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.

We are hitting the same Sign in with Apple failure described in thread 837986, with an identical log signature. Posting our team details in case it helps the ongoing investigation. Team ID: CDLWFYN589 Bundle IDs: br.com.cesto, br.com.cestoparceiros App IDs created: 2026-08-20 (both recreated on that date) Build: TestFlight, iOS 26, physical iPhone SUMMARY Every first-time Sign in with Apple authorization fails with "Sign Up Not Completed". The Apple sheet renders correctly, with the right app name and the user's account. The user authorizes. The failure happens AFTER consent, in the SRP exchange with the Apple ID server. Our backend is never reached - signInAsync never returns a credential, so no server-side code of ours participates in the failing step. DEVICE LOG (akd, 2026-09-05 17:21:06-13, UTC-3) Client has default access level in SiwA entitlement Fetching developer team for client with ID: Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 No applications were found with the provided Client ID: Application has no shared credentials Using personal credential state - 2, error - Error Domain=AKAuthenticationError Code=-7074 presenting authorization UI for request <- sheet appears Got a response from user <- user authorizes No password, but CK is available. Will ask for ck-based auth. Task <59764A72-...> received response, status 200 AppleIDAuthSupport: setError: 2:M2 missing (bad password) Invalid/missing value for key acname: (null) Invalid value for key ut: (null) Invalid value for key authType: (null) SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2 The server returns HTTP 200 with the server proof (M2) absent. The "bad password" string appears to be the generic label for error 2 rather than a diagnosis - there is no password in this exchange, as the preceding line shows (No password, but CK is available). WHAT WE HAVE ALREADY VERIFIED Capability APPLE_ID_AUTH present on both App IDs, with APPLE_ID_AUTH_APP_CONSENT: PRIMARY_APP_CONSENT (read back through the App Store Connect API). com.apple.developer.applesignin: [Default] present in the SHIPPED .ipa, verified with codesign -d --entitlements :- on the extracted payload rather than on the archive. Embedded profile is "iOS Team Store Provisioning Profile" and carries the entitlement (security cms -D -i embedded.mobileprovision). Bundle IDs match across the project config, Identifiers and App Store Connect. No other App ID in the team declares APPLE_ID_AUTH. Program License Agreement accepted on 2026-08-25; 2FA active on the account. Requesting only fullName, with no email scope, does not change the outcome. The log line "Client has default access level in SiwA entitlement" is what closes the client-side question for us: the entitlement is present and read correctly ON DEVICE, not merely present in our build output. QUESTION Given the confirmation earlier in thread 837986 for team GW7XA5CX69 - same build and same configuration starting to work with no changes on their side - this looks like the same server-side condition affecting recently created App IDs. Could our Team ID be included in that investigation? Happy to file a Feedback with the full log attached and post the number here if that is the preferred route.

We are designing account deletion and token storage for Sign in with Apple across a native iOS flow and a web-based flow used by our Android client. Apple’s documentation describes a successful /auth/revoke request as revoking the user session associated with the supplied token. It also states that the client_id used for revocation must match the client_id used during authorization. We need to understand the documented revocation boundary: whether it is limited to the supplied token or session, or whether it also affects other tokens associated with the same Apple user, client ID, primary app group, or Developer Team. Definitions: A: Our primary App ID. B: A Services ID associated with primary App ID A. C: Another App ID grouped with primary App ID A. D: An App ID in the same Developer Team but belonging to a different primary app group. Assume that the tokens in the questions below belong to the same Apple user. Questions: For a refresh token issued under each of A, B, C, and D, which authorizations or tokens under A, B, C, and D are invalidated by a successful revocation request? Please clarify the result separately for each starting client ID (A, B, C, and D), rather than assuming that the relationship is symmetrical. Please also state whether the result differs depending on whether the identifiers belong to the same primary app group. If multiple refresh tokens have been issued for the same user under the same client_id, does revoking one refresh token invalidate the other refresh tokens, or only the user session associated with the supplied token? If an access token is revoked, is the refresh token from which it was derived also invalidated? Conversely, if a refresh token is revoked, are access tokens derived from it also invalidated? When processing an account deletion request, is revoking one stored token sufficient to remove the user’s complete Sign in with Apple authorization for our Developer Team, or must every refresh token and access token that we have stored be revoked individually? We are asking for the documented behavior that an implementation can safely rely on, rather than behavior observed in a single test. If the only guaranteed scope is the user session associated with the supplied token, please confirm that explicitly.

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.

