Hi everyone, I'm integrating WeatherKit into an app for users in Mainland China, and I have a data residency question I haven't been able to resolve from the documentation. To fetch weather data, the app sends the user's precise latitude/longitude to WeatherKit. Under China's Personal Information Protection Law (PIPL), precise geolocation is personal information, and cross-border transfers are strictly regulated — so I need to understand where this data actually goes. While testing on Android (REST API), I captured the outbound request and it connected to an IP that appears to be located in Mainland China. That's encouraging, but a single edge/CDN IP doesn't prove the data stays in-country — it could still be forwarded to or accessed from servers outside Mainland China. My questions: When a request originates from Mainland China, does WeatherKit process and store the latitude/longitude within Mainland China, or is it transferred/accessible outside? Does WeatherKit have a data localization deployment for Mainland China (similar to how iCloud is operated locally there)? Is there any official documentation on WeatherKit's data residency and request logging (IP, coordinates, retention period)? If anyone from Apple or the community has insight — or can point me to the right documentation — I'd really appreciate it. Thanks!

macOS 27.0 beta 4 I have an installer app which needs to set a key/value inside a plist file during installation. This is for a screensaver that runs under the legacyScreensaver system, so the plist lives at: ~/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver.x86-64/Data/Library/Preferences/com.foobar.plist Although I can see the plist file in the Finder, my installer app can't read or write it, and the NSAppDataUsageDescription string is not shown, nor does the OS ask the user for permission. Also, trying to do this via the Terminal app is also blocked (even using 'sudo'). I understand this is part of the new Golden Gate security system. In Golden Gate, is there a legitimate way to accomplish this so it works like it did in macOS 26 and earlier? I'd like my installer to request access, the NSAppDataUsageDescription string is shown, and the user can grant or deny permission.

I'm seeing a behavior difference in CGWindowListCopyWindowInfo between macOS 26 Tahoe and macOS 27 Golden Gate beta regarding the Screen Recording / System Audio Recording privacy permission, and I'd like to confirm whether this is intentional or a beta regression. Environment macOS 26 Tahoe (26.x) — tested behavior below macOS 27 Golden Gate beta 4 (26A5388g) — tested behavior below Expected behavior (matches Tahoe) When my app does NOT have permission under System Settings > Privacy & Security > Screen & System Audio Recording: CGWindowListCopyWindowInfo still returns window list entries for other running apps. However, kCGWindowOwnerName for windows owned by processes other than my own app is nil. When permission IS granted, kCGWindowOwnerName is populated correctly for all windows. Actual behavior on Golden Gate Even without Screen Recording permission granted (verified in System Settings, and via CGPreflightScreenCaptureAccess() returning false), kCGWindowOwnerName is populated for windows owned by other running apps — i.e., the same as if permission had been granted. Repro swift let options: CGWindowListOption = [.optionOnScreenOnly, .excludeDesktopElements] let windowList = CGWindowListCopyWindowInfo(options, kCGNullWindowID) as? [[String: AnyObject]] for window in windowList ?? [] { let owner = window[kCGWindowOwnerName as String] as? String print(owner ?? "nil") } On Tahoe without permission: prints nil for other apps' windows. On Golden Gate beta 4 without permission: prints the actual owner name for other apps' windows. Question Is this a known/intentional change in Golden Gate, or a beta regression in the TCC enforcement path for this API? Since Apple has been steadily tightening screen-capture-adjacent APIs (Sonoma/Sequoia/Tahoe) and recommending migration to ScreenCaptureKit, should we treat any reliance on kCGWindowOwnerName's permission-gated nil behavior as unsupported going forward, and use a different API to check whether the process has Screen Recording access? Any guidance from DTS would be appreciated. Happy to file a Feedback Assistant report with a sample project if useful — let me know the FB number format expected.

We have an application (macOS) which opens an ASWebAuthenticationSession window to prompt the user for credentials. This works well, except for there are times when the window is opened behind other windows - and the user does not see that they are being prompted for authentication. Is there some way to force this window to be always-on-top or at the very least, to bring it to the foreground on top of other windows (including other browser windows from the same default system browser).

