We are using SecItemCopyMatching from LocalAuthentication to access the private key to sign a challenge in our native iOS app twice in a few seconds from user interactions. This was working as expected up until about a week ago where we started getting reports of it hanging on the biometrics screen (see screenshot below). From our investigation we've found the following: It impacts newer iPhones using iOS 26.1 and later. We have replicated on these devices: iPhone 17 Pro max iPhone 16 Pro iPhone 15 Pro max iPhone 15 Only reproducible if the app tries to access the private key twice in quick succession after granting access to face ID. Looks like a race condition between the biometrics permission prompt and Keychain private key access We were able to make it work by waiting 10 seconds between private key actions, but this is terrible UX. We tried adding adding retries over the span of 10 seconds which fixed it on some devices, but not all. We checked the release notes for iOS 26.1, but there is nothing related to this. Screenshot:

While working with Platform SSO on macOS, I’m trying to better understand how the system handles cases where a user’s local account password becomes unsynchronized with their Identity Provider (IdP) password—for example, when the device is offline during a password change. My assumption is that macOS may store some form of persistent token during the Platform SSO user registration process (such as a certificate or similar credential), and that this token could allow the system to unlock the user’s login keychain even if the local password no longer matches the IdP password. I’m hoping to get clarification on the following: Does macOS actually use a persistent token to unlock the login keychain when the local account password is out of sync with the IdP password? If so, how is that mechanism designed to work? If such a capability exists, is it something developers can leverage to enable a true passwordless authentication experience at the login window and lock screen (i.e., avoiding the need for a local password fallback)? I’m trying to confirm what macOS officially supports so I can understand whether passwordless login is achievable using the persistent-token approach. Thanks in advance for any clarification.

Hi, We are implementing Platform SSO and using attestKey during registration via ASAuthorizationProviderExtensionLoginManager. Could you clarify whether the attestKey flow involves sending attestation data to an Apple server for verification (similar to App Attest in the DeviceCheck framework), or if the attestation certificate chain is generated and signed entirely on-device without any Apple server interaction? The App Attest flow is clearly documented as using Apple’s attestation service, but the Platform SSO process is less clearly described. Thank you.

I have filed bug reports on this to no avail, so I am bringing it up here hoping someone at Apple will address this. Since the first beta of 26.3, with voice control enabled there are now two icons in the menu bar (*plus an orange dot in full screen) that never go away. That orange microphone isn't serving its intended purpose to notify me that something is accessing my microphone if it is always displayed. I use voice control extensively, so it is nearly always on. In every prior version of macOS, the orange icon was not on for voice control. Even if voice control is not listening but simply enabled in system settings, the orange icon will be there. And there is no need for this icon to be on for a system service that is always listening. This orange icon in the menu bar at all times is incredibly irritating, as it takes up valuable space to the right of the notch, and causes other actual useful menu bar items to be hidden. As well, if some other application on my system were to turn on the mic and start recording me I would never know since that orange icon is always on. It also places an orange dot next to the control center icon taking up even more of the precious little menu bar real estate. Please fix this! Either exempt voice control (as Siri is always listening and it doesn't get the orange icon) or exempt all system services, or give me a way to turn this off. If you cannot tell, I find this incredibly annoying and frustrating.

Hi, we were recently approved for the com.apple.developer.web-browser.public-key-credential entitlement and have added it to our app. It initially worked as expected for a couple of days, but then it stopped working. We're now seeing the same error as before adding the entitlement: Told not to present authorization sheet: Error Domain=com.apple.AuthenticationServicesCore.AuthorizationError Code=1 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "(null)" Do you have any insights into what might be causing this issue? Thank you!

I am new to swift development, and it's possible that I'm missing something fundamental/obvious. If so, I apologize in advance. My team is developing an application for iPadOS using SwiftUI, and I'm trying to accomplish something similar to what the original inquirer is asking for in this thread: https://developer.apple.com/forums/thread/725152. The only difference is that I'm trying to use a PIV smart card to achieve authentication to a server rather than digitally sign a document. Unfortunately, I'm getting stuck when attempting to run the list() function provided in the accepted answer to the post mentioned above. When attempting to call SecItemCopyMatching(), I'm getting a -34018 missing entitlement error. I've attempted to add the com.apple.token to my app's keychain-access-groups entitlements, but this does not resolve the issue. I have checked the entitlements in my built app, per the recommendation in the troubleshooting guide here: https://developer.apple.com/forums/thread/114456. The entitlement for com.apple.token is indeed present in the plist. Based on other documentation I've read, however, it seems that the explicit declaration of com.apple.token should not even be required in the entitlements. Is there something obvious that I'm missing here that would prevent my app from accessing the token access group?

