Hi, Before I begin my investigation, I want to explain our code-level support process for issues related to Sign in with Apple—as the issue you’re reporting may be the result of any of the following: An error in your app or web service request. A configuration issue in your Developer Account. An internal issue in the operation system or Apple ID servers. To ensure the issue is not caused by an error within your app or web service request, please review TN3107: Resolving Sign in with Apple response errors to learn more about common error causes and potential solutions when performing requests. If the technote does not help identify the cause of the error, I need more information about your app or web services to get started. To prevent sending sensitive JSON Web Tokens (JWTs) in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback. Gathering required information for troubleshooting Sign in with Apple authorization and token requests For issues occurring with your native app, perform the following steps: Install the Accounts/AuthKit profile on your iOS, macOS, tvOS, watchOS, or visionOS device. Reproduce the issue and make a note of the timestamp when the issue occurred, while optionally capturing screenshots or video. Gather a sysdiagnose on the same iOS, macOS, tvOS, watchOS, or visionOS device. Create a report in Feedback Assistant, and ensure your feedback contains the following information: the primary App ID or Bundle ID the user’s Apple ID, email address, and/or identity token the sysdiagnose gathered after reproducing the issue the timestamp of when the issue was reproduced screenshots or videos of errors and unexpected behaviors (optional) For issues occurring with your web service, ensure your feedback contains the following information: the primary App ID and Services ID the user’s Apple ID, email address, and/or identity token the failing request, including all parameter values, and error responses (if applicable) the timestamp of when the issue was reproduced (optional) screenshots or videos of errors and unexpected behaviors (optional) Important: If providing a web service request, please ensure the client secret (JWT) has an extended expiration time (exp) of at least ten (10) business days, so I have enough time to diagnose the issue. Additionally, if your request requires access token or refresh tokens, please provide refresh tokens as they do not have a time-based expiration time; most access tokens have a maximum lifetime of one (1) hour, and will expire before I have a chance to look at the issue. Submitting your feedback Before you submit to Feedback Assistant, please confirm the requested information above (for your native app or web service) is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hi, Please see TN3159: Migrating Sign in with Apple users for an app transfer for more information on the expected end-to-end app transfer and user migration flow. Additionally, if you'd like for the iCloud and App Store engineering teams to confirm if the errors are related to a revoked authorization to previous users accounts, please submit a report via Feedback Assistant and include the following information: Gathering required information for troubleshooting Sign in with Apple user migration To prevent sending sensitive JSON Web Tokens (JWTs) in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback. For issues occurring with your user migration, ensure your feedback contains the following information: the primary App ID and Services ID the client secret for the transferring team (Team A) and the recipient team (Team B) the failing request(s), including all parameter values, and error responses (if applicable) the timestamp of when the issue was reproduced (optional) screenshots or videos of errors and unexpected behaviors (optional) Important: If providing a web service request, please ensure the client secret (JWT) has an extended expiration time (exp) of at least ten (10) business days, so I have enough time to diagnose the issue. Additionally, if your request requires access token or refresh tokens, please provide refresh tokens as they do not have a time-based expiration time; most access tokens have a maximum lifetime of one (1) hour, and will expire before I have a chance to look at the issue. Submitting your feedback Before you submit via Feedback Assistant, please confirm the requested information above (for your native app or web service) is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hi, Before I begin my investigation, I want to explain our code-level support process for issues related to Sign in with Apple—as the issue you’re reporting may be the result of any of the following: An error in your app or web service request. A configuration issue in your Developer Account. An internal issue in the operation system or Apple ID servers. To ensure the issue is not caused by an error within your Private Email Replay configuration, please review Configuring your environment for Sign in with Apple to learn more about registering your email sources and authenticated domains. To prevent sending sensitive message details in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback. Gathering required information for troubleshooting Private Email Relay with Sign in with Apple For issues occurring with your email delivery, ensure your feedback contains the following information: the primary App ID and Services ID the user’s Apple ID and/or email address the email message headers the Private Email Relay Service or Hide My Email message delivery failure, and SMTP error codes Submitting your feedback Before you submit to Feedback Assistant, please confirm the requested information above is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

