General: Forums topic: Privacy & Security Privacy Resources Security Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Team, its been observed that, there are some Spam calls which triggers the face recognitions and disappear within few seconds, what i mean is that while you see at screen who is calling the facial recognition scans your face… i had this episodes many times..

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 using a custom Installer plug-in (InstallerPane) to collect sensitive user input (username/password) during install. After the payload is laid down, I need to send those values to a newly installed agent (LaunchAgent) to persist them. What I tried I expose an XPC Mach service from the agent and have the plug-in call it. On the agent side I validate the XPC client using the audit token → SecCodeCopyGuestWithAttributes → SecCodeCheckValidity. However, the client process is InstallerRemotePluginService-* (Apple’s view service that hosts all plug-ins), so the signature I see is Apple’s, not mine. I can’t distinguish which plug-in made the call. Any suggestion on better approach ?

Hello everyone, I'm encountering a persistent 503 Server Temporarily Not Available error when trying to implement "Sign in with Apple" for my web application. I've already performed a full review of my configuration and I'm confident it's set up correctly, which makes this server-side error particularly confusing. Problem Description: Our web application uses Firebase Authentication to handle the "Sign in with Apple" flow. When a user clicks the sign-in button, they are correctly redirected to the appleid.apple.com authorization page. However, instead of seeing the login prompt, the page immediately displays a 503 Server Temporarily Not Available error. This is the redirect URL being generated (with the state parameter truncated for security): https://appleid.apple.com/auth/authorize?response_type=code&client_id=XXXXXX&redirect_uri=https%3A%2F%2FXXXXXX.firebaseapp.com%2F__%2Fauth%2Fhandler&state=AMbdmDk...&scope=email%20name&response_mode=form_post Troubleshooting Steps Performed: Initially, I was receiving an invalid_client error, which prompted me to meticulously verify every part of my setup. I have confirmed the following: App ID Configuration: The "Sign in with Apple" capability is enabled for our primary App ID. Services ID Configuration: We have a Services ID configured specifically for this. The "Sign in with Apple" feature is enabled on this Services ID. The domain is registered and verified under "Domains and Subdomains". Firebase Settings Match Apple Settings: The Services ID from Apple is used as the Client ID in our Firebase configuration. The Team ID is correct. We have generated a private key, and both the Key ID and the .p8 file have been correctly uploaded to Firebase. The key is not revoked in the Apple Developer portal. Since the redirect to Apple is happening with the correct client_id and redirect_uri, and the error is a 5xx server error (not a 4xx client error like invalid_client), I believe our configuration is correct and the issue might be on Apple's end. This has been happening consistently for some time. My Questions: What could be causing a persistent 503 Server Temporarily Not Available error on the /auth/authorize endpoint when all client-side configurations appear to be correct? What is the formal process for opening a technical support ticket (TSI) directly with Apple Developer Support for an issue like this? Thank you for any insights or help you can provide.

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 everyone, I'm experiencing an intermittent issue with Keychain data loss on the latest iOS Beta 2. In about 7% of cases, users report that previously saved Keychain items are missing when the app is relaunched — either after a cold start or simply after being killed and reopened. Here are the key observations: The issue occurs sporadically, mostly once per affected user, but in 3 cases it has happened 4 times. No explicit deletion is triggered from the app. No system logs or error messages from Apple indicate any Keychain-related actions. The app attempts to access Keychain items, but they are no longer available. This behavior is inconsistent with previous iOS versions and is not reproducible in development environments. This raises concerns about: Whether this is a bug in the beta or an intentional change in Keychain behavior. Whether this could affect production apps when the final iOS version is released. The lack of any warning or documentation from Apple regarding this behavior. Has anyone else encountered similar issues? Any insights, workarounds, or official clarification would be greatly appreciated. Thanks!

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 added a feature to my app that retrieves only app settings (no personal data) from my API hosted on Cloudflare Workers. The app does not send, collect, track, or share any user data, and I do not store or process any personal information. Technical details such as IP address, user agent, and device information may be automatically transmitted as part of the internet protocol when the request is made, but my app does not log or use them. Cloudflare may collect this information. Question: Does this count as “data collection” for App Store Connect purposes, or can I select “No Data Collected”?

