I'm trying to use ASWebAuthenticationSession on macOS but there is a weird crash and I have no idea what to do. It looks like there is a main thread check in a framework code that I have no control over. Any help would be appreciated. Thank you in advance. The stack of crashed thread has no symbols, even for supposedly my code in OAuthClient.authenticate. macOS 15.4.1 (24E263) Xcode Version 16.3 (16E140) Thread 11: EXC_BREAKPOINT (code=1, subcode=0x10039bb04) Thread 12 Queue : com.apple.NSXPCConnection.m-user.com.apple.SafariLaunchAgent (serial) #0 0x0000000100b17b04 in _dispatch_assert_queue_fail () #1 0x0000000100b52834 in dispatch_assert_queue$V2.cold.1 () #2 0x0000000100b17a88 in dispatch_assert_queue () #3 0x000000027db5f3e8 in swift_task_isCurrentExecutorWithFlagsImpl () #4 0x00000001022c7754 in closure #1 in closure #1 in OAuthClient.authenticate() () #5 0x00000001022d0c98 in thunk for @escaping @callee_guaranteed (@in_guaranteed URL?, @guaranteed Error?) -> () () #6 0x00000001c7215a34 in __102-[ASWebAuthenticationSession initWithURL:callback:usingEphemeralSession:jitEnabled:completionHandler:]_block_invoke () #7 0x00000001c72163d0 in -[ASWebAuthenticationSession _endSessionWithCallbackURL:error:] () #8 0x00000001c7215fc0 in __43-[ASWebAuthenticationSession _startDryRun:]_block_invoke_2 () #9 0x0000000194e315f4 in __invoking___ () #10 0x0000000194e31484 in -[NSInvocation invoke] () #11 0x00000001960fd644 in __NSXPCCONNECTION_IS_CALLING_OUT_TO_REPLY_BLOCK__ () #12 0x00000001960fbe40 in -[NSXPCConnection _decodeAndInvokeReplyBlockWithEvent:sequence:replyInfo:] () #13 0x00000001960fb798 in __88-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:]_block_invoke_3 () #14 0x0000000194a6ef18 in _xpc_connection_reply_callout () #15 0x0000000194a6ee08 in _xpc_connection_call_reply_async () #16 0x0000000100b3130c in _dispatch_client_callout3_a () #17 0x0000000100b362f8 in _dispatch_mach_msg_async_reply_invoke () #18 0x0000000100b1d3a8 in _dispatch_lane_serial_drain () #19 0x0000000100b1e46c in _dispatch_lane_invoke () #20 0x0000000100b2bfbc in _dispatch_root_queue_drain_deferred_wlh () #21 0x0000000100b2b414 in _dispatch_workloop_worker_thread () #22 0x0000000100c0379c in _pthread_wqthread () My code: @MainActor func authenticate() async throws { let authURL = api.authorizationURL( scopes: scopes, state: state, redirectURI: redirectURI ) let authorizationCodeURL: URL = try await withUnsafeThrowingContinuation { c in let session = ASWebAuthenticationSession(url: authURL, callback: .customScheme(redirectScheme)) { url, error in guard let url = url else { c.resume(throwing: error ?? Error.unknownError("Failed to get authorization code")) return } c.resume(returning: url) } session.presentationContextProvider = presentationContextProvider session.start() } let authorizationCode = try codeFromAuthorizationURL(authorizationCodeURL) (storedAccessToken, storedRefreshToken) = try await getTokens(authorizationCode: authorizationCode) } Here is disassembly of the crashed function. libdispatch.dylib`_dispatch_assert_queue_fail: 0x10067fa8c <+0>: pacibsp 0x10067fa90 <+4>: sub sp, sp, #0x50 0x10067fa94 <+8>: stp x20, x19, [sp, #0x30] 0x10067fa98 <+12>: stp x29, x30, [sp, #0x40] 0x10067fa9c <+16>: add x29, sp, #0x40 0x10067faa0 <+20>: adrp x8, 71 0x10067faa4 <+24>: add x8, x8, #0x951 ; "not " 0x10067faa8 <+28>: adrp x9, 70 0x10067faac <+32>: add x9, x9, #0x16b ; "" 0x10067fab0 <+36>: stur xzr, [x29, #-0x18] 0x10067fab4 <+40>: cmp w1, #0x0 0x10067fab8 <+44>: csel x8, x9, x8, ne 0x10067fabc <+48>: ldr x10, [x0, #0x48] 0x10067fac0 <+52>: cmp x10, #0x0 0x10067fac4 <+56>: csel x9, x9, x10, eq 0x10067fac8 <+60>: stp x9, x0, [sp, #0x10] 0x10067facc <+64>: adrp x9, 71 0x10067fad0 <+68>: add x9, x9, #0x920 ; "BUG IN CLIENT OF LIBDISPATCH: Assertion failed: " 0x10067fad4 <+72>: stp x9, x8, [sp] 0x10067fad8 <+76>: adrp x1, 71 0x10067fadc <+80>: add x1, x1, #0x8eb ; "%sBlock was %sexpected to execute on queue [%s (%p)]" 0x10067fae0 <+84>: sub x0, x29, #0x18 0x10067fae4 <+88>: bl 0x1006c258c ; symbol stub for: asprintf 0x10067fae8 <+92>: ldur x19, [x29, #-0x18] 0x10067faec <+96>: str x19, [sp] 0x10067faf0 <+100>: adrp x0, 71 0x10067faf4 <+104>: add x0, x0, #0x956 ; "%s" 0x10067faf8 <+108>: bl 0x1006b7b64 ; _dispatch_log 0x10067fafc <+112>: adrp x8, 108 0x10067fb00 <+116>: str x19, [x8, #0x2a8] -> 0x10067fb04 <+120>: brk #0x1

