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.

Hi everyone, I’ve been working on an experimental prototype called FaceBridge that explores whether Secure Enclave–backed biometric authorization can be delegated between macOS and iPhone using only public Apple APIs. The goal of the project was to better understand the architectural boundaries of cross-device trust and approval flows that resemble Apple’s built-in Touch ID / Continuity authorization experiences. FaceBridge implements a local authorization pipeline where: macOS generates a signed authorization request the request is delivered to a trusted nearby iPhone over BLE / Network framework the iPhone verifies sender identity Face ID approval is requested using LocalAuthentication the iPhone signs the approval response using Secure Enclave–backed keys macOS validates the response and unlocks a protected action Security properties currently implemented: • Secure Enclave–backed signing identities per device • cryptographic device pairing and trust persistence • replay protection using nonce + timestamp binding • structured authorization request/response envelopes • signed responder identity verification • trusted-device registry model • local encrypted transport over BLE and local network This is intentionally not attempting to intercept or replace system-level Touch ID dialogs (App Store installs, Keychain prompts, loginwindow, etc.), but instead explores what is possible within application-level authorization boundaries using public APIs only. The project is open source: https://github.com/wesleysfavarin/facebridge Technical architecture write-up: https://medium.com/@wesleysfavarin/facebridge I’m particularly interested in feedback around: • recommended Secure Enclave identity lifecycle patterns • best practices for cross-device trust persistence • LocalAuthentication usage in delegated approval scenarios • whether similar authorization models are expected to become more formally supported across Apple platforms in the future Thanks in advance for any guidance or suggestions.

I’m considering storing some sensitive information in the userID field of a passkey, as described in the createCredentialRegistrationRequest method.(link to method). I'm aware of the largeBlob extension introduced in iOS 17+, but it doesn't meet my needs since I want to create a cross-platform passkey that can be used across various devices — and currently, not many devices support the largeBlob extension. According to W3C documentation, the userID field is not considered private information and can be displayed to the user without requiring a verification process. Based on my understanding, it's also not encrypted, which means it might be accessible with physical access to the device. So here are my questions: How do Apple devices (especially iPhones) handle the userID field in their authenticators? Is it possible to access the userID without user verification, as permitted by the W3C specification? Are there any alternative methods to access the userID value stored in a passkey on Apple devices?

Hi Forum, We’re building a security-focused SDK for iOS that includes SIM Binding and SIM Swap detection to help prevent fraud and unauthorised device access, particularly in the context of banking and fintech apps. We understand that iOS limits access to SIM-level data, and that previously available APIs (such as those in CoreTelephony, now deprecated from iOS 16 onwards) provide only limited support for these use cases. We have a few questions and would appreciate any guidance from the community or Apple engineers: Q1. Are there any best practices or Apple-recommended approaches for binding a SIM to a device or user account? Q2. Is there a reliable way to detect a SIM swap when the app is not running (e.g., via system callback, entitlement, or background mechanism)? Q3. Are fields like GID1, GID2, or ICCID accessible through any public APIs or entitlements (such as com.apple.coretelephony.IdentityAccess)? If so, what is the process to request access? Q4. For dual SIM and eSIM scenarios, is there a documented approach to identify which SIM is active or whether a SIM slot has changed? Q5. In a banking or regulated environment, is it possible for an app vendor (e.g., a bank) to acquire certain entitlements from Apple and securely expose that information to a security SDK like ours? What would be the compliant or recommended way to structure such a partnership? Thanks in advance for any insights!

We use Jamf Blueprint to deploy the managed app and identity to the iOS device (iOS 26.3 installed). Our managed app can access the identity via let identityProvider = ManagedAppIdentitiesProvider() let identity: SecIdentity do { identity = try await identityProvider.identity(withIdentifier: "myIdentity") } catch { } However, the app extension cannot access the same identity. Our app extension is notification extension that implemented UNNotificationServiceExtension APIs. We use above code in didReceive() function to access identity that always failed. The MDM configuration payload is: "AppConfig": { "Identities": [ { "Identifier": "myIdentity", "AssetReference": "$PAYLOAD_2" } ] }, "ExtensionConfigs": { "Identifier (com.example.myapp.extension)": { "Identities": [ { "Identifier": "myIdentity", "AssetReference": "$PAYLOAD_2" } ] } }, "ManifestURL": "https://example.net/manifest.plist", "InstallBehavior": { "Install": "Required" } } Is there any problem in our MDM configuration? Or the notification extension cannot integrate with ManagedApp FM?