I'm developing an iOS app that utilizes Universal Links and ASWebAuthenticationSession to deep-link from a website to the app itself. This implementation adheres to the recommendations outlined in RFC 8252, ensuring that the app opening the ASWebAuthenticationSession is the same app that is launched via the Universal Link. Problem: 　While most users can successfully launch the app via Universal Links,a few percent of users experience instances where the app fails to launch, and the user is redirected to the browser. What I've Tried: 　ASWebAuthenticationSession Configuration: I've double-checked the configuration of callbackURLScheme and presentationContextProvider. 　Universal Links: Verified the apple-app-site-association file and associated domains entitlement. 　Network Conditions: Tested on various network environments (Wi-Fi, cellular) and devices. Questions: 　What are the potential causes for this behavior? 　Has anyone else encountered a similar issue and found a solution? 　Are there any debugging techniques or ways to generate more detailed logs? I haven't been able to determine which device or OS version is causing this problem. Thank you.

I can't find any information about why this is happening, nor can I reproduce the 'successful' state on this device. My team needs to understand this behavior, so any insight would be greatly appreciated! The expected behavior: If I delete both apps and reinstall them, attempting to open the second app from my app should trigger the system confirmation dialog. The specifics: I'm using the MSAL library. It navigates the user to the Microsoft Authenticator app and then returns to my app. However, even after resetting the phone and reinstalling both apps, the dialog never shows up (it just opens the app directly). Does anyone know the logic behind how iOS handles these prompts or why it might be persistent even after a reset? Thanks in advance!

Attempting to DECRYPT a cipher message using the Apple API SecKeyCreateDecryptedData(privateKey, .rsaEncryptionOAEPSHA256, encryptedMessage). Decryption ALWAYS fails for every algorithm. SecKeyCreateDecryptedDataWithParameters Error: `Domain=NSOSStatusErrorDomain Code=-50 "algid:encrypt:RSA:OAEP:SHA256: algorithm not supported by the key <SecKeyRef:('com.yubico.Authenticator.TokenExtension:5621CDF8560D4C412030886584EC4C9E394CC376DD9738B0CCBB51924FC26EB6') 0x3007fd150>" UserInfo={numberOfErrorsDeep=0, NSDescription=algid:encrypt:RSA:OAEP:SHA256: algorithm not supported by the key <SecKeyRef:('com.yubico.Authenticator.TokenExtension:5621CDF8560D4C412030886584EC4C9E394CC376DD9738B0CCBB51924FC26EB6') 0x3007fd150>}` Decryption failed: SecKeyCreateDecryptedData returned nil. Error: One or more parameters passed to a function were not valid. When checking with SecKeyIsAlgorithmSupported(privateKey, .decrypt, <ANYalgorithm>) all algorithms fail. Btw - The privateKey does support decryption when retrieving the attributes. Important to know: The private key is a reference to an external private key placed in the iOS Keychain via a 3rd party CryptoTokenKit Extension app. When I perform, the SecKeyCreateSignature(...) and pass in the SAME privateKey reference, the OS automatically calls the 3rd party app to perform a successful signing with the private key that reside on a YubiKey. Here's my code for obtaining the private key reference from an Identity: func getKeyPairFromIdentity() -> (privateKey: SecKey, publicKey: SecKey)? { let query = NSDictionary( dictionary: [ kSecClass as String: kSecClassIdentity, kSecAttrTokenID as String: self.tokenID!, kSecReturnRef as String: kCFBooleanTrue as Any ] ) var identityRef: CFTypeRef? let status = SecItemCopyMatching(query, &identityRef) if status == errSecSuccess, let identity = identityRef { var privateKeyRef: SecKey? let keyStatus = SecIdentityCopyPrivateKey(identity as! SecIdentity, &privateKeyRef) if keyStatus == errSecSuccess, let privateKey = privateKeyRef { let publicKey = SecKeyCopyPublicKey(privateKey) if let publicKey = publicKey { print("Private and public keys extracted successfully.") return (privateKey, publicKey) } else { print("Failed to extract public key from private key.") return nil } } else { print("SecIdentityCopyPrivateKey: Private key not found error: \(keyStatus)") return nil } } else { print("SecIdentity not found or error: \(status)") return nil } }