I have a very basic binary question around passkeys. Assuming everything is on latest and greatest version with respect to iOS, when user starts creating a passkey in platform-authenticator i.e., iCloudKeyChain (Apple Password Manager) , will iCloudKeyChain create a hardware-bound passkey in secure-enclave i.e., is brand new key-pair created right inside Secure-enclave ? OR will the keypair be created in software i.e., software-bound-passkey ?? i.e., software-bound keypair and store the private-key locally in the device encrypted with a key that is of course created in secure-enclave.

I am working on a SDK which helps identify the device authenticity. I am in need of something which can confirm the firmware/Hardware/OS is signed by Apple and is authentic. There will be no tempering to device?

Hello everyone, I've noticed some unusual behavior while debugging my application on the iOS 26 beta. My standard testing process relies on the App Tracking Transparency (ATT) authorization status being reset whenever I uninstall and reinstall my app. This is crucial for me to test the permission flow. However, on the current beta, I've observed the following: 1 I installed my app on a device running the iOS 26 beta for the first time. The ATTrackingManager.requestTrackingAuthorization dialog appeared as expected. 2 I completely uninstalled the application. 3 I then reinstalled the app. Unexpected Result: The tracking permission dialog did not appear. And more importantly, the device's advertisingIdentifier appears to have remained unchanged. This is highly unusual, as the IDFA is expected to be reset with a fresh app installation. My question: Is this an intentional change, and is there a fundamental shift in how the operating system handles the persistence of the IDFA or the authorization status? Or could this be a bug in the iOS 26 beta? Any information or confirmation on this behavior would be greatly appreciated.

I modified the system.login.screensaver rule in the authorization database to use "authenticate" instead of "use-login-window-ui" to display a custom authentication plugin view when the screensaver starts or the screen locks. However, I noticed an issue when the "Require Password after Display is Turned Off" setting is set to 5 minutes in lock screen settings: If I close my Mac’s lid and reopen it within 5 minutes, my authentication plugin view is displayed as expected. However, the screen is not in a locked state—the desktop remains accessible, and the black background that typically appears behind the lock screen is missing. This behavior differs from the default lock screen behavior, where the screen remains fully locked, and the desktop is hidden. Has anyone encountered this issue before? Is there a way to ensure the screen properly locks when using authenticate in the screensaver rule?

