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.

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

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.

Native Sign in with Apple fails with "Sign Up Not Completed" inside the AuthenticationServices sheet for every NEWLY registered App ID on our team (V4DCPCSM54) — including a clean-room probe App ID created via the ASC API with the capability enabled at creation — while an App ID registered in 2025 on the same team works. Entitlements, profiles, and capability config are all verified correct; capability toggle and fresh builds change nothing. This matches the server-side registration issue described in thread 790827. Filed as FB[23726069] with full details. Would appreciate DTS taking a look — this is currently blocking our App Store review (rejected 2.1(a)).

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.

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.

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

This is our second App Store submission for Rex, a social entertainment discovery app whose core features depend on account-based personalization, saved history, and social/group functionality. Rex’s core features include Rex AI, which provides personalized movie and TV recommendations, along with social watchlists and Party Mode for group recommendations. These features do not function in any meaningful way without an account because they rely on user preferences, saved history, social connections, and persistent recommendation data to deliver the intended experience. Our app is being rejected under Guideline 5.1.1(v), even though account-based functionality is central to the premise of the product. Sign-in is not being used as a gate in front of otherwise accessible content. It is required because the product itself depends on an account-based experience. We have now received the same generic rejection message twice, with no indication that our previous responses were reviewed or considered. We submitted detailed explanations of how Rex works and why sign-in is foundational to the experience, but those points have not been acknowledged or addressed. The responses we have received do not engage with the specific nature of our app, do not address the 5.1.1(v) exception for apps whose core functionality is account-dependent, and appear to repeat the same form language without responding to the context we provided. This is a significant investment of time and resources, and we are trying to understand what Apple is specifically asking us to change. We are not trying to gate free content behind a login. We are trying to ship a product that, by design, requires an account for its core functionality to work. Can someone from Apple or the developer community help clarify how Guideline 5.1.1(v) should be applied to apps where personalization, social features, saved history, and group recommendations are the core product experience?

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.