The revoke tokens endpoint (/auth/revoke) is the only way to programmatically invalidate user tokens associated to your developer account without user interaction. This endpoint requires either a valid refresh token or access token for invalidation, as Sign in with Apple expects all apps to securely transmit and store these tokens for validation and user identity verification while managing user sessions. If you don’t have the user’s refresh token, access token, or authorization code, you must still fulfill the user’s account deletion request and meet the account deletion requirement. You'll need to follow this workaround to manually revoke the user credentials: Delete the user’s account data from your systems. Direct the user to manually revoke access for your client. Respond to the credential revoked notification to revert the client to an unauthenticated state Important: If the manual token revocation isn’t completed, the next time the user authenticates with your client using Sign in with Apple, they won’t be presented with the initial authorization flow to enter their full name, email address, or both. This is because the user credential state managed by Sign in with Apple remains unchanged and returns the.authorizedcredential state, which may also result in the system auth UI displaying the “Continue with Apple” button. Respond to the credential revoked notification Once the user’s credentials are revoked by Apple, your client will receive a notification signaling the revocation event:  For apps using the Authentication Services framework to implement Sign in with Apple, register to observe the notification named credentialRevokedNotification. For web services, if an endpoint is registered for server-to-server notifications, Apple broadcasts a notification to the specified endpoint with the consent-revokedevent type. When receiving either notification, ensure you’ve already performed the following operations to meet the requirements of account deletion: Deleted all user-related account data, including: The token used for token revocation; Any user-related data stored in your app servers; and Any user-related data store in the Keychain or securely on disk in the native app or locally on web client. Reverted the client to an unauthenticated state. Securely store user tokens for account creations For all new user account creations, follow the expected authorization flow below: Securely transmit the identity token and authorization code to your app server. Verify the identity token and validate the authorization code using the /auth/token endpoint.  Once the authorization code is validated, securely store the token response — including the identity token, refresh token, and access token. Validate the refresh token up to once per day with Apple servers (to manage the lifetime of your user session and for future token revocation requests), and obtain access tokens (for future token revocation, app transfer, or user migration requests). For information about verifying an identity token and validating tokens, visit Verifying a user and Generate and validate tokens. If you have questions about implementing these flows, including client authorization, token validation, or token revocation, please submit a Technical Support Incident.

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 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.

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.

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