Hi everyone, We're migrating our iOS app from Auth0 custom scheme callbacks to HTTPS Universal URLs using ASWebAuthenticationSession. We've configured everything correctly, but webcredentials only works when using ?mode=developer suffix in our entitlements, which is not allowed for App Store submissions. The Issue Without ?mode=developer: Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=1 "Application with identifier com.example.myapp is not associated with domain auth.example.com. Using HTTPS callbacks requires Associated Domains using the webcredentials service type for auth.example.com." With ?mode=developer: webcredentials:auth.example.com?mode=developer Works perfectly! Questions Why does it work with ?mode=developer but not without it, even though Apple's CDN has the correct AASA? Is there a way to force iOS to re-verify associated domains without requiring users to delete and reinstall? How will this affect existing users who update the app? Will they need to reinstall? Is there a known propagation delay beyond the CDN showing correct data? Any guidance would be greatly appreciated. We cannot ship to the App Store with ?mode=developer, but without it, the authentication fails. Thank you!

I am seeing recurring DCError.invalidKey in my iOS app using App Attest, and I'am trying to determine whether throttling or a quota can be a contributing factor before we look further. Questions Are there rate limits or quotas on generateKey, attestKey, or generateAssertion — scoped per device, per key, or per app? I understand exact thresholds may not be published; what I'd mainly like to know is whether such limits exist and roughly what timing window they apply over. If a limit is hit, which error surfaces? Specifically, can throttling ever present as DCError.invalidKey, or would it always be serverUnavailable (or another distinct code)? Does calling the attestation flow repeatedly in a short window (e.g. several times within a few minutes from an onboarding sequence) risk triggering throttling or anti-abuse rejection? Am I right that generateAssertion is entirely on-device and therefore not subject to any server-side limit — i.e. only attestKey contacts Apple's servers? Is throttling one of the documented causes of invalidKey, or is invalidKey strictly a key-state error (key absent from the Secure Enclave, already attested, from a prior install, etc.)? Being able to rule throttling in or out would help us narrow the investigation considerably. Thanks.

Hello, We have an enterprise application that provides a security agent plugin with custom UI based on SFAuthorizationPluginView. We’ve been testing it on macOS 27 Developers Betas 1 through 4 and we noticed that if we set screenUnlockMode to 2, then after a screen is locked for the second time during one session, it can no longer be unlocked. Here are the concrete steps to reproduce: Open Terminal. Run sudo defaults write /Library/Preferences/com.apple.loginwindow.plist screenUnlockMode -int 2 Lock the screen. Observe the “You must enter the password to unlock the screen” dialog window. Enter the correct password and press OK. Lock the screen again. Expected result: The dialog “You must enter the password to unlock the screen” is displayed again. Entering the correct password unlocks the screen. Actual result: The screen is black with no visible UI. Rebooting the system seems to be the only way to leave this state. Displaying custom UI at the unlock screen is a part of our core functionality and it has been working fine with screenUnlockMode = 2 since at least macOS 14. I have filed a feedback FB23918474; if it is a known issue, please merge it with mine so that I can receive updates on the matter. In the meantime, do you have any suggestions on what can be done? Thanks.