can i get transferid by /auth/usermigrationinfo api before transfered app? https://developer.apple.com/documentation/sign_in_with_apple/transferring-your-apps-and-users-to-another-team#Generate-the-transfer-identifier

I am developing a sample authorization plugin to sync the user’s local password to the network password. During the process, I prompt the user to enter both their old and new passwords in custom plugin. After the user enters the information, I use the following code to sync the passwords: try record.changePassword(oldPssword, toPassword: newPassword) However, I have noticed that this is clearing all saved keychain information, such as web passwords and certificates. Is it expected behavior for record.changePassword to clear previously stored keychain data? If so, how can I overcome this issue and ensure the keychain information is preserved while syncing the password? Thank you for your help!

I’d like to confirm something regarding the hosting of the apple-app-site-association (AASA) file. We have a server that publicly hosts the AASA file and is accessible globally. However, this server sits behind an additional security layer (a security server/reverse proxy). My question is: Will this security layer affect Apple’s ability to access and validate the AASA file for Universal Links or App Clips? Are there specific requirements (e.g. headers, redirects, TLS versions, etc.) that we need to ensure the security server does not block or modify? Any guidance or best practices would be appreciated. Thanks!

Greetings, We are struggling to implement device binding according to your documentation. We are generation a nonce value in backend like this: public static String generateNonce(int byteLength) { byte[] randomBytes = new byte[byteLength]; new SecureRandom().nextBytes(randomBytes); return Base64.getUrlEncoder().withoutPadding().encodeToString(randomBytes); } And our mobile client implement the attestation flow like this: @implementation AppAttestModule - (NSData *)sha256FromString:(NSString *)input { const char *str = [input UTF8String]; unsigned char result[CC_SHA256_DIGEST_LENGTH]; CC_SHA256(str, (CC_LONG)strlen(str), result); return [NSData dataWithBytes:result length:CC_SHA256_DIGEST_LENGTH]; } RCT_EXPORT_MODULE(); RCT_EXPORT_METHOD(generateAttestation:(NSString *)nonce resolver:(RCTPromiseResolveBlock)resolve rejecter:(RCTPromiseRejectBlock)reject) { if (@available(iOS 14.0, *)) { DCAppAttestService *service = [DCAppAttestService sharedService]; if (![service isSupported]) { reject(@"not_supported", @"App Attest is not supported on this device.", nil); return; } NSData *nonceData = [self sha256FromString:nonce]; NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults]; NSString *savedKeyId = [defaults stringForKey:@"AppAttestKeyId"]; NSString *savedAttestation = [defaults stringForKey:@"AppAttestAttestationData"]; void (^resolveWithValues)(NSString *keyId, NSData *assertion, NSString *attestationB64) = ^(NSString *keyId, NSData *assertion, NSString *attestationB64) { NSString *assertionB64 = [assertion base64EncodedStringWithOptions:0]; resolve(@{ @"nonce": nonce, @"signature": assertionB64, @"deviceType": @"IOS", @"attestationData": attestationB64 ?: @"", @"keyId": keyId }); }; void (^handleAssertion)(NSString *keyId, NSString *attestationB64) = ^(NSString *keyId, NSString *attestationB64) { [service generateAssertion:keyId clientDataHash:nonceData completionHandler:^(NSData *assertion, NSError *assertError) { if (!assertion) { reject(@"assertion_error", @"Failed to generate assertion", assertError); return; } resolveWithValues(keyId, assertion, attestationB64); }]; }; if (savedKeyId && savedAttestation) { handleAssertion(savedKeyId, savedAttestation); } else { [service generateKeyWithCompletionHandler:^(NSString *keyId, NSError *keyError) { if (!keyId) { reject(@"keygen_error", @"Failed to generate key", keyError); return; } [service attestKey:keyId clientDataHash:nonceData completionHandler:^(NSData *attestation, NSError *attestError) { if (!attestation) { reject(@"attestation_error", @"Failed to generate attestation", attestError); return; } NSString *attestationB64 = [attestation base64EncodedStringWithOptions:0]; [defaults setObject:keyId forKey:@"AppAttestKeyId"]; [defaults setObject:attestationB64 forKey:@"AppAttestAttestationData"]; [defaults synchronize]; handleAssertion(keyId, attestationB64); }]; }]; } } else { reject(@"ios_version", @"App Attest requires iOS 14+", nil); } } @end For validation we are extracting the nonce from the certificate like this: private static byte[] extractNonceFromAttestationCert(X509Certificate certificate) throws IOException { byte[] extensionValue = certificate.getExtensionValue("1.2.840.113635.100.8.2"); if (Objects.isNull(extensionValue)) { throw new IllegalArgumentException("Apple App Attest nonce extension not found in certificate."); } ASN1Primitive extensionPrimitive = ASN1Primitive.fromByteArray(extensionValue); ASN1OctetString outerOctet = ASN1OctetString.getInstance(extensionPrimitive); ASN1Sequence sequence = (ASN1Sequence) ASN1Primitive.fromByteArray(outerOctet.getOctets()); ASN1TaggedObject taggedObject = (ASN1TaggedObject) sequence.getObjectAt(0); ASN1OctetString nonceOctet = ASN1OctetString.getInstance(taggedObject.getObject()); return nonceOctet.getOctets(); } And for the verification we are using this method: private OptionalMethodResult<Void> verifyNonce(X509Certificate certificate, String expectedNonce, byte[] authData) { byte[] expectedNonceHash; try { byte[] nonceBytes = MessageDigest.getInstance("SHA-256").digest(expectedNonce.getBytes()); byte[] combined = ByteBuffer.allocate(authData.length + nonceBytes.length).put(authData).put(nonceBytes).array(); expectedNonceHash = MessageDigest.getInstance("SHA-256").digest(combined); } catch (NoSuchAlgorithmException e) { log.error("Error while validations iOS attestation: {}", e.getMessage(), e); return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } byte[] actualNonceFromCert; try { actualNonceFromCert = extractNonceFromAttestationCert(certificate); } catch (Exception e) { log.error("Error while extracting nonce from certificate: {}", e.getMessage(), e); return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } if (!Arrays.equals(expectedNonceHash, actualNonceFromCert)) { return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } return OptionalMethodResult.empty(); } But the values did not matched. What are we doing wrong here? Thanks.

