Hi there, We're implementing Apple's DeviceCheck App Attest for production iOS authentication. The public documentation defines DCError cases but doesn't specify which errors are expected per API method or recommend retry/remediation strategies. We need Apple's guidance to implement robust, production-aligned error handling before rollout. 1. Error Surface per API Method Question: Can you confirm the complete, officially expected set of DCError values for each method? We understand the following errors are possible across App Attest APIs: invalidKey invalidInput featureUnsupported serverUnavailable unknownSystemFailure Specifically, please confirm which errors can occur for: DCAppAttestService.generateKey() DCAppAttestService.attestKey(_:clientData:) DCAppAttestService.generateAssertion(keyID:clientData:) Are there any additional undocumented or edge-case errors we should handle? 2. Retry Strategy & Remediation Matrix Question: For each API method and error code, please help us with proposal around which errorCode is retriable, whats the remediation pre retry, retry cap and backoff strategy: Kindly also help with errors that are not covered here: Specific sub-questions: invalidKey handling: When this error occurs: Should the app delete the key and call generateKey again? Or should it fail the entire flow? serverUnavailable handling: Should we retry immediately, or wait before retrying? Is exponential backoff recommended? What's the recommended max retry count? Backoff strategy: Which errors (if any) qualify for exponential backoff? Recommended base delay, max delay, and jitter approach? When should we give up and fail the request? unknownSystemFailure: Is this retriable or should we fail? Any known causes or mitigations? 3. Simulator Testing Questions: Simulator API behavior: Can App Attest APIs be called normally on iOS Simulator? If not, is there a way to simulate for testing. Do they complete successfully with simulated attestations, or do they fail? Thanks, Nirekshitha

Hello, sorry for the awkward text formatting but I kept getting prevented from positing due to "sensitive language"... Help.txt

I'm currently reviewing the various DCError cases defined in Apple’s DeviceCheck framework (reference: https://developer.apple.com/documentation/devicecheck/dcerror-swift.struct). To better understand how to handle these in production, I’m looking for a clear breakdown of: Which specific DCError values can occur during service.generateKey, service.attestKey, and service.generateAssertion The realworld scenarios or conditions that typically cause each error for each method. If anyone has insight on how these errors arise and what conditions trigger them, I’d appreciate your input.

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 developing a macOS application (targeting macOS 13 and later) that is non-sandboxed and needs to install and trust a root certificate by adding it to the System keychain programmatically. I’m fine with prompting the user for admin privileges or password, if needed. So far, I have attempted to execute the following command programmatically from both: A user-level process A root-level process sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.pem While the certificate does get installed, it does not appear as trusted in the Keychain Access app. One more point: The app is not distributed via MDM. App will be distributed out side the app store. Questions: What is the correct way to programmatically install and trust a root certificate in the System keychain? Does this require additional entitlements, signing, or profile configurations? Is it possible outside of MDM management? Any guidance or working samples would be greatly appreciated.

Problem Statement: Pre-requisite is to generate a PKCS#12 file using openssl 3.x or above. Note: I have created a sample cert, but unable to upload it to this thread. Let me know if there is a different way I can upload. When trying to import a p12 certificate (generated using openssl 3.x) using SecPKCS12Import on MacOS (tried on Ventura, Sonoma, Sequoia). It is failing with the error code: -25264 and error message: MAC verification failed during PKCS12 import (wrong password?). I have tried importing in multiple ways through, Security Framework API (SecPKCS12Import) CLI (security import <cert_name> -k ~/Library/Keychains/login.keychain -P "<password>”) Drag and drop in to the Keychain Application All of them fail to import the p12 cert. RCA: The issues seems to be due to the difference in the MAC algorithm. The MAC algorithm used in the modern certs (by OpenSSL3 is SHA-256) which is not supported by the APPLE’s Security Framework. The keychain seems to be expecting the MAC algorithm to be SHA-1. Workaround: The current workaround is to convert the modern p12 cert to a legacy format (using openssl legacy provider which uses openssl 1.1.x consisting of insecure algorithms) which the SecPKCS12Import API understands. I have created a sample code using references from another similar thread (https://developer.apple.com/forums/thread/723242) from 2023. The steps to compile and execute the sample is mentioned in the same file. PFA the sample code by the name “pkcs12_modern_to_legacy_converter.cpp”. Also PFA a sample certificate which will help reproduce the issue by the name “modern_certificate.p12” whose password is “export”. Questions: Is there a fix on this issue? If yes, pls guide me through it; else, is it expected to be fixed in the future releases? Is there a different way to import the p12 cert which is resistant to the issue? This issue also poses a security concerns on using outdated cryptographic algorithms. Kindly share your thoughts. pkcs12_modern_to_legacy_converter.cpp