I am developing a macOS solution that exposes a cloud-backed digital signing credential as a system identity through a persistent CryptoTokenKit token extension. My main goal is to allow third-party macOS applications, especially Adobe Acrobat, to discover the signing identity through the standard macOS Keychain infrastructure and use it for signing PDF documents. Intended signing flow The flow I am trying to implement is: The user adds a cloud signing credential in my macOS container application. My application retrieves the certificate and credential metadata from a remote signing service using the CSC protocol. My application creates or updates the persistent CryptoTokenKit token configuration. The CryptoTokenKit extension exposes the certificate and its associated private-key capability as a macOS system identity. The user opens a PDF document in Adobe Acrobat and starts a digital signature operation. Adobe Acrobat discovers the identity through the standard macOS certificate and Keychain selection flow. The signing request is routed to my CryptoTokenKit token extension. My extension forwards the signing request to the remote CSC signing service and returns the resulting signature. The private key is held by the remote signing infrastructure. It is never stored or exported locally. Environment macOS 26.4.1 (25E253) Xcode 26.4.1 (17E202) Swift Persistent Token Extension created from the Xcode template macOS container application Apple silicon Mac Current implementation issue I have built a prototype consisting of a macOS container application and a persistent CryptoTokenKit token extension. While managing the persistent token configuration, I encountered a reproducible issue with TKTokenDriver.Configuration.driverConfigurations. When I access this API from the container application process, the operation can block indefinitely without returning an error. I tested different threads and dispatch queues, but the behavior remained the same. However, when I execute the same configuration operation from a newly launched helper XPC process, it completes successfully. At this stage, I would first like to confirm that the overall architecture is correct before submitting detailed code and reproduction steps. Questions Is a persistent CryptoTokenKit token extension the Apple-supported architecture for exposing a cloud-backed signing credential as a macOS system identity? What is the recommended Apple-supported pattern for creating and updating persistent TKTokenDriver.Configuration entries? Should this be done directly by the container application, or is a separate process expected? Is there any official Apple sample project or technical guidance covering persistent CryptoTokenKit tokens, network-backed signing and consumption by third-party applications? I have a focused test project and can provide minimal code, logs, process samples and detailed reproduction steps if they are useful. Any architectural guidance, sample code or experience with a similar Adobe Acrobat signing flow would be greatly appreciated. Thank you!

On a physical device, the native Sign in with Apple sheet fails INSTANTLY with ASAuthorizationError.unknown (code 1000) — before any Apple account UI appears. It fails for every Apple ID we try. The app shows "Sign Up Not Completed". App ID: brp.sohsostory.app · Team: JZZUYHU3UU (a newly enrolled account) Already verified (config looks fully correct): "Sign in with Apple" capability is ENABLED on the App ID (Primary App consent), confirmed in both the Developer portal and via the App Store Connect API. The active distribution provisioning profile includes com.apple.developer.applesignin, and the built binary carries the entitlement. Program License Agreement is accepted. The SAME client code + backend works on a DIFFERENT (older) team's app, so this looks specific to this App ID / team — as if a server-side activation for a new team never completed. Questions: For a newly enrolled team, is there a known activation delay before Sign in with Apple starts working, and how long? Is there any additional step required to "activate" the capability beyond enabling it on the App ID and regenerating the profile? Has anyone resolved ASAuthorizationError.unknown that persisted for days on a new team? Environment: iOS (physical device), React Native / Expo, backend uses Apple as an OpenID provider (Supabase Auth).

Our app can no longer complete native Sign in with Apple: the system sheet appears, the user authenticates (Face ID / password succeeds), and the sheet then fails before any credential is returned to the app. Console shows AKAuthenticationError -7003 from the AppleAccount/AuthorizationServices stack. Details: App: "Antes y Después: Fotos" — bundle ID com.jpbaldi.antesydespues, live on the App Store Team ID: PZDWZHXF9V (individual membership) Implementation: ASAuthorizationController (via expo-apple-authentication), scopes full name + email; the identityToken is exchanged with our backend (Supabase). The failure happens inside the native sheet, before any token is issued. Reproducible across devices, networks and Apple IDs — and App Review reproduced it too: our build was rejected under 2.1(a) because the reviewer hit the same failure. It does not look device- or account-specific. What we've already tried, with no change: Removed and re-added the Sign in with Apple capability on the App ID in Certificates, Identifiers & Profiles, regenerated provisioning profiles, rebuilt and resubmitted. Verified com.apple.developer.applesignin (Default) is present in the shipped binary's entitlements. Fresh devices, different Apple IDs, different networks. As a workaround we shipped v1.0 with Sign in with Apple disabled (email/password only), so guideline 4.8 doesn't apply — but we want to restore it. Since -7003 appears to be returned server-side for our client ID rather than by anything in the app, is there any account-side registration state for the App ID that can be checked or reset? Has anyone resolved this exact error without creating a new App ID (not viable for a shipped app)? Feedback Assistant: FB23890204 (sysdiagnose + screen recording attached) Developer Support case ref: 102944296016