I'm working on a Password Manager app that integrates with the AutoFill Credential Provider to provide stored passwords and OTPs to the user within Safari and other apps. Password AutoFill works perfectly. I'm unable to get iOS to register that the app supports OTPs though. I've followed the Apple documentation here: https://developer.apple.com/documentation/authenticationservices/providing-one-time-passcodes-to-autofill and added "ProvidesOneTimeCodes" to the AutoFill extension's Info.plist, but iOS just doesn't seem to notice the OTP support. &lt;key&gt;ASCredentialProviderExtensionCapabilities&lt;/key&gt; &lt;dict&gt; &lt;key&gt;ProvidesOneTimeCodes&lt;/key&gt; &lt;true/&gt; &lt;key&gt;ProvidesPasswords&lt;/key&gt; &lt;true/&gt; &lt;/dict&gt; Any help would be greatly appreicated!

We are experiencing a significant issue with macOS security alerts that began on July 9th, at approximately 4:40 AM UTC. This alert is incorrectly identifying output files from our snippet tests as malware, causing these files to be blocked and moved to the Trash. This is completely disrupting our automated testing workflows. Issue Description: Alert: We are seeing the "Malware Blocked and Moved to Trash" popup window. Affected Files: The security alert triggers when attempting to execute .par files generated as outputs from our snippet tests. These .par files are unique to each individual test run; they are not a single, static tool. System-Wide Impact: This issue is impacting multiple macOS hosts across our testing infrastructure. Timeline: The issue began abruptly on July 9th, at approximately 4:40 AM UTC. Before that time, our tests were functioning correctly. macOS Versions: The problem is occurring on hosts running both macOS 14.x and 15.x. Experimental Host: Even after upgrading an experimental host to macOS 15.6 beta 2, the issue persisted. Local execution: The issue can be reproduced locally. Observations: The security system is consistently flagging these snippet test output files as malware. Since each test generates a new .par file, and this issue is impacting all generated files, the root cause doesn't appear to be specific to the code within the .par files themselves. This issue is impacting all the snippet tests, making us believe that the root cause is not related to our code. The sudden and widespread nature of the issue strongly suggests a change in a security database or rule, rather than a change in our testing code. Questions: Could a recent update to the XProtect database be the cause of this false positive? Are there any known issues or recent changes in macOS security mechanisms that could cause this kind of widespread and sudden impact? What is the recommended way to diagnose and resolve this kind of false positive? We appreciate any guidance or assistance you can provide. Thank you.