Using the simplified sign-in with tvOS and a third party password manager, I receive a complete ASPasswordCredential, and I can easily log into my app. When I do the same thing but with Apple's password manager as the source, I receive an ASPasswordCredential that includes the email address, but the password is an empty string. I have tried deleting the credentials from Apple Passwords and regenerating them with a new login to the app's website. I have tried restarting my iPhone. Is this the expected behavior? How should I be getting a password from Apple's Password app with an ASAuthorizationPasswordRequest?

Hi everyone, I’m working an Objective-C lib that performs Keychain operations, such as generating cryptographic keys and signing data. The lib will be used by my team in a Java program for macOS via JNI. When working with the traditional file-based Keychain (i.e., without access control flags), everything works smoothly, no issues at all. However, as soon as I try to generate a key using access control flags SecAccessControlCreateWithFlags, the Data Protection Keychain returns error -34018 (errSecMissingEntitlement) during SecKeyCreateRandomKey. This behavior is expected. To address this, I attempted to codesign my native dynamic library (.dylib) with an entitlement plist specifying various combinations of: keychain-access-groups com.apple.security.keychain etc. with: My Apple Development certificate Developer ID Application certificate Apple Distribution certificate None of these combinations made a difference, the error persists. I’d love to clarify: Is it supported to access Data Protection Keychain / Secure Enclave Keys in this type of use case? If so, what exact entitlements does macOS expect when calling SecKeyCreateRandomKey from a native library? I’d really appreciate any guidance or clarification. Thanks in advance! Best regards, Neil

I am not very well versed in this area, so I would appreciate some guidance on what should be enabled or disabled. My app is an AppKit app. I have read the documentation and watched the video, but I find it hard to understand. When I added the Enhanced Security capability in Xcode, the following options were enabled automatically: Memory Safety Enable Enhanced Security Typed Allocator Runtime Protections Enable Additional Runtime Platform Restrictions Authenticate Pointers Enable Read-only Platform Memory The following options were disabled by default: Memory Safety Enable Hardware Memory Tagging Memory Tag Pure Data Prevent Receiving Tagged Memory Enable Soft Mode for Memory Tagging Should I enable these options? Is there anything I should consider disabling?

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 Team, How can we fetch the macOS password requirement(for setting a new password) that are inforce during login for users? Is there a way to get this info in swift programming?

Problem Description: In our App, When we launch the web login part using ASWebAuthentication + Universal Links with callback scheme as "https", we are not receiving callback. Note: We are using "SwiftUIWebAuthentication" Swift Package Manager to display page in ASWebAuth. But when we use custom url scheme instead of Universal link, app able to receive call back every time. We use ".onOpenURL" to receive universal link callback scheme.

Hello, I am currently researching to develop an application where I want to apply the MacOS updates without the password prompt shown to the users. I did some research on this and understand that an MDM solution can apply these patches without user intervention. Are there any other ways we can achieve this? Any leads are much appreciated.

I have been implementing an sdk for authenticating a user. I have noticed that on iOS 18.5, whether using SFSafariViewController, or the sdk (built on ASWebAuthenticationSession), password autofill does not work. I have confirmed it works on a different device running iOS 18.0.1. Are there any work arounds for this at this time? Specifically for ASWebAuthenticationSession?