Sign in with Apple consistently fails with the sheet error "Sign up not completed" for every user and device we have tested. The authorization sheet presents correctly (name/email choices are shown); the failure happens on completion, so no credential is returned to the app. We have eliminated all client-side and account-side causes and believe this is a server-side registration issue with our App ID, matching previously reported cases that were ultimately fixed on Apple's side (forums threads 716252, 122458, 750633). App details: Team ID: Q7BH7CYU67 Client ID (Bundle ID): com.hohomom.baby (App ID resource id RN35DS29UD) Native flow: ASAuthorizationController identity token verified via Firebase signInWithCredential; audience = the bundle ID (no web Services ID involved) Distribution: TestFlight (external), build 1.0 (1784386654) Feedback Assistant report (with sysdiagnose + akd log): FB23839922 Developer Support case: 102946147992 What we verified (all pass): Delivered IPA binary entitlements: com.apple.developer.applesignin = [Default] (via codesign -d --entitlements). Embedded provisioning profile carries the same entitlement (via security cms -D). Signed with a fresh App Store profile created after a capability reset. Developer portal: App ID has APPLE_ID_AUTH enabled as primary (APPLE_ID_AUTH_APP_CONSENT: PRIMARY_APP_CONSENT). We also disabled/re-enabled the capability and rebuilt — no change. Every embedded target now has the entitlement too — we found and fixed a bundled Controls app-extension (com.hohomom.baby.Controls) that was missing the Sign in with Apple entitlement, added it, rebuilt and re-uploaded. Still fails. App Store Connect: no pending agreements. Apple System Status: Sign in with Apple operational at test time. The tester's Apple ID and device are fine: Sign in with Apple works in third-party apps from other teams on the same device. Device-side: rebooted the iPhone and retried on both Wi-Fi and LTE — same failure. Device log evidence (log collect during a failed attempt): at the moment of the attempt, a freshly spawned akd repeatedly fails to fetch the GrandSlam configuration: akd [com.apple.authkit:core] Bag fetch failed! Error Domain=NSURLErrorDomain Code=-1008 URL: https://gsa.apple.com/grandslam/GsService2/lookup/v2 (x4 consecutive) Could an Apple engineer please check the server-side Sign in with Apple registration state for Team Q7BH7CYU67 / com.hohomom.baby and repair or re-provision it? Full details, the affected Apple ID email, and a sysdiagnose are in FB23839922. This is currently blocking our App Store submission (guideline 4.8). Thank you.

How can I find out if my device is connected to another device and if their is an administrator that is controlling some of my actions and being able to see me and everything I do on my phone.

I’m experiencing the same “Sign Up Not Completed” issue with native Sign in with Apple. The authorization logs report “No applications were found with the provided Client ID” and “Invalid client”, although the App ID capability, provisioning profile, and signed application entitlement appear to be configured correctly. I submitted the requested information and sysdiagnose through Feedback Assistant. Feedback ID: FB23819378