App: Subio - Quản lý đăng ký Bundle ID: io.ausynclab.subio Team ID: DMB7A87LM9 App Store Connect App ID: 6785710632 SUMMARY Sign in with Apple in our app consistently fails during the account-creation flow with the system error "Sign-Up Not Completed" (shown by iOS's own native AuthenticationServices UI, before any of our app code runs). This has caused App Review to reject our app 5+ times over the past week (builds 16, 17, 19, 20, 21, 22), each citing Guideline 2.1(a) with this exact error. KEY EVIDENCE THIS IS SERVER-SIDE, NOT APP-SIDE The failure reproduces for TWO COMPLETELY INDEPENDENT Apple ID accounts: Our own developer test account (used repeatedly since build 16) Apple App Review's own test account/device (different devices each time: iPad Air 11" M3, iPad Air 11" M4, iPhone 17 Pro Max — running iPadOS 26.5.2 and iOS 27.0) Two unrelated accounts hitting the identical failure strongly suggests the issue is in our app's Sign-In-With-Apple server-side registration (tied to our Team ID/Bundle ID), not any individual user's account state. Our backend receives ZERO HTTP requests at the moment of failure, confirmed via server-side logging. This proves the failure occurs entirely within iOS's native account-creation sheet, before our JavaScript code (or the identityToken) is ever produced. TROUBLESHOOTING ALREADY COMPLETED (to save engineering time) We have verified all of the following are correctly configured, and the issue persists regardless: Bundle ID capability: APPLE_ID_AUTH is enabled with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (confirmed via App Store Connect API) Provisioning profile: App Store distribution type, contains com.apple.developer.applesignin entitlement (Default), correct Team ID Signing certificate: valid iOS Distribution cert, serial number matches the certificate linked to the provisioning profile in App Store Connect Entitlements embedded in the actual signed, submitted binary (extracted directly from the .ipa and inspected with codesign -d --entitlements) match expectations exactly Tried requesting full scopes (FULL_NAME + EMAIL), reduced scopes (FULL_NAME only), and zero scopes at all (requestedScopes: []) — the failure is identical in all three configurations Added a guard to prevent concurrent/duplicate calls to signInAsync() (in case of rapid double-taps) — failure persists Confirmed the failure occurs both when the button is presented inside a React Native Modal and when presented on a plain (non-modal) screen — ruling out a presentation-context conflict WHAT WE'D LIKE APPLE'S HELP WITH Please check, on your side, whether there is a stuck, incomplete, or corrupted Sign-In-With-Apple account-linking record associated with Bundle ID io.ausynclab.subio / Team ID DMB7A87LM9 that could be causing account-creation requests to fail at the server level. We are happy to provide additional logs, device details, or a screen recording if useful. We would greatly appreciate guidance, as this is blocking our very first App Store submission and we've been unable to identify anything further to fix from the client side. Thank you for your time.

Our app's Sign in with Apple never completes. Apple's create-account sheet renders fully (name + share/hide-my-email step), then the final server submit fails and shows the "Sign Up Not Completed" sheet. The authorization callback returns ASAuthorizationError.canceled (1001) with no userInfo — even though the user did not cancel. Reproduced on multiple physical devices and multiple Apple IDs (all with 2FA), on iOS 26.5.1, since our first build. Team ID: 24XS837728 App ID: C54N9Q226H (bundle com.sucsessmaperrs.careerAssessmentApp) Verified on our side: com.apple.developer.applesignin = [Default] present in the distribution build (codesign -d --entitlements); embedded profile is the explicit App Store profile for the App ID (not wildcard). App ID has Sign in with Apple enabled as a primary App ID; capability deleted + recreated via the App Store Connect API today, no change. Firebase consumes the identity token; the failure is in Apple's UI before our code runs. App Store Connect agreements are clean. Key isolating fact: the same Apple ID on the same device completes a first-time Sign in with Apple sign-up in other third-party apps — only ours fails. So the cause appears scoped to our App ID / team on Apple's side, not the device, the Apple ID, 2FA, or our client code. This matches the widespread server-side "Sign Up Not Completed" failure in thread 675756 — same signature: multiple devices/Apple IDs, no console error, the failure delegate surfacing only as "cancel", newly created apps affected, even Apple's own sample app failing — which Apple ultimately resolved server-side (with a recurrence reported June 2025). Note this is the native ASAuthorizationController flow, not the REST/web flow, so the query-parameter percent-encoding fix from thread 122458 does not apply here. Could an Apple engineer check the server-side Sign in with Apple / account-association state for App ID C54N9Q226H (Team 24XS837728)? Happy to provide a screen recording or sysdiagnose.

@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.

Hello, our Sign in with Apple Button no longer works and throws an 7003 error. It worked a few days ago but suddenly fails. Any ideas how to fix this? Thanks in advance! plist: <dict> <key>com.apple.developer.applesignin</key> <array> <string>Default</string> </array> ... Code: var body: some View { VStack { SignInWithAppleButton(.signUp) { request in request.requestedScopes = [.fullName, .email] } onCompletion: { result in switch result { case .success(let authResults): handleSuccess(authorization: authResults) case .failure(let error): self.credentialFailure = true self.errorMessage = .appleSignInError logger.error("SIWA login failure: \(error)") } } .signInWithAppleButtonStyle(.white) .cornerRadius(GlobalValues.cornerRadius) } } Error: Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.our.app} ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)" SIWA login failure: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)"

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.

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.