Testing my security agent plugin on Tahoe and find that when unlocking the screen, I now get an extra window that pops up over the SFAuthorizationPluginView that says "macOS You must enter a password to unlock the screen" with a Cancel (enabled) and OK button (disabled). See the attached photo. This is new with Tahoe. When unlocking the screen, I see the standard username and password entry view and I enter my password and click OK. That is when this new view appears. I can only click cancel so there is no way to complete authenticating.

Hi, I followed step by step documentation to implement SignIn with Apple in iOS/Android application. I created an AppId com.nhp.queenergy, a related ServiceId com.nhp.queenergy.apple, and a KeyId. Authorization request is correctly performed by using ServiceId as client_id and my backend redirect_uri I receive code on my backend Token request is performed by using ServiceId as client_id, same redirect_uri, the code I have just received and the client_secret as JWT signed with my .p8 certificate with the following decoded structure Header { "kid": , "typ": "JWT", "alg": "ES256" } Payload { "iss": , "sub": "com.nhp.queenergy.apple", "aud": "https://appleid.apple.com", "exp": 1756113744, "iat": 1756111944 } I always receive "invalid_grant" error without any further error description. Moreover the error is always the same even though I use any fake string as client secret. If the code expires, as expected the error changes by adding "The code has expired or has been revoked." I really don't know how to solve this issue Best regards

Private relay emails are not being delivered, even though we've followed the guidance here, https://developer.apple.com/help/account/capabilities/configure-private-email-relay-service/ iCloud, gmail etc. get delivered fine but as soon as its a private relay email address they get bounced as unauthorized sender. We've tried a couple of domains but here I'll document test.x.domain.com We have registered domains (test.x.domain.com), also the sender communication emails just to be safe (noreply at test.x.domain.com). Passed SPF Authentication, DKIM Authentication. ESP account shows as all green checks in mailgun. Is there any way to track down what the actual rejection reason is? { "@timestamp": "2025-08-20T14:30:59.801Z", "account": { "id": "6425b45fb2fd1e28f4e0110a" }, "delivery-status": { "attempt-no": 1, "bounce-type": "soft", "certificate-verified": true, "code": 550, "enhanced-code": "5.1.1", "first-delivery-attempt-seconds": 0.014, "message": "5.1.1 <bounce+b53c9e.27949-6qj4xaisn4k=privaterelay.appleid.com@test.x.domain.com>: unauthorized sender", "mx-host": "smtp3.privaterelay.appleid.com", "session-seconds": 1.7229999999999999, "tls": true }, "domain": { "name": "test.x.domain.com" }, "envelope": { "sender": "noreply@test.x.domain.com", "sending-ip": "111.22.101.215", "targets": "6qj4xaisn4k@privaterelay.appleid.com", "transport": "smtp" }, "event": "failed", "flags": { "is-authenticated": true, "is-delayed-bounce": false, "is-routed": false, "is-system-test": false, "is-test-mode": false }, "id": "1gtVBeZYQ0yO1SzipVP99Q", "log-level": "error", "message": { "headers": { "from": "\"Test Mail\" <noreply@test.x.domain.com>", "message-id": "20250820143058.7cac292cf03993f2@test.x.domain.com", "subject": "Test Mail", "to": "6qj4xaisn4k@privaterelay.appleid.com" }, "size": 22854 }, "primary-dkim": "s1._domainkey.test.x.domain.com", "reason": "generic", "recipient": "6qj4xaisn4k@privaterelay.appleid.com", "recipient-domain": "privaterelay.appleid.com", "recipient-provider": "Apple", "severity": "permanent", "storage": { "env": "production", "key": "BAABAgFDX5nmZ7fqxxxxxxZNzEVxPmZ8_YQ", "region": "europe-west1", "url": [ "https://storage-europe-west1.api.mailgun.net/v3/domains/test.x.domain.com/messages/BAABAgFDXxxxxxxxxxxxxxNzEVxPmZ8_YQ" ] }, "user-variables": {} }