Hello, I would like to seek clarification regarding the availability of the NFC Secure Element (SE) / ISO7816 entitlement by region, specifically for Indonesia. I recently contacted Apple Developer Support regarding the use of NFC for reading ISO7816-compatible cards. I was informed that, at this time, the NFC & Secure Element entitlement is not available in Indonesia. For technical planning and compliance purposes, I would like to confirm the following: Is the NFC Secure Element / ISO7816 entitlement currently restricted by region, and is Indonesia officially unsupported at this time? For apps distributed on the App Store in Indonesia, is Core NFC limited to NDEF and non–Secure Element tag reading only? Are there any publicly supported alternatives or recommended architectural approaches for NFC-based workflows in regions where the Secure Element entitlement is unavailable? Is there any public documentation or guidance that outlines regional availability for NFC Secure Element features? I understand that entitlement approvals and availability may vary by region and are handled on a case-by-case basis. Any clarification from Apple engineers or developers with experience in this area would be greatly appreciated. Thank you for your time and assistance. Best regards.

I’m having an issue with my Credential Provider Extension for passkey registration. On the browser I click on registration, in IOS i can select my App for passkey registration with a continue button. Wenn I click the continue button the prepareInterface(forPasskeyRegistration:) function is called but the MainInterface is not shown —it only appears when I click the continue button a second time. Here’s a simplified version of my prepareInterface method: override func prepareInterface(forPasskeyRegistration registrationRequest: ASCredentialRequest) { guard let request = registrationRequest as? ASPasskeyCredentialRequest, let identity = request.credentialIdentity as? ASPasskeyCredentialIdentity else { extensionContext.cancelRequest(withError: ASExtensionError(.failed)) return } self.identity = identity self.request = request log.info("prepareInterface called successfully") } In viewDidAppear, I trigger FaceID authentication and complete the registration process if register is true. However, the UI only shows after a second “Continue” tap. Has anyone encountered this behavior or have suggestions on how to ensure the UI appears immediately after prepareInterface is called? Could it be a timing or lifecycle issue with the extension context? Thanks for any insights!

I am developing a Flutter iOS application and encountering a crash when using biometric authentication (Face ID) via the local_auth plugin. ■ Environment Flutter: 3.x local_auth: 2.2.0 (also tested with 2.1.6) iOS: real device (Face ID is working normally for device unlock) Firebase Authentication (email/password) Xcode build ■ Issue When calling biometric authentication, the app crashes immediately. Code: final didAuthenticate = await auth.authenticate( localizedReason: 'Authenticate to login', options: const AuthenticationOptions( biometricOnly: false, useErrorDialogs: false, ), ); ■ Error Thread 1: signal SIGABRT Crash occurs in libsystem_kernel.dylib (__pthread_kill) Happens immediately when authenticate() is called No exception is caught in Dart (native crash) ■ Verified NSFaceIDUsageDescription is correctly included in Info.plist Confirmed it exists in the built Runner.app Info.plist localizedReason is non-empty and in English Flutter clean / pod install executed App reinstalled on device Face ID works normally outside the app ■ Question Under what conditions does LAContext.evaluatePolicy trigger SIGABRT instead of returning an error? Are there known issues with presenting biometric authentication UI in certain UI states (e.g., view controller hierarchy, scene lifecycle)? Could this be related to UIScene / rootViewController issues? What is the correct timing and context to call biometric authentication safely in iOS apps? I suspect this is related to native iOS behavior rather than Flutter logic. Any guidance would be appreciated.

Hi. I enter a password using the security command at the command line. It appears in the keychain access app, but not in the passwords app. I don't understand why. rickhedin@Ricks-MacBook-Pro zalando % security add-generic-password -U -s "birds" -a "cats" -w "dogs" rickhedin@Ricks-MacBook-Pro zalando % rickhedin@Ricks-MacBook-Pro zalando % security find-generic-password -s "birds" -wa "cats" dogs rickhedin@Ricks-MacBook-Pro zalando % I'm told the two apps are two views of the same data, so I guess some filter must be being applied?

I'm using Secure Enclave to generate and use a private key like this: let access = SecAccessControlCreateWithFlags(nil, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, [.privateKeyUsage, .biometryAny], nil) let attributes: [String: Any] = [ kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom, kSecAttrKeySizeInBits as String: 256, kSecAttrTokenID as String: kSecAttrTokenIDSecureEnclave, kSecAttrAccessControl as String: access as Any, kSecAttrApplicationTag as String: "com.example.key".data(using: .utf8)!, kSecReturnRef as String: true ] let privateKey = SecKeyCreateRandomKey(attributes as CFDictionary, nil) Later, I use this key to sign a message: let signature = SecKeyCreateSignature(privateKey, .ecdsaSignatureMessageX962SHA256, dataToSign as CFData, nil) This prompts for biometric authentication, but shows the default system text. How can I customize or localize the biometric prompt (e.g., title, description, button text) shown during SecKeyCreateSignature? Thanks!

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