Sign in with Apple works correctly on a physical iPhone in my Capacitor-based app, but fails in the Simulator, and this appears to be causing repeated App Store review rejections. I'm trying to figure out how to get past review.... What happens On a physical iPhone, Sign in with Apple works as expected. In the Simulator, if the user signs into their Apple ID (Settings) and returns to the app, tapping "Sign up with Apple" fails immediately with: The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError error 1000.) (Screenshot attached.) The native Apple sheet never appears — the error returns right away. The actual problem Every time I submit to App Store review, the app gets rejected because Sign in with Apple fails for the reviewer — I believe they're testing in an environment (Simulator, or a device not signed into iCloud) where it returns error 1000. It works on real hardware, so I keep getting stuck in a review loop over something I can't reproduce on device. What I've already checked Sign In with Apple capability is present in Signing & Capabilities for both Debug and Release, and the entitlement is in the built product. The App ID has Sign In with Apple enabled in the Developer portal, and the Services ID / return URLs are configured for Clerk. Resolved an earlier iPad-specific issue where connectedScenes was empty (added a UIApplicationSceneManifest + AppDelegate.window fallback), so ASAuthorizationController now has a valid presentation anchor. Questions Is error 1000 (ASAuthorizationError.unknown) in the Simulator a known environment issue (e.g. no usable Apple ID for the authorization flow) rather than an app bug — given it works on physical devices? For anyone who has been rejected because Sign in with Apple failed in the reviewer's environment: what actually got you through review? Reviewer notes explaining it works on device? Replying in Resolution Center with a screen recording from a real device? Something else? Any guidance appreciated — I'd rather fix the root cause than keep resubmitting.

Sign in with Apple (web flow) fails 100% reproducibly at the token exchange for our newly created identifiers. POST to https://appleid.apple.com/auth/token with a REAL authorization code → 400 {"error":"invalid_client"}. The exact same client_id + client_secret from the same production server with a dummy code → {"error":"invalid_grant"} — i.e. client authentication passes and only the code is rejected, as expected. 16/16 probe requests across both registered redirect_uris. The authorization phase succeeds (user completes the appleid.apple.com sheet; code arrives via form_post to the registered return URL) and the exchange happens within ~1 second, so code expiry is not the cause. client_secret is an ES256 JWT with correct iss/sub/aud, validity ~6 months, sent via client_secret_post with no Authorization header. I have reviewed TN3107 — none of the documented invalid_client causes fit, given the invalid_grant asymmetry above. Persisted 24+ hours and survived: recreating the Services ID under a new identifier with a freshly minted secret; toggling the Sign in with Apple capability off/on (as primary) on the App ID; re-saving the Services ID configuration (domains and both return URLs re-confirmed). Team ID: CGSLWL988T Primary App ID: app.bookagym (created 2026-07-10) Services ID: app.bookagym.signin (an earlier Services ID app.bookagym.web behaved identically) Key ID: C99J756C86 This looks like stuck or unpropagated server-side provisioning for these identifiers rather than a client-side error. Per the "Gathering required information for troubleshooting Sign in with Apple authorization and token requests" post, I have filed the full details (including the failing request with all parameter values and a long-lived client secret) in Feedback Assistant: FB23692739

I'm building an iOS app using Capacitor with a Next.js 14 backend. Authentication currently uses: NextAuth Prisma Sign in with Apple Google Sign-In Magic Link The web version works correctly. For the native iOS app, tapping Continue with Apple currently opens the NextAuth endpoint (/api/auth/signin/apple), which launches the web authentication flow. App Review rejected the app because the Sign in with Apple flow leaves the native experience and opens a web view/browser during sign in. My goal is to keep Sign in with Apple fully native while continuing to use the same Prisma user database and authentication system used by the web application. What is Apple's recommended architecture for this scenario? Should I: Perform native Sign in with Apple in the Capacitor app. Send the returned identity token to my backend. Verify the token server-side. Create my own authenticated session instead of using the NextAuth Apple provider. Or is there another approach Apple recommends for hybrid apps using Capacitor? Any guidance would be greatly appreciated.