Following the pinned post "Gathering required information for troubleshooting Private Email Relay with Sign in with Apple" (thread 794191, which is locked, so I am posting here as instructed): I have filed FB24564316 with the required information. Since 28 July, every message from our app's sending domain to @privaterelay.appleid.com addresses is rejected by iCloud Mail with 554 5.7.1 [HM08], so users who signed up with Sign in with Apple and Hide My Email cannot receive their sign-in emails. Plain-text messages with no URL bounce as well, SPF/DKIM/DMARC pass on two independent sending systems, and external reputation checks are clean, so this looks like a false positive on the sending domain. The feedback contains the App ID (6761705463), Services ID, SMTP error codes and transaction IDs. iCloud postmaster case 21382576 and Developer Support case 20000139732014 did not resolve it. Happy to provide message headers. FB24564316

Sign in with Apple has failed for every user of our app for four weeks. It fails inside Apple's own authorization sheet, before any credential reaches our code. App ID: com.chorestoreapp.app (SJRRC8Q327) Team ID: T4KD7949GL App Apple ID: 6797335710 — TestFlight builds 7 and 8, version 1.0.1 Symptom: The authorization sheet appears and behaves normally. When the fingerprint read is complete, it immediately fails with "Sign Up Not Completed". No credential is returned. When I cancel, it returns ERR_REQUEST_CANCELED, consistent with the sheet being dismissed by the user after being unable to sign in. Sign in with Apple works on the affected device and Apple ID. Downloading an unrelated App Store app and creating a new account with Sign in with Apple succeeded immediately, on the same iPad, with the same Apple ID, minutes before and after a ChoreStore failure. Before that test, Settings → [name] → Sign in with Apple was empty, so the account had never completed the flow — it is demonstrably capable of it now, for other apps. Reproduced with: two Apple IDs, two physical devices, both "Share My Email" and "Hide My Email", Wi-Fi and cellular, and two builds on freshly regenerated credentials. Verified on our side: The signed binary contains com.apple.developer.applesignin = ["Default"] The embedded provisioning profile includes the same entitlement App ID capability, read back from the App Store Connect API: APPLE_ID_AUTH with [{"key":"APPLE_ID_AUTH_APP_CONSENT","options":[{"key":"PRIMARY_APP_CONSENT"}]}] Provisioning profile IOS_APP_STORE, state ACTIVE, expires 2027-08-20 Distribution certificate valid to 2027-08-20 Exactly one bundle ID in the account; no grouped App ID The client call is the standard one, with no nonce or custom parameters: signInAsync({ requestedScopes: [FULL_NAME, EMAIL] }) The distribution certificate and App ID survived an Individual → Organization conversion unchanged (re-verified after the conversion) Why I'm posting rather than filing a code-level request. The request form requires a focused sample Xcode project. A sample cannot demonstrate this: anyone who opens it must sign it with their own team, which changes the App ID — the one variable that is failing. The fault appears to be server-side provisioning for this specific App ID, which no sample can carry. Question: Given the client configuration verifies correct and Sign in with Apple works on the same device and Apple ID for other apps, what would cause the authorization sheet itself to fail for a single App ID, and how can that be investigated or reset? Happy to provide a sysdiagnose, timestamps of specific failed attempts, a screen recording showing the working and failing cases minutes apart, or a TestFlight build.