@Paris X Pinkney — Looking for help with a team-scoped SIWA failure. Feedback ID: FB23839261 Bundle ID: com.yyssd Team ID: U3KSLBV22Q iOS: 26.5.2 (23F84) production Device: iPhone 13 (iPhone14,5) Failure window: 2026-07-19 14:51:28 – 14:51:40 +0800 (Beijing time) Symptom SIWA fails immediately after Face ID succeeds. The app sees ASAuthorizationError Code=1001. The system alert says "Sign-Up Not Completed". The same Apple ID on the same device works fine for SIWA in other teams' apps (e.g. Notion). akd failure chain (from sysdiagnose with AuthKit profile) [authkit:siwa] Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 [authkit:siwa] No applications were found with the provided Client ID [authkit:siwa] Using personal credential state - 2, error - AKAuthenticationError Code=-7074 [authkit:core] Performing SRP request with context [AppleIDAuthSupport] setError: 2:M2 missing (bad password) [authkit:core] SRP authentication with server failed! [authkit:siwa] Error performing auth request: AKAuthenticationError Code=-7003 This is identical to the failure signature reported in thread 838075. What we've verified App Store Connect API: SIWA capability (APPLE_ID_AUTH + PRIMARY_APP_CONSENT) is enabled on the App ID Tried deleting & recreating the capability via API — same failure com.apple.developer.applesignin is in entitlements AND embedded provisioning profile (verified via security cms -D) Same failure on two different Apple IDs Tried deleting app + Reset Location & Privacy — same failure Removed SIWA from sibling App ID com.yyssd.game to eliminate prefix conflict — same failure iOS is production 26.5.2, not beta Notion (different team) works fine on same device with same Apple ID Diagnosis The AKSQLError -6003 "No applications were found with the provided Client ID" line strongly suggests that Apple's SIWA backend does not recognize com.yyssd as having SIWA enabled, even though App Store Connect API says otherwise. The two databases are out of sync. The subsequent setError: 2:M2 missing (bad password) is a phantom error — the SRP handshake fails because the backend can't find a valid credential state for (Apple ID, com.yyssd), not because the password is wrong. Ask Could DTS confirm whether the team-scoped SIWA provisioning state for Team U3KSLBV22Q can be re-initialized server-side? Happy to share the full sysdiagnose logarchive (already attached to FB23839261). Sysdiagnose: sysdiagnose_2026.07.19_15-32-28+0800_iPhone-OS_iPhone_23F84_2CBB9352-E02D-547E-9213-5C5C7514A41F.tar.gz Many thanks.

Whenever I go to sign in with Apple on my new app, I press Continue and it takes my Face ID, but it says 'Sign in not completed' right after and there is no debug details at all. How can I debug this? My Apple Account has 2FA, terms accepted, I have selected Sign in with Apple in the App ID Configuration, I don't know what the issue is.

Summary: invalid_client on a Services ID whose portal configuration is complete and correct, AND the same team's native App ID cannot be revoked from the iOS Settings UI ("Stop authorisation has failed - Invalid client"). Both started on 17 July 2026. Sign in with Apple on this App ID worked normally earlier the same day. Team ID: 8ASV5HF9RR Primary App ID: co.uk.2point45.calendarapp Services ID: co.uk.2point45.web Issue 1 (web): a request to the authorize endpoint with client_id set to the Services ID and redirect_uri set to a registered Return URL returns invalid_client. This reproduces with plain curl - no browser, no JS SDK, no popup, no scope, no nonce. The minimal request (response_type=code, response_mode=query) fails identically, so no application code is involved. Issue 2 (native): Settings > Apple Account > Sign in with Apple > [the app] > Stop using Apple ID returns "Stop authorisation has failed - Invalid client". This is the Settings app failing against the Sign in with Apple backend for the native App ID, with no third-party code in the path. sysdiagnose attached to the Feedback, captured with the Accounts/AuthKit profile installed. Already verified, so please don't return these as the cause: App ID has Sign in with Apple enabled and is set to "Enable as a primary App ID" Services ID has Sign in with Apple enabled, grouped to that primary App ID, with 6 Website URLs attached client_id is the Services ID, not the App ID redirect_uri is a character-for-character match of a registered Return URL Domains registered without a scheme; Return URLs registered with https TLS 1.2+ on all domains No domain association file uploaded, per the documentation ("You don't need to upload a file on your server to complete the registration process for domains and subdomains") Not applicable: no client secret JWT, refresh token or access token can be supplied, because this integration never calls the token endpoint. It uses Sign in with Apple JS with response_type=code id_token and verifies the returned id_token against the published JWKS. The failure is at the authorize endpoint, before any token exchange. The only portal changes between working and failing were: (1) creating the Services ID and selecting the App ID above as its Primary App ID, and (2) renaming the App ID's Description from the Xcode-generated default. No capabilities were changed.