We are using Apple's PSSO to federate device login to out own IdP. We have developed our own extension app and deployed it using MDM. Things works fine but there are 2 issues that we are trying to get to the root cause - On some devices after restarting we see an error message on the logic screen saying "The registration for this device is invalid and must be repaired" And other error message is "SmartCard configuration is invalid for this account" For the 1st we have figured out that this happens when the registration doesn't happen fully and the key is not tied to the user so when the disk needs to be decrypted at the FileVault screen the issue is raised. For the "SmartCard configuration is invalid for this account" issue also one aspect is invalid registration but there has been other instances as well where the devices were registered completely but then also the the above error was raised. We verified the registration being completed by checking if the SmartCard is visible in the System Report containing the key. Has anyone seen the above issues and any possible resolution around it?

override func prepareInterface(forPasskeyRegistration registrationRequest: any ASCredentialRequest) int this function how can i get the "challenge" from user agent, the params "challenge" need to be used in webauthn navigator.credentials.create

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.

Hello everyone, I'm working on a project where I intend to use Secure Enclave-based, device-bound private keys within a Webauthn flow. I have the following question: Is it possible to generate private keys in the Secure Enclave with integrated attestation in order to reliably prove to a relying party the authenticity and uncompromised state of the key? If so, I would appreciate details on the implementation—specifically, any prerequisites, limitations, or particular API calls and configuration options that need to be considered. I look forward to any advice, best practices, or pointers to further documentation on this topic. Thank you in advance for your support! Best regards, Alex

I have a custom NSWindow that I want to exclude from screen capture by setting its sharing state to kCGWindowSharingStateSharingNone. The goal is to prevent this window from appearing in the content captured by ScreenCaptureKit. [window setSharingType:NSWindowSharingType::NSWindowSharingNone]; However, on macOS 15.4+ (Sequoia), the window is still captured by ScreenCaptureKit and appears in the shared content. Does anyone know if kCGWindowSharingStateSharingNone is still effective with ScreenCaptureKit on macOS 15.4 and later?

Like many/most developers, I gave Connect the info required to comply with the DSA. Perhaps unlike most, I always give unique email addresses so that I can easily track the source of abuse. Yesterday I finally had a phish come in to my DSA address claiming "Message blocked" and doing the standard click-to-login-for-details FOMO bait. So, yep, DSA just becomes yet another public database that malicious actors can use to target you. It would be really nice if Apple provided a way to supply our contact info only for legitimate business purposes. Mail Privacy Protection (or similar) for this would be a start.

I want iOS device identifier for a framework that is used in multiple vendor's apps. I'm developing a framework to control a peripheral. The framework has to send unique information to register the device with the peripheral. My naive idea was to use IdentifierForVendor. But this API provides the device identifier for the same vendor's apps, not the framework. (The framework will be used by multiple vendors.) Is there a usable device identifier for the framework, regardless of app vendor? Please tell me any solution.

I downloaded a P12 file (containing a private key) from the company server, and retrieved the private key from this P12 file using a password : private func loadPrivateKeyFromPKCS12(path: String, password: String) throws -> SecKey? { let p12Data: Data do { p12Data = try Data(contentsOf: fileURL) } catch let readError { ... } let options: [CFString: Any] = [ kSecImportExportPassphrase: password as CFString ] var items: CFArray? let status = SecPKCS12Import(p12Data as CFData, options as CFDictionary, &items) guard status == errSecSuccess else { throw exception } var privateKey: SecKey? let idd = identity as! SecIdentity let _ = SecIdentityCopyPrivateKey(idd, &privateKey) return privateKey } However, when I use this private key to call SecKeyCreateSignature for data signing, a dialog box always pops up to ask user to input the Mac admin password. What confuses me is that this private key is clearly stored in the local P12 file, and there should be no access to the keychain involved in this process. Why does the system still require the user's login password for signing? Is it possible to perform silent signing (without the system dialog popping up) in this scenario?

I am developing a macOS system service (standalone binary running as a LaunchDaemon) that requires the ability to sign data using a private key which will be deployed via MDM. The Setup: Deployment: A .mobileconfig pushes a PKCS12 identity to the System Keychain. Security Requirement: For compliance and security reasons, we cannot set AllowAllAppsAccess to <true/>. The key must remain restricted. The Goal: I need to use the private key from the identity to be able to sign the data The Problem: The Certificate Payload does not support a TrustedApplications or AccessControl array to pre-authorize binary paths. As a result, when the process tries to use the private key for signing (SecKeyCreateSignature), it prompts the user to allow this operation which creates a disruption and is not desired. What i've tried so far: Manually adding my process to the key's ACL in keychain access obviously works and prevents any prompts but this is not an "automatable" solution. Using security tool in a script to attempt to modify the ACL in an automated way, but that also asks user for password and is not seamless. The Question: Is there a documented, MDM-compatible way to inject a specific binary path into the ACL of a private key? If not, is there a better way to achieve the end goal?