Hello, I am currently working on iOS application development using Swift, targeting iOS 17 and above, and need to implement mTLS for network connections. In the registration API flow, the app generates a private key and CSR on the device, sends the CSR to the server (via the registration API), and receives back the signed client certificate (CRT) along with the intermediate/CA certificate. These certificates are then imported on the device. The challenge I am facing is pairing the received CRT with the previously generated private key in order to create a SecIdentity. Could you please suggest the correct approach to generate a SecIdentity in this scenario? If there are any sample code snippets, WWDC videos, or documentation references available, I would greatly appreciate it if you could share them. Thank you for your guidance.

For testing purposes we have code that calls SecTrustEvaluateAsyncWithError() with a trust object containing a hardcoded leaf certificate and the corresponding intermediate certificate required to form a valid chain. Because the leaf certificate has since expired we pass a date in the past via SecTrustSetVerifyDate() at wich the certificate was still valid, but trust evaluation fails: Error Domain=NSOSStatusErrorDomain Code=-67825 "“<redacted>” certificate is not standards compliant" UserInfo={NSLocalizedDescription=“<redacted>” certificate is not standards compliant, NSUnderlyingError=0x600000c282a0 {Error Domain=NSOSStatusErrorDomain Code=-67825 "Certificate 0 “<redacted>” has errors: Certificate Transparency validation required for this use;" UserInfo={NSLocalizedDescription=Certificate 0 “<redacted>” has errors: Certificate Transparency validation required for this use;}}} I know that App Transport Security enforces Certificate Transparency by default, but is there a way around that here?

In some crashlog files, there are additional pieces of information related to codesigning. I can understand what most of themcorresponds to (ID, TeamID, Flags, Validation Category). But there is one I have some doubt about: Trust Level. As far as I can tell (or at least what Google and other search engines say), this is an unsigned 32 bit integer that defines the trust level with -1 being untrusted, 0, being basically an Apple executable and other potential bigger values corresponding to App Store binaries, Developer ID signature, etc. Yet, I'm not able to find a corresponding detailed documentation about this on Apple's developer website. I also had a look at the LightweightCodeRequirements "include" file and there does not seem to be such a field available. [Q] Is there any official documentation listing the different values for this trust level value and providing a clear description of what it corresponds to?

Hi, my app is receiving all keyboard events through Input Monitoring preference. It completely stopped to work on macOS 15 Sequoia and I have no idea why. Where can I read what has been changed in Input Monitoring? Thanks!

We are interested in using a hardware-bound key in a launch daemon. In a previous post, Quinn explicitly told me this is not possible to use an SE keypair outside of the system context and my reading of the Apple documentation also supports that. That said, we have gotten the following key-creation and persistence flow to work, so we have some questions as to how this fits in with the above. (1) In a launch daemon (running thus as root), we do: let key = SecureEnclave.P256.Signing.PrivateKey() (2) We then use key.dataRepresentation to store a reference to the key in the system keychain as a kSecClassGenericPassword. (3) When we want to use the key, we fetch the data representation from system keychain and we "rehydrate" the key using: SecureEnclave.P256.Signing.PrivateKey(dataRepresentation: data) (4) We then use the output of the above to sign whatever we want. My questions: in the above flow, are we actually getting a hardware-bound key from the Secure Enclave or is this working because it's actually defaulting to a non-hardware-backed key? if it is an SE key, is it that the Apple documentation stating that you can only use the SE with the Data Protection Keychain in the user context is outdated (or wrong)? does the above work, but is not an approach sanctioned by Apple? Any feedback on this would be greatly appreciated.