Question I'm encountering a very strange RSA issue on iOS. I'm using a 1024-bit RSA key pair generated by SecKeyGeneratePair. Public Key MIGJAoGBAK2wYDpTcGxFDe+0SwUj4twWOQWfWE+pvbgoUFsXZ/XBplEv7qlruq8ZutG+q7qW2M1983V5HzWGmtDrz2l8vLHYNKaBqEGYAtlYIePBq6+lfsUj2qmFE5Uui8R44KLz8i8QqMxYJUQoeUY3JxHeOe4DnUMWK3+X2nWWv4YWv9qxAgMBAAE= Private Key MIICWwIBAAKBgQCtsGA6U3BsRQ3vtEsFI+LcFjkFn1hPqb24KFBbF2f1waZRL+6pa7qvGbrRvqu6ltjNffN1eR81hprQ689pfLyx2DSmgahBmALZWCHjwauvpX7FI9qphROVLovEeOCi8/IvEKjMWCVEKHlGNycR3jnuA51DFit/l9p1lr+GFr/asQIDAQABAoGAAe2GUpITWkmgQw6Z0uZdfIAM+nm/YcT6di/mXRh4VC3l0hq0LV0PfvrhYWDFKFvyb0IhthEAg8LTzD6tzZfaQqIOMEu77BkuDnpu3g7xTnZP2n2nmBU+4kz7F9l/pBr0KL6RopnagcwfuAtPXxGKv2kfWWbX3szHJXwjMo2KjgECQQDhN/i/yDjhzu8psTHvGptiHrOqi5H1CdmSg7u7EbBbZIPp/FsoxBsxcY8FPmMAkD0bR0JIpwBmYkPLFm+rITeBAkEAxW13UsOstGN8rRJ34SklhlYUDUQKN2R8OLyES5w7rRPcOUfCdKR45SJ2OWrLHATqlPRN+9jo5WmsQWArxlm7MQJAF/2DVMJ6NKt7VGCYphSaeqA0mTUWzhhHgdDgfXPL6mBRoOoNt9Dz6JdlGbTkjNnQeIhlqiGH7GAJQqfYK011gQJATWDIAaI7kD/l35d7cL5FvM8D8OcX8fnqTfplB5VmNkGwcKrVZg4IbBYDrCFVFdg/cL4HyouLTE8MelsNDSKiIQJAEwj2CoK+uupS2T1gJNd57wqOkZp+LbkVX92oSUbJQfez1P7Ldtbn4uCMyoOL34I9CTDfCzlxWqbZnwFmSq3eaQ== Test Data Plaintext: SO202605140735073974 Encrypted ciphertext (Base64): AAKhsQxaEVqqZbFLUzC1+8uzdyCDVxzkTbq37pea6cgLlCTOniYeZQVwaOIRdioQmZ/M/0q33l0votNRWZje8bj4Km0vQF2NjvX+8EjPg6T6OsJKEt/KZf+bX6+PoNooSh1tC9H/HVFhhgNJdpKj9s/Fdl3eLH4qEsmQ25FS53M= After calling SecKeyDecrypt, I get the following decrypted bytes: 4d48734341514177457759484b6f5a497a6a3043415159494b6f5a497a6a304441514545595442664167454242426835707a4b493973744f4e42416b4a4757646e5035465842546d386e555272565367436759494b6f5a497a6a3044415147684e414d794141545a542b4a49746b4a4e647554424e70624d336f324d7a654e5565306f6e4e617a623767645975303370712f2f4271505861397747504e4575462b7145786a4c633d However: NSString *result = [[NSString alloc] initWithData:plainData encoding:NSUTF8StringEncoding]; returns nil. Additional Information This RSA key pair works correctly for many other plaintext values. The failure only occurs when encrypting and decrypting this specific string: SO202605140735073974 The RSA key pair is generated using: SecKeyGeneratePair(...) with a 1024-bit key size. Encryption and decryption use the Security framework APIs: SecKeyEncrypt SecKeyDecrypt Decryption returns errSecSuccess (status == noErr). There are no Security framework errors. Decryption Code status = SecKeyDecrypt( key, kSecPaddingNone, dataSegment.bytes, dataSegmentRealSize, cipherBuffer, &cipherBufferSize ); status is noErr. However, converting the decrypted data to UTF-8 always returns nil. My Questions Why can SecKeyDecrypt return noErr, yet the resulting data is not valid UTF-8? Is it possible that the decrypted bytes are actually an ASN.1/DER structure rather than the original plaintext? Could this be related to using kSecPaddingNone instead of kSecPaddingPKCS1? Is there anything special about this plaintext (SO202605140735073974) that could trigger this behavior, even though other plaintexts work correctly with the same key pair? Any insights would be greatly appreciated. Thanks!