First, I do not publish my application to the AppStore, but I need to customize a sandbox environment. It seems that sandbox-exec cannot configure entitlements, so I have used some other APIs, such as sandbox_compile_entitlements and sandbox_apply_container. When encountering the entitlement "com.apple.security.files.user-selected.read-only", I am unsure how to correctly write sandbox profile to implement this. Can anyone help me?

Hello Experts, I am in need of your help with this feedback from the App Reviewer. Issue Description: One or more purpose strings in the app do not sufficiently explain the use of protected resources. Purpose strings must clearly and completely describe the app's use of data and, in most cases, provide an example of how the data will be used. Next Steps: Update the location purpose string to explain how the app will use the requested information and provide a specific example of how the data will be used. See the attached screenshot. Resources: Purpose strings must clearly describe how an app uses the ability, data, or resource. The following are hypothetical examples of unclear purpose strings that would not pass review: "App would like to access your Contacts" "App needs microphone access" Feedback #2 "Regarding 5.1.1, we understand why your app needs access to location. However, the permission request alert does not sufficiently explain this to your users before accessing the location. To resolve this issue, it would be appropriate to revise the location permission request, specify why your app needs access, and provide an example of how your app will use the user's data. To learn more about purpose string requirements, watch a video from App Review with tips for writing clear purpose strings. We look forward to reviewing your app once the appropriate changes have been made." May I know how can I update my purpose string? I appealed on the first feedback by explaining what is the purpose of it but got the Feedback #2. TYIA!!

Hi, I hope someone is able to help me with this query: Is there a mandatory requirement to display a view before presenting the App Tracking Transparency modal to explain to the user why the app is asking for tracking? I see there are a few apps which do this, but I don't see any mention of this as a mandatory requirement within the app store review guidelines. The modal can be customised with a description detailing why the app is asking for tracking and I believe this may be sufficient to pass an app store review. The guidelines also mention that the app must provide access to information about how and where the data will be used. We have these details in our privacy policy which is accessible from within the app. Is this sufficient or do we need a pre-modal view which contains a direct link the the privacy policy. Any advice on this would be much appreciated.

We are working with an iOS app where we have enabled the “Generate Debug Symbols” setting to true in Xcode. As a result, the .dSYM files are generated and utilized in Firebase Crashlytics for crash reporting. However, we received a note in our Vulnerability Assessment report indicating a potential security concern. The report mentions that the .ipa file could be reverse-engineered due to the presence of debug symbols, and that such symbols should not be included in a released app. We could not find any security-related information about this flag, “Generate Debug Symbols,” in Apple’s documentation. Could you please clarify if enabling the “Generate Debug Symbols” flag in Xcode for a production app creates any security vulnerabilities, such as the one described in the report? The report mentions the following vulnerability: TEST-0219: Testing for Debugging Symbols The concern raised is that debugging symbols, while useful for crash symbolication, may be leveraged to reverse-engineer the app and should not be present in a production release. Your prompt confirmation on this matter would be greatly appreciated. Thank you in advance for your assistance.