We are facing an issue with Keychain sharing across our apps after our Team ID was updated. Below are the steps we have already tried and the current observations: Steps we have performed so far: After our Team ID changed, we opened and re-saved all the provisioning profiles. We created a Keychain Access Group: xxxx.net.soti.mobicontrol (net.soti.mobicontrol is one bundle id of one of the app) and added it to the entitlements of all related apps. We are saving and reading certificates using this access group only. Below is a sample code snippet we are using for the query: [genericPasswordQuery setObject:(id)kSecClassGenericPassword forKey:(id)kSecClass]; [genericPasswordQuery setObject:identifier forKey:(id)kSecAttrGeneric]; [genericPasswordQuery setObject:accessGroup forKey:(id)kSecAttrAccessGroup]; [genericPasswordQuery setObject:(id)kSecMatchLimitOne forKey:(id)kSecMatchLimit]; [genericPasswordQuery setObject:(id)kCFBooleanTrue forKey:(id)kSecReturnAttributes]; Issues we are facing: Keychain items are not being shared consistently across apps. We receive different errors at different times: Sometimes errSecDuplicateItem (-25299), even when there is no item in the Keychain. Sometimes it works in a debug build but fails in Ad Hoc / TestFlight builds. The behavior is inconsistent and unpredictable. Expectation / Clarification Needed from Apple: Are we missing any additional configuration steps after the Team ID update? Is there a known issue with Keychain Access Groups not working correctly in certain build types (Debug vs AdHoc/TestFlight)? Guidance on why we are intermittently getting -25299 and how to properly reset/re-add items in the Keychain. Any additional entitlement / provisioning profile configuration that we should double-check. Request you to please raise a support ticket with Apple Developer Technical Support including the above details, so that we can get guidance on the correct setup and resolve this issue.

Hi, I have a certificate, how can I display the certificate content in my Mac app just like Keychain Access app does. Can I popup the certificate content dialog just like Keychain Access app?

Hi everyone, I’d like to clarify something regarding the behavior of Team IDs after an app transfer between Apple Developer accounts. I have an app update that enforces a force update for all users. My plan is to release this update under the current developer account, and then proceed with transferring the app to a different developer account shortly afterward. My concern is: once the transfer is complete, will users who download the same app version (released before the transfer) be logged out due to a change in Team ID? Specifically, does the transferred app continue to use the original Team ID (used to sign the last submitted build), or does the Team ID change immediately upon transfer — affecting Keychain access? Any insights or confirmation on this would be greatly appreciated. Thanks!

I work for Brave, a browser with ~80M users. We want to introduce a new system for automatic updates called Omaha 4 (O4). It's the same system that powers automatic updates in Chrome. O4 runs as a separate application on users' systems. For Chrome, this works as follows: An app called GoogleUpdater.app regularly checks for updates in the background. When a new version is found, then GoogleUpdater.app installs it into Chrome's installation directory /Applications/Google Chrome.app. But consider what this means: A separate application, GoogleUpdater.app, is able to modify Google Chrome.app. This is especially surprising because, for example, the built-in Terminal.app is not able to modify Google Chrome.app. Here's how you can check this for yourself: (Re-)install Chrome with its DMG installer. Run the following command in Terminal: mkdir /Applications/Google\ Chrome.app/test. This works. Undo the command: rm -rf /Applications/Google\ Chrome.app/test Start Chrome and close it again. mkdir /Applications/Google\ Chrome.app/test now fails with "Operation not permitted". (These steps assume that Terminal does not have Full Disk Access and System Integrity Protection is enabled.) In other words, once Chrome was started at least once, another application (Terminal in this case) is no longer allowed to modify it. But at the same time, GoogleUpdater.app is able to modify Chrome. It regularly applies updates to the browser. For each update, this process begins with an mkdir call similarly to the one shown above. How is this possible? What is it in macOS that lets GoogleUpdater.app modify Chrome, but not another app such as Terminal? Note that Terminal is not sandboxed. I've checked that it's not related to codesigning or notarization issues. In our case, the main application (Brave) and the updater (BraveUpdater) are signed and notarized with the same certificate and have equivalent requirements, entitlements and provisioning profiles as Chrome and GoogleUpdater. The error that shows up in the Console for the disallowed mkdir call is: kernel (Sandbox) System Policy: mkdir(8917) deny(1) file-write-create /Applications/Google Chrome.app/foo (It's a similar error when BraveUpdater tries to install a new version into /Applications/Brave Browser.app.) The error goes away when I disable System Integrity Protection. But of course, we cannot ask users to do that. Any help would be greatly appreciated.

iOS18.1.1 macOS15.1.1 xcode16.1 Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Unable to verify webcredentials association of ********** with domain ******************. Please try again in a few seconds." Our domain must query with VPN, so I set webcredentials:qa.ejeokvv.com?mode=developer following: "If you use a private web server, which is unreachable from the public internet, while developing your app, enable the alternate mode feature to bypass the CDN and connect directly to your server. To do this, add a query string to your associated domains entitlement, as shown in the following example: :?mode= " but it still not working, even after I set mode=developer. Please help!!!!

Since Sun 15th Jun 04:30 (UTC+7) we received lots of following error that causes our device test failure. Could Apple please investigate further? ############################# Operations could not be completed. (com.apple.devicecheck.error error 4.) (serverUnavailable)