Apple Developer Support Request - Sign in with Apple Failure Date prepared: 2026-07-08 App name: LingJing / XiaoLing Bundle ID: com.jachymchen.xiaoling Apple Developer Team ID: 765B64SW9Z Platform: iOS Summary Sign in with Apple fails before the app receives a usable Apple identity token. The user-facing Apple system sheet ends with the Chinese alert "未完成注册" ("Sign Up Not Completed"). The app callback does not receive an identityToken, so our backend auth provider is not reached successfully. We reproduced the same failure in a minimal native Swift app that only uses AuthenticationServices and the same Bundle ID / provisioning profile, without Supabase or any app-specific backend code. This suggests the failure is likely in the Apple Sign in with Apple authorization flow, account/device state, or App ID/provisioning configuration recognized by Apple's auth services, rather than in our app's backend implementation. Environment Mac: macOS 26.5 Apple Silicon MacBook Pro Xcode 26.5 iPhone: Real device connected over USB Device name: 硬糖的iPhone iOS 26.5.1 Device UDID: 00008150-000344540C99401C App: Bundle ID: com.jachymchen.xiaoling App version currently used for testing: 0.1.0 App Store Connect app ID observed during TestFlight work: 6784075688 TestFlight build upload previously succeeded for version 0.1.0 build 2 Provisioning / Entitlements Checked Development provisioning profile: Profile name: XiaoLing Dev application-identifier: 765B64SW9Z.com.jachymchen.xiaoling com.apple.developer.applesignin: [Default] com.apple.developer.team-identifier: 765B64SW9Z get-task-allow: true keychain-access-groups includes: 765B64SW9Z.* com.apple.token Profile includes the test device UDID: 00008150-000344540C99401C Expiration: 2027-06-27 Distribution / TestFlight provisioning profile: Profile name: XiaoLing AppStore application-identifier: 765B64SW9Z.com.jachymchen.xiaoling com.apple.developer.applesignin: [Default] beta-reports-active: true get-task-allow: false Signed app entitlements were checked from the executable and matched the expected Bundle ID / Team ID / Sign in with Apple entitlement. Important note: Running codesign -d --entitlements :- XiaoLing.app against the .app bundle may print an "invalid entitlements blob" style result. Running codesign against the actual executable inside the .app is the useful check, and that showed the expected entitlements. Reproduction Steps Install and launch the iOS app with Bundle ID com.jachymchen.xiaoling on the real iPhone. Tap "Sign in with Apple". Complete the Apple ID system prompt. The Apple system flow fails and shows "未完成注册". The app does not receive a valid ASAuthorizationAppleIDCredential identity token. Observed Result The Apple authorization flow fails before returning a usable credential to the app. The system UI shows "未完成注册" ("Sign Up Not Completed"). Expected Result AuthenticationServices should return an ASAuthorizationAppleIDCredential with an identityToken so the app can continue its own backend sign-in. Key Device Logs Observed During real-device attempts, the following log lines appeared around the failure: AuthKit continuation-key-creation token is missing AppleIDAuthSupport: setError: 2:M2 missing (bad password) SRP authentication with server failed AUTH_ALERT_SIGN_UP_NOT_COMPLETED -> 未完成注册 AKRemoteViewController did complete with authorization (null) AKAuthenticationServerError Code=-24000 The private framework error code by itself is not enough to identify the root cause, but the flow consistently fails inside Apple's AuthKit / Apple ID authorization path before our app receives an identity token. Minimal Native Demo Test To exclude app-specific implementation and backend issues, we created a minimal native SwiftUI app using only: AuthenticationServices SignInWithAppleButton ASAuthorizationAppleIDProvider The same Bundle ID: com.jachymchen.xiaoling The same Team ID / provisioning entitlement setup No Supabase No custom backend No React Native No third-party auth library The minimal native demo produced the same user-facing failure: "未完成注册". This strongly suggests the issue is not caused by Supabase, nonce hashing, OAuth handling, React Native, or our app UI. The failure happens before any backend auth exchange can occur. Additional Context The tester tried another Apple ID and still reproduced the failure. The tester stated the Apple ID itself is otherwise usable. The app's Bundle ID is intended to be exactly: com.jachymchen.xiaoling We specifically checked for provisioning profile / Bundle ID mismatch and did not find a mismatch in the installed build. Questions for Apple Developer Support Can Apple check whether App ID 765B64SW9Z.com.jachymchen.xiaoling has any server-side Sign in with Apple configuration issue? Can Apple explain what conditions produce: AUTH_ALERT_SIGN_UP_NOT_COMPLETED AKAuthenticationServerError Code=-24000 "M2 missing (bad password)" "AuthKit continuation-key-creation token is missing" in a native AuthenticationServices Sign in with Apple flow? Is there any known issue on iOS 26.5.1 or with development-signed apps where Sign in with Apple fails before returning an ASAuthorizationAppleIDCredential? Are there account-level or device-level requirements beyond normal Apple ID login that can cause Sign in with Apple to show "Sign Up Not Completed"? Can Apple verify whether this Bundle ID / Team ID is correctly enabled for Sign in with Apple on Apple's backend? Minimal Code Shape Used for Native Demo The native demo used a standard SignInWithAppleButton: SignInWithAppleButton(.signIn) { request in request.requestedScopes = [.fullName, .email] } onCompletion: { result in switch result { case .success(let authorization): // Check authorization.credential as ASAuthorizationAppleIDCredential // and read identityToken. case .failure(let error): // Log NSError domain, code, localizedDescription, and userInfo. } } Support Request Please help determine why Apple's Sign in with Apple authorization flow fails for Bundle ID com.jachymchen.xiaoling before returning a credential, despite the app having the Sign in with Apple entitlement and matching provisioning profile / Bundle ID.