Hello, We recently implemented SSL pinning in our iOS app (Objective-C) using the common approach of embedding the server certificate (.cer) in the app bundle and comparing it in URLSession:didReceiveChallenge:. This worked fine initially, but when our backend team updated the server certificate (same domain, new cert from CA), the app immediately started failing because the bundled certificate no longer matched. We’d like to avoid shipping and updating our app every time the server’s certificate changes. Instead, we are looking for the Apple-recommended / correct approach to implement SSL pinning without embedding the actual certificate file in the app bundle. Specifically: . Is there a supported way to implement pinning based on the public key hash or SPKI hash (like sha256/... pins) rather than the full certificate? . How can this be safely implemented using NSURLSession / SecTrustEvaluate (iOS 15+ APIs, considering that SecTrustGetCertificateAtIndex is deprecated)? . Are there Apple-endorsed best practices for handling certificate rotation while still maintaining strong pinning? Any guidance or code samples would be greatly appreciated. We want to make sure we are following best practices and not relying on brittle implementations. Thanks in advance!

Hi all, I’m building a password manager app for iOS. The app implements an ASCredentialProviderExtension and has the entitlement com.apple.developer.authentication-services.autofill-credential-provider. From a UX perspective, I’d like to help users enable my app under: Settings → General → AutoFill & Passwords What I’ve observed: Calling UIApplication.openSettingsURLString only opens my app’s own Settings page, not the AutoFill list. Some apps (e.g. Google Authenticator) appear to redirect users directly into the AutoFill Passwords & Passkeys screen when you tap “Enable AutoFill.” 1Password goes even further: when you tap “Enable” in 1Password App, it shows a system pop-up, prompts for Face ID, and then enables 1Password as the AutoFill provider without the user ever leaving the app. Questions: Is there a public API or entitlement that allows apps to deep-link users directly to the AutoFill Passwords & Passkeys screen? Is there a supported API to programmatically request that my app be enabled as an AutoFill provider (similar to what 1Password seems to achieve)? If not, what is the recommended approach for guiding users through this flow? Thanks in advance!

Hello, I am unable to configure Sign in with Apple on my developer account. Whenever I try to: Enable/disable the Sign in with Apple capability in my App ID, or Configure a Service ID for web authentication, the portal does not save my changes. In the browser developer console, I consistently see this error: Request URL: https://developer.apple.com/services-account/v1/bundleIds/XXXXXXXX Request Method: PATCH Status Code: 501 Not Implemented This happens across all browsers (Safari, Chrome, Incognito) and even after clearing cache. It affects my entire account, not just one App ID. I have already tried: Creating a new Service ID → still fails. Creating a new App ID → still fails. Re-enabling the capability → save does not work. Different browsers and devices → same result. Has anyone else experienced this issue, and is there a known fix? Or is this something that Apple Developer Support needs to resolve at the account level?

Using the SDK, I've printed out some log messages when I enter the wrong password: 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] invoke 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] general: 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] progname: 'SecurityAgentHelper-arm64' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] OS version: 'Version 15.5 (Build 24F74)' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] pid: '818' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] ppid: '1' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] euid: '92' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] uid: '92' 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] session: 0x186e9 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] attributes: 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] is root: f 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] has graphics: t 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] has TTY: t 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] is remote: f 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] auth session: 0x0 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] context: 2025-08-20 15:58:14.088 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] authentication-failure: --S -14090 2025-08-20 15:58:14.088 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] pam_result: X-S 9 2025-08-20 15:58:14.089 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] hints: 2025-08-20 15:58:14.089 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] authorize-right: "system.login.console" 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-path: "/System/Library/CoreServices/loginwindow.app" 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-pid: 807 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-type: 'LDNB' 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-uid: 0 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] creator-audit-token: 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ................ 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] 00 00 00 00 27 03 00 00 e9 86 01 00 68 08 00 00 ....'.......h... 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] creator-pid: 807 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] flags: 259 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] reason: 0 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] tries: 1 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] immutable hints: 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-apple-signed: true 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-firstparty-signed: true 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] creator-apple-signed: true 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] creator-firstparty-signed: true 2025-08-20 15:58:14.091 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] arguments: 2025-08-20 15:58:14.091 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] none 2025-08-20 15:58:14.108 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] LAContext: LAContext[4:8:112] 2025-08-20 15:58:14.119 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] token identities: 0 2025-08-20 15:58:14.120 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] token watcher: <TKTokenWatcher: 0x11410ee70> Specifically, is there a manual/link somewhere that can allow me to interpret: authentication-failure: --S -14090 and pam_result: X-S 9