I'm trying to add a generic password to the keychain and get back the persistent ID for it, and give it .userPresence access control. Unfortunately, if I include that, I get paramError back from SecItemAdd. Here's the code: @discardableResult func set(username: String, hostname: String?, password: String, comment: String? = nil) throws -> PasswordEntry { // Delete any existing matching password… if let existing = try? getEntry(forUsername: username, hostname: hostname) { try deletePassword(withID: existing.id) } // Store the new password… var label = username if let hostname { label = label + "@" + hostname } var item: [String: Any] = [ kSecClass as String : kSecClassGenericPassword, kSecAttrDescription as String : "TermPass Password", kSecAttrGeneric as String : self.bundleID.data(using: .utf8)!, kSecAttrLabel as String : label, kSecAttrAccount as String : username, kSecValueData as String : password.data(using: .utf8)!, kSecReturnData as String : true, kSecReturnPersistentRef as String: true, ] if self.synchronizable { item[kSecAttrSynchronizable as String] = kCFBooleanTrue! } if let hostname { item[kSecAttrService as String] = hostname } if let comment { item[kSecAttrComment as String] = comment } // Apply access control to require the user to prove presence when // retrieving this password… var error: Unmanaged<CFError>? guard let accessControl = SecAccessControlCreateWithFlags(nil, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, .userPresence, &error) else { let cfError = error!.takeUnretainedValue() as Error throw cfError } item[kSecAttrAccessControl as String] = accessControl item[kSecAttrAccessible as String] = kSecAttrAccessibleWhenUnlockedThisDeviceOnly var result: AnyObject! let status = SecItemAdd(item as CFDictionary, &result) try Errors.throwIfError(osstatus: status) load() guard let secItem = result as? [String : Any], let persistentRef = secItem[kSecValuePersistentRef as String] as? Data else { throw Errors.malformedItem } let entry = PasswordEntry(id: persistentRef, username: username, hostname: hostname, password: password, comment: comment) return entry } (Note that I also tried it omitting kSecAttrAccessible, but it had no effect.) This code works fine if I omit setting kSecAttrAccessControl. Any ideas? TIA!

In one of my apps I would like to find out if users have their device set up to authenticate with their Apple Watch. According to the documentation (https://developer.apple.com/documentation/localauthentication/lapolicy/deviceownerauthenticationwithcompanion) this would be done by evaluating the LAPolicy like this: var error: NSError? var canEvaluateCompanion = false if #available(iOS 18.0, *) { canEvaluateCompanion = context.canEvaluatePolicy(.deviceOwnerAuthenticationWithCompanion, error: &error) } But when I run this on my iPhone 16 Pro (iOS 18.5) with a paired Apple Watch SE 2nd Gen (watchOS 11.5) it always returns false and the error is -1000 "No companion device available". But authentication with my watch is definitely enabled, because I regularly unlock my phone with the watch. Other evaluations of using biometrics just works as expected. Anything that I am missing?

Cannot find developer mode in iPhone 16. Please help me resolve this

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?

With Let's Encrypt having completely dropped support for OCSP recently [1], I wanted to ask if macOS has a means of keeping up to date with their CRLs and if so, roughly how often this occurs? I first observed an issue where a revoked-certificate test site, "revoked.badssl.com" (cert signed by Let's Encrypt), was not getting blocked on any browser, when a revocation policy was set up using the SecPolicyCreateRevocation API, in tandem with the kSecRevocationUseAnyAvailableMethod and kSecRevocationPreferCRL flags. After further investigation, I noticed that even on a fresh install of macOS, Safari does not block this test website, while Chrome and Firefox (usually) do, due to its revoked certificate. Chrome and Firefox both have their own means of dealing with CRLs, while I assume Safari uses the system Keychain and APIs. I checked cert info for the site here [2]. It was issued on 2025-07-01 20:00 and revoked an hour later. [1] https://letsencrypt.org/2024/12/05/ending-ocsp/ [2] https://www.ssllabs.com/ssltest/analyze.html?d=revoked.badssl.com

Hi everyone, I have a macOS application that uses Screen Recording permission. I build my app with an adhoc signature (not with a Developer ID certificate). For example, in version 1.0.0, I grant Screen Recording permission to the app. Later, I build a new version (1.1.0) and update by dragging the new app into the Applications folder to overwrite the previous one. However, when I launch the updated app, it asks for Screen Recording permission again, even though I have already granted it for the previous version. I don’t fully understand how TCC (Transparency, Consent, and Control) determines when permissions need to be re-granted. Can anyone explain how TCC manages permissions for updated builds, especially with adhoc signatures? Is there any way to retain permissions between updates, or any best practices to avoid having users re-authorize permissions after every update?