Sign in with Apple for the web returns invalid_client at the authorization request for every Services ID in our team. The failure occurs before any token exchange, so no client secret is involved. Team ID: UGZTH42J5G Primary App ID: UGZTH42J5G.com.nearbuddy.mobile (Sign in with Apple enabled; "Enable as a primary App ID" selected) Services IDs: com.nearbuddy.mobile.signin com.nearbuddy.mobile.signin2 (created solely as a control) Both Services IDs are configured with: Sign in with Apple: enabled Primary App ID: UGZTH42J5G.com.nearbuddy.mobile Domain: dkhtjkcygbpomaummdih.supabase.co Return URLs: https://dkhtjkcygbpomaummdih.supabase.co/functions/v1/auth-apple-web/callback https://dkhtjkcygbpomaummdih.supabase.co/auth/v1/callback Failing authorization request: GET https://appleid.apple.com/auth/authorize client_id=com.nearbuddy.mobile.signin redirect_uri=https://dkhtjkcygbpomaummdih.supabase.co/functions/v1/auth-apple-web/callback response_type=code id_token response_mode=form_post scope=name email state= nonce= Apple responds with: invalid_client Invalid client. The same failure is reproduced: with both Services IDs; in Safari; in Chrome on Android; via curl; and using the authorization URL generated by Supabase GoTrue. The failure occurs before authentication/consent and before any authorization code or ID token is issued. Membership is active until March 18, 2027. The Account Holder is active and there are no pending membership or agreement banners. A fresh control Services ID reproduces exactly the same failure. Feedback Assistant report: FB24549460 Please inspect the Sign in with Apple provisioning/configuration state for Team UGZTH42J5G and determine why the registered Services IDs are not being recognized at the authorization endpoint.

Hi Apple Developer Support, We are implementing Sign in with Apple for our web application hosted on example.com. In the Service ID settings, we have configured the following: Service ID (client_id): com.example.service.local Web Domain: example.com Return URL: https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple We also tested login via the following URL from our web application: https://appleid.apple.com/auth/authorize?response_mode=form_post&response_type=code&client_id=com.example.service.local&scope=name%20email&state=2f9gMY1rTe12-O7Wbnb7KWe504HQ0KWBSHTKHbg9ZEY=&redirect_uri=https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple However, we’re receiving an invalid_client error after submission. Our questions: Is it valid to use an ngrok URL like https://2db2-121-160-153-88.ngrok-free.app/... as the Return URL for development and testing? Does the Web Domain need to match the ngrok domain, or is it enough to register the production domain (e.g., example.com)? Is there any propagation delay or approval process after updating the Return URL in the Service ID? Is the client_id strictly required to match the Service ID exactly? We would greatly appreciate any insights or best practices to help us resolve this issue. Thank you in advance!

Sign in with Apple is failing for every user, on every device, for our live App Store app. Each attempt fails inside Apple's native sign-in sheet with the error "Sign-Up Not Completed" — before any of our code runs (no ASAuthorizationController delegate callback is reached). Environment / identifiers: Bundle ID: online.framenet.app Team ID: 5F2256QJNT App Store app: FrameNet, App ID 6799345029 (approved and live as of Aug 24, 2026) Timeline: Last worked: Aug 8, 2026 Failing on every attempt since: Aug 14, 2026, across builds 12–16 Our sign-in code is unchanged between the working and failing period Already verified / attempted on our side: Sign in with Apple entitlement is present in the signed builds (confirmed via codesign entitlement dump) Capability is enabled on the App ID in Certificates, Identifiers & Profiles Provisioning profile is valid and includes the capability Removed and re-added the Sign in with Apple capability and regenerated the provisioning profile on Aug 17 — no change Google Sign-In in the same app works normally, so networking and the rest of the auth stack are fine Reproduced on multiple physical devices and Apple IDs Because the failure occurs inside Apple's own sign-in sheet before our code executes, this appears to be a server-side state problem with Sign in with Apple for our App ID, and nothing we change client-side has any effect. We were forced to ship v1.0 with Sign in with Apple disabled. A Developer Support case is already open for this: case 20000140460775. A screen recording and full environment details have been provided in that case. Has anyone from Apple seen this "Sign-Up Not Completed" state, and can engineering inspect/repair the server-side Sign in with Apple configuration for this App ID?