I was experiencing a weird sign in error when using apple sign in with my app and wanted to put it here for anyone else who might experience it in the future, and so apple can make this requirement more clear. I was using CloudKit and apple sign in. If you are not using both this probably does not apply to you. Every time I would go to sign in in the iOS simulator I would enter my password, hit "sign in", and everything just froze. The very odd reason for this is if you are using iCloudKit and apple sign in you need to go to specifically the "identifiers" in the "Certificates, Identifiers & Profiles" menu (https://developer.apple.com/account/resources/identifiers/list). And from there you specifically need an App ID Configuration with apple sign in enabled. From there you have to have the same exact bundle identifier in Xcode under project settings(not an upper tab just click your project in the left panel). And that should allow you to both pass validation and have your sign in work. Hope this helps!

Hi Community, We've implemented Sign In with Apple in our application. Our domains are properly registered in the developer console, but we're experiencing inconsistent email functionality with Apple's privacy email service. Some domains work correctly while others show delivery problems, even though all domains have identical configurations. Apple's console displays green verification status for all domains, yet testing reveals that emails to privacy-protected accounts don't arrive as expected. We're using SendGrid as our email service provider, and all domains have valid authentication records (SPF, DKIM, DMARC) in place. Has anyone encountered similar inconsistencies with Apple's privacy email service? Would appreciate any configuration tips or troubleshooting guidance. Thanks.

I am having trouble with one of my apps that will not let me log in via Apple Sign In. I am using Firebase and Firebase UI for the sign in process. I have many other apps with the same exact config that currently work just fine, but this one I have gone as far as completely deleting the targets and rebuilding and it will not return from the login screen I checked the following: Sign in with Apple ID Capability is available in XCode and on the dev certificate on developer.apple.com I have also toggled both of them on and off. I have double checked the config in Firebase to turn on the Apple Login identifier. Again I have toggle it on and off. I have cleaned the project multiple times to no avail. I have logged out and back into my developer account in XCode. It seams like after I put in the correct password to log in, it just never returns to the app, there is no logging. I do get a notified(shaking input box) if I put in an incorrect password, but when I put in the correct one, the login window never dismisses and my app is not notified. I checked the Console and the last message from akd on a working app is: Notifying client (bundle) of credential state change 1. Remote view sent a finish event On the one not working, using the same user and password akd returns: SRP authentication with server failed! Error: Error Domain=com.apple.AppleIDAuthSupport Code=2 "M2 missing (bad password) I have 100% verified I am putting in the correct user password. I was only notified of this issue because Policy is having the same issue logging in during App Review. Also, if I put in a bad password the input window shakes and when this is happening, the input window is not shaking

Hello. I have issue with implementing "Sign in with Apple" on my website. As folow, I have created: App ID identifier: com.livnobus.app (G2F5N5UHYZ) Service ID identifier: com.livnobus.client (B25ZN8P84U) with option enabled "Sign in with Apple" and configuration (Primary App ID and Webiste URLs) Key ID: 43N8XKUW7S with option enabled "Sign in with Apple" and configuration (Primary App ID and Grouped App Ids) When I click "Sign in with Apple" on my website (https://dev.livnobus.com/auth/login), system redirect me to https://appleid.apple.com/ and error show "invalid_client". Redirect URL on my web site is: https://appleid.apple.com/auth/authorize?client_id=com.livnobus.client&redirect_uri=https%3A%2F%2Fdev.livnobus.com%2Fauth%2Fapple%2Fcallback&scope=name%20email&response_type=code&response_mode=form_post&state=eGAgdpLrvskJc26RbTizc9TGwxnL6KAEJOf68pmO&nonce=e7c7a242-1977-47ea-9013-98820c24bfba.eGAgdpLrvskJc26RbTizc9TGwxnL6KAEJOf68pmO There was old Service ID identifier com.livnobus.app-client, for which I lost private KEY, so I have created new one: com.livnobus.client With old Service ID com.livnobus.app-client, https://appleid.apple.com/ shows me Apple form for sign in, but with new Service ID com.livnobus.client there is error "invalid_client" https://appleid.apple.com/auth/authorize?client_id=com.livnobus.app-client&redirect_uri=https%3A%2F%2Fdev.livnobus.com%2Fauth%2Fapple%2Fcallback&scope=name%20email&response_type=code&response_mode=form_post&state=eGAgdpLrvskJc26RbTizc9TGwxnL6KAEJOf68pmO&nonce=e7c7a242-1977-47ea-9013-98820c24bfba.eGAgdpLrvskJc26RbTizc9TGwxnL6KAEJOf68pmO These changes I have made last Friday, and since then I can't use "Sign in with Apple" on my website. Thanks!

We're integrating Sign in with Apple into our iOS app using both SwiftUI and UIKit. The Apple ID login UI appears correctly on real devices, but after tapping Continue, the system immediately stops and shows code 1001. This issue happens across multiple devices and Apple ID accounts, even with no prior login history. We’ve confirmed the following: Sign in with Apple is enabled in both Developer Portal and Xcode Capabilities Automatic signing and provisioning are set correctly Device is signed into iCloud and system time is synced Performed clean build, app reinstall, and other standard debugging steps We suspect that the sign-in process may not be completing properly due to some kind of account or server-side restriction, and we’d appreciate any insights into this behavior.

Hi, I've been developing an app with a server. I'm hosting the server on an IPv6-ONLY network that's hidden behind the CloudFlare, so it works flawlessly from the clients point of view, but if server needs to access external resources, they need to be accessible over IPv6. As it turns out, appleid.apple.com doesn't support IPv6, and the Sign In with Apple happens with the help of my server. So, I can't sign users in as Apple doesn't support IPv6 traffic on appleid.apple.com. Are there any plans to support IPv6 in the near future, or should I work on the networking setup to enable IPv4 just for the Apple SSO? Or maybe there's a clever workaround I'm missing?

Hey there, im getting Sign up not complete! even with the official template https://developer.apple.com/documentation/authenticationservices/implementing-user-authentication-with-sign-in-with-apple my developer account is recently renewed, which it has expired for a bit i am using automatic managed signing I have a feel something went wrong my apple developer account id, and also this cause me getting invalid client when sign in with app on web app.

Since a few days, we are hitting AuthorizationError 1000 / 1001 whenever we try to use Sign in with Apple for a new app. We have added entitlements to the app in both release and debug, and setup the services id. Many other devs are complaining about the same issue lately, and it's possible to reproduce on a fresh app id, see this thread: https://www.reddit.com/r/flutterhelp/comments/1lf6kmq/sign_in_with_apple_signup_not_completed

Apple Sign In - "Sign up not completed" Error in Development Build (React Native / Expo) Problem Summary I'm implementing Apple Sign In in a React Native app using expo-apple-authentication. The Apple sign-in dialog appears as expected, but after tapping "Continue," it displays the message: "Sign up not completed". No credential is returned, and the promise eventually rejects with ERR_REQUEST_CANCELED. App Configuration Platform: React Native (Expo SDK 52) Library: expo-apple-authentication v7.1.3 Target: iOS development build (not Expo Go) Bundle ID: com.example.appname.nativetest (new App ID created for testing) Apple Developer Console Setup (Reviewed Carefully) App ID Explicit App ID (not a wildcard) "Sign In with Apple" capability enabled No associated Services IDs or Sign In with Apple Keys Provisioning Profile Development profile created for the test App ID Profile includes the test device and development certificate Installed successfully and used to sign the app Certificates and Signing Valid Apple Developer Program membership Development certificate installed and selected during build App installs and launches properly on the test device Implementation Attempts Attempt 1: Supabase OAuth Method Initially tried using Supabase’s built-in Apple OAuth provider: Configured with team ID, key ID, and JWT credentials Proper redirect URLs and scheme were in place Resulted in OAuth URL pointing to Supabase instead of Apple, with incomplete client ID Ultimately moved to native implementation for improved control and reliability Attempt 2: Native Apple Sign In (Current Approach) Using expo-apple-authentication with the following code: const credential = await AppleAuthentication.signInAsync({ requestedScopes: [ AppleAuthentication.AppleAuthenticationScope.FULL_NAME, AppleAuthentication.AppleAuthenticationScope.EMAIL, ], }); Relevant app.config.js Section: ios: { bundleIdentifier: 'com.example.appname.nativetest', usesAppleSignIn: true, infoPlist: { NSAppTransportSecurity: { NSAllowsArbitraryLoads: true, NSAllowsLocalNetworking: true, }, }, }, plugins: ['expo-apple-authentication'] Observed Behavior AppleAuthentication.isAvailableAsync() → true Credential state → NOT_FOUND (expected for new user) Apple Sign In dialog appears and allows interaction User taps "Continue" → dialog reports "Sign up not completed" Eventually returns: [Error: The user canceled the authorization attempt], code ERR_REQUEST_CANCELED Confirmed Working Aspects AppleAuthentication API is available and initialized App is signed correctly and launches on the physical test device Apple Sign In dialog appears with correct styling and options Same result observed across both Wi-Fi and cellular networks Clean Setup and Debugging Performed Removed all previous build artifacts Created a new App ID and new provisioning profile Rebuilt the app using expo run:ios --device Validated entitlements and provisioning assignments Removed any Services IDs and Apple Sign In keys used in previous attempts Verified ATS (App Transport Security) policies allow dev-time communication Environment Information Device: iPhone (not simulator) iOS Version: 18.5 Xcode: Latest version Apple ID: Developer account with 2FA enabled Build Method: EAS CLI using expo run:ios --device Open Questions Has anyone experienced the "Sign up not completed" issue with a clean native implementation in Expo? Are there known limitations when testing Apple Sign In in local development builds? Could prior Apple ID authorization attempts impact sign-in behavior during testing? Are there any additional configuration steps, Info.plist changes, or entitlements required beyond those listed above? Thank you in advance for any suggestions or guidance. We’re hoping this is simply a configuration detail that needs to be adjusted.