Subject: Sign In with Apple consistently fails with AuthorizationError 1000 (empty userInfo) immediately after successful biometric authentication — native delegate logging confirms failure occurs before authorization is returned to app App ID: com.andresalecina.vant
Team ID: C6GK7Z5GY2
Services ID: com.andresalecina.vant.signin Summary:
Sign In with Apple fails 100% of the time in our native iOS app (Capacitor 7 wrapper) with error code 1000 and completely empty userInfo. The native authentication sheet displays correctly and the user completes Face ID successfully, but authentication fails immediately afterward. Critical new evidence (delegate-level logging):
We instrumented both ASAuthorizationControllerDelegate callback methods directly with NSLog to determine exactly where the failure occurs: authorizationController(controller:didCompleteWithAuthorization:) — never fires. Confirmed across multiple fresh test attempts. authorizationController(controller:didCompleteWithError:) — fires every time, receiving: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1000 "(null)" with completely empty userInfo. This confirms the failure originates inside AuthenticationServices itself, before any authorization object is ever returned to our app. Our app code is not receiving a token, credential, or authorization of any kind to process — there is nothing for our code to mishandle. Everything already verified clean on our end: Sign In with Apple capability present in Xcode target and confirmed in Apple Developer Portal (Primary App ID, not grouped) Entitlement com.apple.developer.applesignin confirmed present in both the development-signed binary and the App Store distribution provisioning profile Team ID in the compiled binary matches the entitlement (verified via codesign -dv and codesign -d --entitlements) Provisioning profile freshly regenerated after capability was added Apple Developer Program License Agreement and Developer Agreement both fully accepted, no pending items Reproduces identically on two separate physical devices (one iOS 27 beta, one non-beta), on both WiFi and cellular Reproduces with a completely clean Apple ID test account (no prior Family Sharing/managed account involvement, confirmed adult standard account) Device clock, timezone, and Screen Time/Content & Privacy Restrictions confirmed not a factor Native plugin code reviewed line-by-line: uses stock ASAuthorizationAppleIDProvider().createRequest(), standard .fullName/.email scopes only, robust presentation anchor resolution (no detached/fake UIWindow) Timeline:
The Sign In with Apple capability was added to this App ID within the past 24–48 hours (it was missing entirely on our initial rejected App Store submission). Error 1000 has persisted consistently across many rebuilds since the capability was added, which raises the possibility of a propagation delay on Apple's authentication backend, but this has now exceeded typical propagation windows for other capabilities we've observed (Push Notifications, Associated Domains). What we're asking:
Can you verify, on Apple's side, whether App ID com.andresalecina.vant under Team C6GK7Z5GY2 is fully provisioned and active on Apple's Sign In with Apple authentication backend? All client-side, code-side, and account-side factors we can verify are confirmed correct; the delegate-level logging above confirms the failure is occurring before any authorization is returned to the client, which points to a state on Apple's servers that isn't visible to us through the standard Developer Portal UI. Happy to provide device sysdiagnose logs, the full Xcode archive, or a minimal reproduction project (bare SwiftUI, no Capacitor/Supabase) if useful.