Hi everyone, I’m working on adapting our app to iOS 26’s new passkey feature, specifically Automatic Passkey Upgrades. https://developer.apple.com/videos/play/wwdc2025/279/ Our app already supports passkey registration and authentication, which have been running reliably in production. We’d like to extend passkey coverage to more users. According to the WWDC session, adding the parameter requestStyle: .conditional to createCredentialRegistrationRequest should allow the system to seamlessly upgrade an account with a passkey. However, in my testing, I consistently receive the following error: Error | Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)" Test environment: Xcode 26.0 beta 4 (17A5285i) iPhone 11 running iOS 26.0 (23A5297n) Questions: Is the Automatic Passkey Upgrades feature currently available in iOS 26? I understand that the system may perform internal checks and not all upgrade attempts will succeed. However, during development, is there a way to obtain more diagnostic information? At the moment, it’s unclear whether the failure is due to internal validation or an issue with my code or environment. Thanks.

Has anybody else experienced something similar? This is on the login screen. I call update() and it doesn't call me back with view() 2025-08-21 17:04:38.669 Db SecurityAgentHelper-arm64[1134:2df1] [***:LoginView] calling update() Then silence...

Hey folks, I'm seeing an issue where my iOS app is getting an "unknown" error when US users try to sign in with Apple. It works fine for users in other countries like the UK, Singapore, and Taiwan. Could it be related to my developer account not being based in the US? Or have I missed something in my settings? Thanks in advance!

Hi Apple Devs, For our app, we utilize passkeys for account creation (not MFA). This is mainly for user privacy, as there is 0 PII associated with passkey account creation, but it additionally also satisfies the 4.8: Login Services requirement for the App Store. However, we're getting blocked in Apple Review. Because the AASA does not get fetched immediately upon app install, the reviewers are not able to create an account immediately via passkeys, and then they reject the build. I'm optimistic I can mitigate the above. But even if we pass Apple Review, this is a pretty catastrophic issue for user security and experience. There are reports that 5% of users cannot create passkeys immediately (https://developer.apple.com/forums/thread/756740). That is a nontrivial amount of users, and this large of an amount distorts how app developers design onboarding and authentication flows towards less secure experiences: App developers are incentivized to not require MFA setup on account creation because requiring it causes significant churn, which is bad for user security. If they continue with it anyways, for mitigation, developers are essentially forced to add in copy into their app saying something along the lines of "We have no ability to force Apple to fetch the config required to continue sign up, so try again in a few minutes, you'll just have to wait." You can't even implement a fallback method. There's no way to check if the AASA is available before launching the ASAuthorizationController so you can't mitigate a portion of users encountering an error!! Any app that wants to use the PRF extension to encrypt core functionality (again, good for user privacy) simply cannot exist because the app simply does not work for an unspecified amount of time for a nontrivial portion of users. It feels like a. Apple should provide a syscall API that we can call to force SWCD to verify the AASA or b. implement a config based on package name for the app store such that the installation will immediately include a verified AASA from Apple's CDN. Flicking the config on would require talking with Apple. If this existed, this entire class of error would go away. It feels pretty shocking that there isn't a mitigation in place for this already given that it incentivizes app developers to pursue strictly less secure and less private authentication practices.