Hi, I am creating a custom login window, so I am using SFAuthorizationpluginView, here I want to hide Submit Arrow botton which gets displayed beside username and password text feild , is there a way to hide this, please suggest.

Step1. Update system.login.screensaver authorizationdb rule to use “authenticate-session-owner-or-admin”( to get old SFAutorizationPluginView at Lock Screen ). Here I will use my custom authorization plugin. Step 2. Once the rule is in place, logout and login, now click on Apple icon and select “Lock Screen”. Is there a way programmatically to update the Lock Icon and the test getting displayed on the first Unlock screen? When I write a custom authorisation plug-in, I am getting control of the text fields and any consecutive screen I add from there on. But all I want is to update the lock icon and text fields on 1st unlock display itself. Can you please suggest how I can achieve this? Here is the screenshot with marked areas I am looking control for.

Why are we doing this nonsense? We want to be able to run builds in a sandbox such that they can only see the paths they are intended to depend on, to improve reproducibility. With builds with a very large number of dependencies, there's a very large number of paths added to the sandbox, and it breaks things inside libsandbox. Either it hits some sandbox length limit (sandbox-exec: pattern serialization length 66460 exceeds maximum (65535), Nix issue #4119, worked around: Nix PR 12570), or it hits an assert (this report; also Nix issue #2311). The other options for sandboxing on macOS are not viable; we acknowledge sandbox-exec and sandbox_init_with_parameters are deprecated; App Sandbox is inapplicable because we aren't an app. Our use case is closer to a browser, and all the browsers use libsandbox internally. We could possibly use SystemExtension or a particularly diabolical use of Virtualization.framework, but the former API requires notarization which is close to a no-go for our use case as open source software: it is nearly impossible to develop the software on one's own computer, and it would require us to ship a binary blob (and have the build processes to produce one in infrastructure completely dissimilar to what we use today); it also requires a bunch of engineering time. Today, we can pretend that code signing/notarization doesn't exist and that we are writing an old-school Unix daemon, because we are one. The latter is absolutely diabolical and hard to implement. See this saga about the bug we are facing: Nix issue #4119, Nix issue #2311, etc. What is going wrong I can't attach the file fail.sb as it is too large (you can view the failing test case at Lix's gerrit, CL 2870) and run this: $ sandbox-exec -D _GLOBAL_TMP_DIR=/tmp -f fail.sb /bin/sh Assertion failed: (diff &lt;= INSTR_JUMP_NE_MAX_LENGTH), function push_jne_instr, file serialize.c, line 240. zsh: abort sandbox-exec -D _GLOBAL_TMP_DIR=/tmp -f fail.sb /bin/sh Or a stacktrace: stacktrace.txt Credits Full credits to Jade Lovelace (Lix) for writing the above text and filing a bug. This is submitted under FB16964888

We are using SecPKCS12Import C API in our application to import a self seigned public key certificate. We tried to run the application for the first time on Tahoe and it failed with OSStatus -26275 error. The release notes didn't mention any deprecation or change in the API as per https://developer.apple.com/documentation/macos-release-notes/macos-26-release-notes. Are we missing anything? There are no other changes done to our application.

Title: Sporadical - Permissions Not Cleared After App Uninstallation on iOS18 I install and launch my private MAUI App I ask for example Bluetooth permissions (can be any other permission) I tap Allow button on native settings (or Don't Allow) I unistall app from real phone (we can wait for a while) I install and launch My Private MAUI App I ask for example Bluetooth permissions &lt;- here is an issue. Bluetooth is already granted, so I cannot ask for it again. Occurrence: This issue occurs inconsistently: On iOS 18.5: approximately 5 out of 10 times On iOS 17: approximately 1 out of 50 times Tested using my automated system using Appium latest. After each scenario I unistall app using: "mobile: removeApp" with bundleId