I'm implementing Sign in with Apple for a web-only service (Services ID associated with a primary App ID, plus a private key for the client secret JWT). Before I finalize the setup I want to confirm one prerequisite, because two of Apple's own pages give different answers. "Configuring your environment for Sign in with Apple" states that to authenticate users with a web service you must have an existing app in the App Store that uses Sign in with Apple: https://developer.apple.com/documentation/signinwithapple/configuring-your-environment-for-sign-in-with-apple "Configure Sign in with Apple for the web" (Account Help) only says to associate your website with an existing primary App ID enabled for Sign in with Apple — i.e., just a registered identifier, with no mention of a published app: https://developer.apple.com/help/account/capabilities/configure-sign-in-with-apple-for-the-web/ My question: for a web-only service, is a published (or in-review) App Store app actually required, or is a registered App ID identifier with the Sign in with Apple capability enabled sufficient on its own? And if a published app isn't required, is the "existing app in the App Store" wording just meant to describe the App ID rather than a live listing? I've contacted Developer Support and was pointed back to the general docs, which are the source of the contradiction rather than the answer, so I'm hoping an engineer or someone who has shipped a web-only setup can confirm which prerequisite governs. Thanks in advance.

Hello, We recently transferred our iOS app to a different Apple Developer team. App Store URL: https://apps.apple.com/kr/app/id6759354260 Bundle ID: com.kimchisushi.app Our app uses Sign in with Apple. In our legacy implementation, some existing Apple login users were stored in our backend by email only. For those users, we did not store the original team-scoped Apple user identifier (sub). The app transfer has already been completed, and we are currently within the 60-day migration window. For many users, the migration path is clear: If we have the old team-scoped sub, we can generate or exchange the transfer identifier according to Apple’s migration documentation. If a user signs in after the transfer and the identity token contains transfer_sub, we may be able to use that claim to complete the migration. However, our difficult case is this: Some legacy users used Sign in with Apple with Hide My Email / Private Relay. For those users, we only have the old private relay email address in our database. We do not have their old team-scoped sub. Questions: If we do not have the old team-scoped sub, is there any Apple-supported way to recover or map those legacy users using the old private relay email address? During the 60-day migration window, if one of these users signs in again after the app transfer, will the identity token include transfer_sub even if we did not generate a transfer identifier for that user before the transfer? If the identity token includes transfer_sub, is there any Apple-supported way to correlate that transfer_sub back to the user’s old private relay email address or old app account when the old sub was never stored? If the answer is no, is the recommended recovery path to implement our own account recovery / account relinking flow for these users? We understand that the Apple user identifier (sub) should have been stored as the stable identifier, and that email should not be treated as stable. We are trying to confirm whether there is any official recovery path for the subset of legacy users where the old sub was not stored before the app transfer. Thank you.

I’m trying to understand the recommended configuration for Sign in with Apple across two separate iOS apps and one website/Services ID under the same Apple Developer team. Goal: A user signs in with Apple in either iOS app or on the website, and our backend can recognize it as the same Apple identity/account, including when the user chooses Hide My Email. Current question: Should both iOS App IDs be configured as separate primary App IDs, or should one be primary and the other grouped with it? The website uses a Services ID associated with the primary App ID. I'm seeing behavior where the user can get a “create/sign in” style prompt in both iOS apps, and we want to avoid accidentally creating separate backend accounts if Apple returns different sub values for each app/client. What is the correct Apple Developer configuration if I need a stable backend identity across: iOS app A (existing, existing users) iOS app B (new, no existing users) web Services ID (new, no existing users) [preferred go forward "create account" service name if possible] Should our backend expect the sub claim in the Apple identity token to be identical across those clients when they are grouped, or should I treat each App ID/Services ID as potentially returning a different sub and link accounts another way? Current configuration and observed behavior: The web Services ID and iOS App B are currently grouped under iOS App A as the primary App ID for Sign in with Apple. This mostly works: when users sign in through App B, they appear to be associated with the same Apple credential/account, and no additional Sign in with Apple entry appears in the Passwords app. However, App B still presents the “create a login” flow and asks the user to choose/share their name and email again. The system prompt also shows App B’s display name, not the web Services ID name or App A’s primary App ID name. This could confuse users into thinking they are creating a separate App B account rather than signing into the same account used by App A and the website. Because of that, users may choose a different name/email option, including a different Hide My Email choice, which could lead our backend to treat the sign-in as a separate account if the Apple identity token differs by client configuration. I'm trying to confirm whether this prompt/UI behavior is expected for a grouped App ID, and whether the Apple identity token’s sub claim should remain stable across App A, App B, and the associated web Services ID.