Sign in with Apple fails with the system alert "Sign-Up not completed" for every app belonging to our developer team, on every device we tested. The app itself only receives ASAuthorizationError code 1001 with an empty userInfo dictionary, so there is nothing actionable on the client side. We have systematically ruled out every configuration cause we could think of: Sign in with Apple capability is enabled on each App ID, set as primary (verified via the App Store Connect API) com.apple.developer.applesignin entitlement is present in the signed binaries and in the provisioning profiles (verified with codesign and security cms) Two-factor authentication is active on the test Apple ID No pending agreements (Paid Apps accepted; one of our apps is live on the App Store) Reproduction matrix — ALL of these combinations fail identically: Devices: two different physical devices (iPhone, iPad) Signing: development-signed AND TestFlight (App Store distribution) builds Network: Wi-Fi AND cellular App IDs: existing ones (capability enabled more than 48 hours ago) AND a minimal reproduction app whose App ID + capability were created minutes before the test Control test that WORKS: on the same devices, with the same Apple ID, a brand-new Sign in with Apple sign-up in App Store apps from other teams completes without any issue. The failure is therefore strictly scoped to apps of our team. The device log (log collect) shows the following akd sequence at the moment of every attempt: akd: [com.apple.authkit:siwa] Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 akd: [com.apple.aaafoundation:log] Error fetching keychain items - NSOSStatusErrorDomain Code=-25300 "no matching items found" akd: [com.apple.authkit:siwa] Using personal credential state - 2, error - AKAuthenticationError Code=-7074 akd: [com.apple.AppleIDAuthSupport:general] AppleIDAuthSupport: setError: 2:M2 missing (bad password) akd: [com.apple.authkit:core] SRP authentication with server failed! (com.apple.AppleIDAuthSupport Code=2) akd: [com.apple.authkit:siwa] Error performing auth request: AKAuthenticationError Code=-7003 Given that a freshly created App ID reproduces the failure immediately while other teams' apps work on the same devices with the same Apple ID, this looks like a broken server-side Sign in with Apple provisioning/registration state for our team rather than anything we can fix ourselves. Has anyone seen this resolved? Is there anything on the account/team level that can get a team's Sign in with Apple provisioning re-initialized? Happy to share the Team ID and full .logarchive with Apple folks via DTS/support.

Hi Everyone I’m using an iPhone running the latest version of iOS with a physical team after enabling lockdown mode. I have noticed what appears to be unusual issued. 1: wi-Fi works normally. 2: outgoing cellular calls fail wit “call failed.” 3: shortly after the status bar changes to “no service.” 4: I still receive SMS notifications from my courier informing me of missed calls. I’ve already: . Nothing nice. updated to the latest iOS. . Restarted the iPhone. . Confirm that Wi-Fi is functioning normally. From Apple‘s documentation, I understand that lockdown mode is intended to harden the device against sophisticated cyber rates. I should not normally disable voice call service as everyone else experience this after enabling lockdown mode? If so: Which iPhone model are you using? Which iOS version? Which carrie? Did you find a solution? I’m also interested in knowing whether Apple is aware of this as a potential software bug or whether it could be related to a carrier compatibility issue. Thank you