Sign in with Apple has never completed for our app. The native sheet presents correctly (name, Share/Hide My Email), but on confirmation it shows "Sign Up Not Completed" with a red exclamation. No identity token is returned; the delegate receives ASAuthorizationError 1001 only after the sheet is dismissed. The failure happens entirely inside the system sheet, before any callback reaches app code. Environment: iPhone 15 Pro Max / iOS 26.6, TestFlight builds. The Sign In with Apple capability was newly enabled on the App ID five days ago and the flow has failed on 100% of attempts ever since. (I'm withholding the Team ID / bundle ID here since this is public — happy to share them with an Apple engineer via the open support case or a Feedback report.) Implementation - identical to Apple's "Implementing User Authentication with Sign in with Apple" sample; we even replaced the third-party wrapper we originally used with this first-party version to rule it out, and the failure is unchanged: let provider = ASAuthorizationAppleIDProvider() let request = provider.createRequest() request.requestedScopes = [.fullName, .email] let controller = ASAuthorizationController(authorizationRequests: [request]) controller.delegate = self // controller strongly retained until completion controller.presentationContextProvider = self controller.performRequests() Verified correct (not assumed — extracted/inspected directly): Signed binary entitlements (extracted from the distributed IPA): com.apple.developer.applesignin = (Default), with the correct application-identifier and team-identifier for our team embedded.mobileprovision in the bundle contains the same entitlement App ID capability read back via the App Store Connect API: APPLE_ID_AUTH with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (portal shows "Enable as a primary App ID") Exactly one App ID in the account; no wildcard, no duplicates Program License Agreement accepted; nothing pending Already tried, no change: re-saving the capability in the portal; deleting and re-creating the capability via the App Store Connect API; generating a new provisioning profile after that re-registration and shipping a new build signed with it; Share My Email and Hide My Email; device restarts (iCloud + 2FA active); waiting 5+ days for propagation. This matches threads 789588, 789418 and 789323, and the service-side configuration issue described in thread 790827 (invalid_client / "Sign Up Not Completed" for developer accounts that created or edited app configurations, resolved server-side with no developer action). A Developer Support case and a TSI are already open. Question for Apple engineers: with the client implementation identical to the official sample and every developer-side artifact verified, is there anything left on the developer side that can produce this - or can the Sign in with Apple service-side registration for our client_id be checked? This is blocking an App Store release (the app was rejected under Guideline 4.8 and Sign in with Apple is the required remedy). A sysdiagnose captured during reproduction is available, and I can provide the Team ID, bundle ID and case numbers privately on request.

Case #20000132024383 has been filed with Developer Support; posting here as well for visibility Hi Apple Developer Support team, We are experiencing a release-blocking issue: Sign in with Apple always fails server-side with AKAuthenticationServerError -24000 for our bundle com.dadilo.app, on all devices and all Apple IDs we have tested, while the same devices and accounts use Sign in with Apple successfully in other apps. IDENTIFIERS Team ID: HF53KC83Z3 (Individual - Nguyen Duy Mao) Bundle ID: com.dadilo.app (App ID resource 96Q4FAZ8PF) App Store Connect app: "Dadilo: Giup viec nha" - Apple ID 6782634291 (unreleased; TestFlight builds 1.0.0 (120-126)) Client: native ASAuthorizationAppleIDProvider request (Flutter sign_in_with_apple plugin). No web/Services-ID flow is involved. SYMPTOM Every Sign in with Apple attempt completes the system sheet (Face ID/password succeeds, scope selection is shown), then iOS shows the alert "Sign-Up Not Completed". The app's ASAuthorizationControllerDelegate receives ASAuthorizationError code 1001. No credential is ever issued. Device syslog at the exact moment of each failure (captured 2026-08-07 and 2026-08-08): akd: SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2 AKRemoteViewController did complete with authorization (null), error Domain=com.apple.AppleIDAuthSupport Code=2, NSUnderlyingError Domain=AKAuthenticationServerError Code=-24000 akd: Creating AKAuthenticationServerResponse with status contents: (null) akd: Invalid/missing value for key acname: (null); Invalid value for key ut: (null); Invalid value for key authType: (null) The server rejects the request and returns an EMPTY payload; -24000 is the client's reaction to it. An initial tap sometimes logs AKAuthenticationError -7003 first. REPRODUCTION - fails in EVERY combination Devices: iPad mini (iPad16,2, iPadOS 26.5.2) and an iPhone (iOS 26.x) - fails on both Apple IDs: 2 different accounts (2FA enabled, adult, region Vietnam) - fails on both Builds: TestFlight 1.0.0 builds 122, 124, 125, 126 - fails on all Request shape: the standard request (email + fullName scopes, SHA-256 nonce) AND a minimal request (no scopes, no nonce) both fail identically DECISIVE CONTROL TEST (2026-08-08) On the SAME iPad, SAME Apple ID, SAME network, minutes after our app failed,le authorization for another app (ChatGPT - never previously authorized on this account) succeeded normally. So fresh-authorization SRP works for this erver issues credentials for other bundles but rejects com.dadilo.app specifically. Existing authorizations (Notion, Grab, Shopee, Goodnotes) alsocounts. ALREADY VERIFIED / RULED OUT Entitlement com.apple.developer.applesignin = [Default] present in the binary; the provisioning profile contains the entitlement (decoded and checked); the authorization sheet opens and biometric completes, so the entitlement is honored App ID capability APPLE_ID_AUTH enabled, APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (verified via App Store Connect API); no grouped-app configuration conflicts on the team Program License Agreement issued 2026-06-18, accepted 2026-06-21; no pendi Test Apple IDs are healthy: 2FA on, adult birthdays, no Family restrictionh Apple with other apps No stale authorizations: this app is not listed in Settings > Sign in with- Capability re-provisioning attempted 2026-08-08: deleted and re-created APnerated a brand-new App Store provisioning profile, rebuilt and re-tested(build 125) - identical -24000 failure Apple System Status showed no Sign in with Apple outage during any test REQUEST AKAuthenticationServerError -24000 is not publicly documented. Everything clecks out, and the failure is 100% reproducible for this bundle ID only.Please inspect the server-side Sign in with Apple configuration/state for co3 and advise what is rejecting credential issuance.The app is complete and ready for App Store submission; Sign in with Apple ier Guideline 4.8, so this issue is blocking our first release. Fullidevicesyslog captures from both days are available on request. Thank you, Nguyen Duy Mao Team HF53KC83Z3

Sign in with Apple never completes for our app. The authorization sheet presents, the user confirms, and we get ASAuthorizationError 1000. The akd log shows the local entitlement check PASSING and the failure happening server-side. Environment: native ASAuthorizationAppleIDProvider (no web flow, no Services ID), TestFlight build, iOS 26. New App ID created 2026-08-06. akd, abridged — local check passes: akd Requesting password only: NO akd Client has default access level in SiwA entitlement akd Client has underage-users access level in SiwA entitlement sheet presents, user confirms: akd presenting authorization UI for request akd Remote view sent a user response event akd Attempting authorization with response then the server rejects it, after returning HTTP 200: akd Adding passwordlessToken: NO, and idmsDataToken: NO, to auth-params akd No password, but CK is available. Will ask for ck-based auth. akd Performing SRP request with context akd Task ... received response, status 200 content K akd AppleIDAuthSupport: setError: 2:M2 missing (bad password) akd Invalid/missing value for key acname: (null) akd SRP authentication with server failed! Domain=com.apple.AppleIDAuthSupport Code=2 akd Error performing auth request: Domain=AKAuthenticationError Code=-7003 What we have already ruled out: Sign in with Apple enabled on the App ID, configured as "Enable as a primary App ID" (verified in the portal UI, not just via the App Store Connect API). Provisioning profiles deleted and regenerated AFTER enabling the capability, twice, the second time a full day later. The embedded .mobileprovision in the shipped build contains com.apple.developer.applesignin = (Default). The signed binary carries the entitlement (codesign -d --entitlements on the archive). More than 24 hours elapsed since enabling the capability, per the guidance on -7003 in thread 789697. requestedScopes tried as both [.email] and [.fullName, .email]. App deleted and reinstalled; device restarted. Reproduced on a SECOND device (an iPad) that had never had the app installed. Control: a third-party App Store app created a brand-new Sign in with Apple association (it prompted for name, so first-time consent) on the same device and same Apple ID, minutes after our failure, so the account and device can create new associations. Question: what causes Apple's identity service to reject the SRP exchange for one client while accepting it for others on the same device and account? Is there additional App ID or account state we cannot see from the portal? Happy to provide the full akd log.

Hello, I’m transferring an app from my individual account to my corporate developer account. I’m the primary owner of both accounts. I’m trying to transfer the users that used Sign In with Apple and this is what I did: I generated the transfer identifier for all the users that used Sign In with Apple from the database (50.000 users → 100% success rate) I’m using the transfer identifier previously generated to create the new Apple ID and private email address of the user. (40% success rate) I successfully generated new Apple ID and private email address for 20.000 users but for the other 30.000 users I cannot generate it because I get { error: 'invalid_request’ } on the migration endpoint (/auth/usermigrationinfo), even though I'm using the same request parameters as the ones that are working. I couldn’t find any difference between users that could be migrated and the users that couldn’t. It doesn’t matter if they are old users or new users. What I found is that I can generate the new Apple ID and private email address if the user signs in with Apple for the first time after the app transfer. Then I can use the “transfer_sub” that I have stored for the user to generate the new user details. The same process worked fine for another app that I transferred. Something seems to be broken only for this app on 60% of the users that used Sign In with Apple. Please let me know if you need further information Best, Cosmin

In order to use Sign in with Apple, I issued a JWT client according to the instructions and was able to connect without any problems, but suddenly an INVALID_CLIENT error started to occur. The error was resolved by re-obtaining the JWT client token and resetting it. The validity period of the JWT client token is 6 months and it has not expired yet, but I would like to know why I am getting an INVALID_CLIENT error.

I am looking for help diagnosing a Sign in with Apple failure that occurs after Face ID and before a credential is returned. Environment iPhone 15 Pro iOS 26.2 Xcode 26.3 TestFlight distribution builds Team ID 42U……D944 Bundle IDs com.vybers.vybers-ios com.vybers.vybers Reproduction Install the app from TestFlight. Tap Sign in with Apple. Complete Face ID. Face ID succeeds but the authorization sheet reports that registration could not be completed. The app receives no ASAuthorizationAppleIDCredential and no identityToken. The same behavior occurs Across multiple builds. On multiple physical devices. With multiple Apple IDs. In both Bundle IDs belonging to the same team. In Apple's official Juice sample app using the official Sign in with Apple flow. Control experiment The same iPhone successfully signs in with Apple in a newly downloaded unrelated App Store app. The relevant device log captured immediately after the failure includes Apple server response HTTP 200 AppleIDAuthSupport setError 2M2 missing bad password SRP authentication with server failed AKRemoteViewController did complete with authorization null AKAuthenticationServerError Code=-24000 The “bad password” text is confusing but the Apple ID works in unrelated apps and the failure happens after successful Face ID. The application server is never contacted because no credential or identityToken is produced. Could this be caused by a team-scoped Sign in with Apple/AuthKit registration or synchronization problem rather than by the client implementation or server-side token verification In particular I would appreciate guidance on Checking the Sign in with Apple registration for the team. Checking whether multiple client IDs in one team can become stale or out of sync. Whether an individual Developer Program membership changes any requirement for this flow. Which diagnostic information Apple needs to investigate the AuthKit backend response. I can provide the full Team ID build details signing entitlements and a sysdiagnose through a private support case.

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

Hi everyone, I recently purchased an Apple Developer Membership using a newly created Apple Account. Currently, I am logged into this developer account only inside the Apple Developer app on my iPhone. Note that this same iPhone is primarily linked to my personal, separate iCloud account. When I try to log into the Apple Developer and App Store Connect portals on my MacBook via the web browser, I do not receive any 2FA verification codes on my phone. Here is what I have tried so far: Checked my SMS messages (no code received). Selected the phone call option for the 2FA code, but I did not receive any call. Verified that my mobile carrier is working normally. Since I cannot bypass the 2FA screen on the web, I am locked out of App Store Connect and cannot manage my membership. Has anyone encountered this issue with secondary accounts on the same device, and how can I resolve it? 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.

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.

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