Sign in with Apple fails for every App ID in our team (K9UFUZF2XW), on every device and every Apple ID we have tried. The system sheet appears, the user authenticates successfully, the sheet then shows "Sign Up Not Completed", and no credential is returned. The failure happens after authentication — this is not a client-side rejection. I have spent several days isolating this and have ruled out everything on my side. Posting the full evidence in case an Apple engineer can look at the server-side state for our team, and in case it helps others hitting the same wall. WHAT THE FRAMEWORK ACTUALLY RETURNS The client library we use (expo-apple-authentication) discards the original NSError, so I patched its native layer to surface the raw error verbatim. This is what ASAuthorizationController hands back to didCompleteWithError, immediately after the user authenticated and the sheet displayed "Sign Up Not Completed": ASAuthorizationError .canceled (rawValue = 1001) domain = com.apple.AuthenticationServices.AuthorizationError code = 1001 desc = The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError, error 1001) userInfo: NSUnderlyingError: So the framework reports a user cancellation that never happened, with a completely empty userInfo and no underlying error. There is no diagnostic information on the client at all — I cannot debug this any further from my side, because the information does not exist there. Note: the same failure surfaces as a different error code depending on the client library version — .unknown (1000) with the older version, .canceled (1001) with the current one. The user-visible behaviour ("Sign Up Not Completed") is identical in both. So the error code is not a reliable signal here. WHAT I RULED OUT Not the App ID. I created a brand-new App ID (kz.auraai.ios) with Sign in with Apple enabled as a primary App ID, built a fresh binary, tested on the same device with the same Apple ID — identical failure. Two independent App IDs in the same team fail the same way. Not the entitlement. Verified inside the signed binary, not just in the portal: application-identifier = K9UFUZF2XW.kz.auraai.ios com.apple.developer.applesignin = ["Default"] I also tried the workaround suggested elsewhere on these forums (removing the entitlement while keeping the capability in the portal). That made it strictly worse: iOS then rejects the request instantly, without showing the sheet at all. Which confirms iOS reads the entitlement correctly, the sheet works, and the user authenticates — the failure is downstream of all of that. No stray or wildcard App IDs. A commonly cited cause is other App IDs in the team lacking the entitlement. I enumerated the whole team via the App Store Connect API: it contains exactly two App IDs, both with APPLE_ID_AUTH = PRIMARY_APP_CONSENT. No wildcard identifiers exist. Not the Apple ID, the device, or the iOS version. The same Apple ID, on the same device, with the same iOS, signs in successfully through another app belonging to a different team (Expo Go, host.exp.Exponent) — a valid identity token is returned. A second, unrelated Apple ID on another device fails in my app in exactly the same way. So this is not scoped to one account: it affects every user of the app. Agreements and membership are in good standing. Program License Agreement accepted 30 June 2026; Developer Agreement accepted 26 June 2026; membership active. Both distribution types fail. TestFlight and ad-hoc. WHAT IS LEFT After all of the above, the only variable that differs between the working case (a different team's app, same device, same Apple ID) and the failing case (my app) is the Apple Developer team itself. This exact signature — sheet renders fully, final server submit fails, "Sign Up Not Completed", delegate reports canceled with no userInfo, not reproducible in other apps on the same device — is documented in thread 122458 ("Error: Sign-Up Not Completed"). In that case it affected multiple developers, including Apple's own sample app, and was ultimately resolved by Apple on the server side, with a recurrence reported in June 2025. THE ASK Could someone from Apple check the server-side Sign in with Apple registration for team K9UFUZF2XW (App IDs kz.auraai.app and kz.auraai.ios)? I am not looking for configuration advice — I have exhausted the client side and there is nothing left to configure. This looks like the same server-side state that was fixed in the referenced cases. Feedback Assistant: FB23716661 (includes sysdiagnose with the Accounts/AuthKit profile, timestamp, and video of the failure). This is currently blocking us: because Sign in with Apple works for none of our users, guideline 4.8 prevents us from offering Google Sign-In, so we are shipping with email-only login. Happy to provide the binary, entitlements dump, or a fresh sysdiagnose on request.