Sign in with Apple: "Sign Up Not Completed" for every App ID in our team — framework returns canceled (1001) with empty userInfo

Privacy & Security Sign in with Apple Authentication Services Sign in with Apple

Created Jul ’26

Replies 89

Boosts 6

Views 15k

Participants 74

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: <empty> NSUnderlyingError: <none>

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.

Keirajayde OP

Team ID: 3CKFWN9ZBM Bundle ID: app.kardea App: Kardea (App Store ID 6793991476), live on the App Store since September 7, 2026

Symptom: the native Sign in with Apple sheet appears, Face ID succeeds, then the sheet shows "Sign Up Not Completed". No credential is returned to the app, and no request ever reaches our backend. Not a single Apple-created account exists in our database since the App ID was created in July 2026. This happens for every user and every build, on both TestFlight and App Store builds.

Configuration verified on our side:

App ID app.kardea has Sign in with Apple enabled as a primary App ID.
The signed binary and its App Store provisioning profile both carry the entitlement com.apple.developer.applesignin = ["Default"].
The app uses ASAuthorizationAppleIDProvider with requestedScopes fullName and email.
Our backend verifies the identity token against https://appleid.apple.com/auth/keys.

This matches the server-side registration issue described in Developer Forums thread 837986, where the reported signature is "No applications were found with the provided Client ID" and the app receives ASAuthorizationError.canceled with an empty userInfo. Several teams listed in that thread were repaired server-side with no client changes.

Please check whether our Team ID 3CKFWN9ZBM and App ID app.kardea are correctly registered in the Sign in with Apple authorization database.

UnleashedVision OP

@Paris X Pinkney — same issue, still present, team not yet in the list.

Team ID: U8D7WQV7NA Bundle ID: vision.unleashed.mobile (App ID registered July 2026)

Capability (APPLE_ID_AUTH, primary app consent), entitlement in both the signed binary and the embedded provisioning profile, and agreements all verified. Reproduced 2026-09-08 20:24 +0100 on iOS 26.6 (TestFlight build). akd logs with the Accounts profile installed:

Fetching developer team for client with ID: vision.unleashed.mobile Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 No applications were found with the provided Client ID: vision.unleashed.mobile AlertHandler called with error: Error Domain=AKAuthenticationError Code=-7003 {AKClientBundleID=vision.unleashed.mobile}

Sign in with Apple works in unrelated apps on the same device and Apple Account. Also reproduced by App Review (2.1(a) rejection).

Filed as FB24705640 with the sysdiagnose attached. Could our team be added to the server-side re-registration queue?

morsels OP

Same issue here. Team ID K322BCXN7N, bundle ID com.vmatusevic.ListReel, App ID registered 2026-09-01 with Sign in with Apple enabled as a primary App ID. The sheet renders, authentication succeeds, then "Sign-Up Not Completed"; the app gets no callback. Reproduced in a development build on 2026-09-02 and in a TestFlight build under an App Store profile on 2026-09-09. Feedback filed: FB24708261. Could someone please re-provision the team's Sign in with Apple registration?

bug_report_padi OP

@Paris X Pinkney — could the same server-side team-registration fix applied to GW7XA5CX69 and FRL3DTJQ62 be applied to 44P7GPF4HC? Same signature as the rest of this thread, captured today, with a server transaction ID to pull it from your side. Team ID: 44P7GPF4HC · App ID: app.padimu (resource 3XPCF75FKV) · App Store ID 6797140332 Feedback Assistant: FB24712097 — sysdiagnose with the Accounts/AuthKit profile attached Server transaction: ptxid 1b8098e2-e4e0-439a-b0a5-3bd269b5be41 (2026-09-09 08:41:07 CEST) The app has been live on the App Store since 24 August 2026: 0 successful Sign in with Apple authorizations out of 88 accounts created. Every other sign-in path works. Device log — iPhone, iOS 23G83, TestFlight build, Accounts/AuthKit profile installed: 08:40:53.695 akd [authkit:siwa] Client has default access level in SiwA entitlement 08:40:53.698 akd [authkit:siwa] Setting clientID to app.padimu 08:40:53.698 akd [authkit:siwa] Setting teamID to 44P7GPF4HC 08:40:53.705 akd [authkit:siwa] Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 08:40:53.705 akd [authkit:siwa] No applications were found with the provided Client ID: app.padimu 08:41:07.731 akd [authkit:core] { ec = "-24000"; em = "Invalid client."; hsc = 200; ptxid = "1b8098e2-e4e0-439a-b0a5-3bd269b5be41"; } for executed request (<AKSRPRequest>) 08:41:07.742 akd [authkit:core] SRP authentication with server failed! com.apple.AppleIDAuthSupport Code=2 "M2 missing (bad password)" 08:41:12.827 Runner [authkit:siwa] Authorization failed: AKAuthenticationError Code=-7003 UserInfo={AKClientBundleID=app.padimu} Face ID succeeds 14 seconds before the server rejects the exchange, so this is not a cancellation. As Ozvern noted earlier in this thread, the -6003 line reads as a first-authorization cache miss; the decisive event is the -24000 "Invalid client" GSA response — which is what the ptxid above points to. Client side re-verified today via the App Store Connect API: APPLE_ID_AUTH with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT; the team contains exactly one App ID (app.padimu), no wildcard and no grouped identifiers; com.apple.developer.applesignin = ["Default"] is present in the signed binary, and iOS confirms reading it in the log above. Native ASAuthorizationController, no third-party plugin. Same failure on App Store, TestFlight, debug and Simulator builds, with several Apple Accounts and devices. Happy to verify and close the Feedback the moment it is re-provisioned.

JohnHammer OP

FYI guys, this issue has been solved automatically after a few days.

neil-atr OP

@Paris X Pinkney — same issue, still present, team not yet in the list.

Team ID: Z7B8KX297F (Organization, enrolled 2026-08-31) · Bundle ID: fr.deliciomap.app (App ID D6SNV93YM8, APPLE_ID_AUTH / PRIMARY_APP_CONSENT) · App: DelicioMap, TestFlight Feedback Assistant: FB24688196 (filed 2026-09-07, updated today with the akd capture)

Symptom identical to the rest of the thread: native sheet renders, Face ID succeeds, then "Sign Up Not Completed"; the app receives ASAuthorizationError 1001 with empty userInfo, nothing reaches our backend. Reproduced 2026-09-07 and again 2026-09-09 15:37 CEST on iOS 26.5.1 (23F81), fresh Release build.

akd, 2026-09-07: Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003, then No applications were found with the provided Client ID: fr.deliciomap.app

akd, 2026-09-09: 15:37:04.562 AppleIDAuthSupport: setError: 2:M2 missing (bad password) 15:37:04.563 SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2 15:37:13.254 Error performing auth request: Error Domain=AKAuthenticationError Code=-7003 {AKClientBundleID=fr.deliciomap.app} 15:37:13.256 ASAuthorizationController credential request failed: AuthorizationError Code=1001

Client side verified: com.apple.developer.applesignin = ["Default"] and application-identifier = Z7B8KX297F.fr.deliciomap.app in the signed binary (codesign -d --entitlements). The same Apple Account signs in fine to other teams' apps on the same device.

Could the same server-side team-registration fix applied to GW7XA5CX69 and FRL3DTJQ62 be applied to Z7B8KX297F? Happy to re-test and confirm immediately, and to close the Feedback once repaired.

bug_report_padi OP

Team ID: 44P7GPF4HC · App ID: app.padimu (resource 3XPCF75FKV) · App Store ID 6797140332
Feedback Assistant: FB24712097 (sysdiagnose with the Accounts/AuthKit profile attached)
Server transaction: ptxid 1b8098e2-e4e0-439a-b0a5-3bd269b5be41, 2026-09-09 08:41:07 CEST
Live on the App Store since 24 August 2026: 0 successful Sign in with Apple authorizations out of 88 accounts created. Every other sign-in path works.

DTS Engineer OP

Apple

Hi everyone,

If you have not yet created a Feedback ID for these "Sign Up Not Completed" errors, please submit a bug report via Feedback Assistant:

Gathering required information for troubleshooting Sign in with Apple authorization and token requests

https://developer.apple.com/forums/thread/801173

Remember to include your Team ID, Client ID/Services ID, affected user ID/email, and sysdiagnose logs. Once submitted, please reply with your Feedback ID.

Cheers,

Paris X Pinkney |  WWDR | DTS Engineer

openshimmy OP

Same signature here, on an App ID created in August 2026.

Team ID: 276UBMJFVS Bundle ID / Client ID: com.openshimmy.open (App ID V2XX9T4FG9, platform Universal) App ID created: 2026-08-12; Sign in with Apple capability enabled 2026-08-15 (APPLE_ID_AUTH, PRIMARY_APP_CONSENT) Feedback Assistant: FB24734174 App: OPEN, App Store id 6800488516 (live since 2026-08-13, currently 1.0.17)

Symptom: the native sheet renders, the user authenticates, then "Sign Up Not Completed". ASAuthorizationController returns ASAuthorizationError 1000 (our client instrumentation records the code; 1001 would be recorded as well). No credential, and zero requests ever reach our backend. Zero Apple identities have ever been created for this app; Google sign-in on the same devices works.

Verified: com.apple.developer.applesignin = ["Default"] in the signed App Store binary and its embedded provisioning profile; bundleIdCapabilities shows PRIMARY_APP_CONSENT; membership, certificate and profile all valid.

Reproduced on: multiple iPhones and Apple IDs since 2026-08-18, across every App Store build from 1.0.6 to 1.0.17 (from timing, App Review devices included). One anomaly for the record: a single iPhone did receive a credential from the sheet on 2026-08-17, and the same phone hit "Sign Up Not Completed" the next day.

Sysdiagnose with the Accounts/AuthKit profile available on request as soon as we have an affected device in hand.

nestlingstudios OP

Adding another team to this. Same chain, same signature.

Team: J9HSK83G24 (Nestling Studios LLC, Organization). Enrolled 2026-07-18, approved 2026-07-20. Bundle: com.NestlingStudios.PocketReef, App ID resource 7MPF2PXGJG. Sign in with Apple enabled on the App ID 2026-08-04. It has never worked once - no working period that later broke.

Behaviour, identical to the reports above: sheet renders correctly with the right app name and the right Apple Account, Touch ID succeeds, sheet then shows "Sign Up Not Completed", dismisses, and ASAuthorizationController returns ASAuthorizationError.canceled (1001) with an empty userInfo. Some of our iPhones return 1000 instead, in the same second as the request, same sheet text - which matches what others have said here about the code varying while the behaviour does not. Our production diagnostics for the last 30 days of retention hold 25 attempts from 11 distinct installs across 7 hardware/OS combinations and ZERO successes. No identity token is ever minted, so nothing reaches our IdP.

Device log signature is the one already posted in this thread, captured first-party on our own device on 2026-09-11 and reproduced three times between 00:57 and 02:16 UTC that night: akd [authkit:siwa] fetching the developer team for the client ID, AKSQLError -6003, "No applications were found with the provided Client ID" - then the GSA SRP sign-up exchange comes back HTTP 200 with the server proof missing ("M2 missing (bad password)", "serverProvidedData is nil"), the sheet shows AUTH_ALERT_SIGN_UP_NOT_COMPLETED, the whole SRP attempt repeats identically, and only then does AuthKit give up with AKAuthenticationError -7003 and hand the app 1001. Worth spelling the order out because I read it backwards at first: -7003 is the dismissal 12-15 seconds and two failed SRP attempts downstream, not the cause. The cause is a 200 with nothing in it. Touch ID succeeds before that happens (shouldContinueWithRequest returning result YES), so a stale stored password cannot explain it either.

Ruled out on our side, each read off the artefact rather than assumed:

com.apple.developer.applesignin = ["Default"] in the signed binary (codesign -d --entitlements on the archive that produced the uploaded build).
Same entitlement in the embedded provisioning profile (security cms -D). Profile created 2026-08-04T20:27:42Z, i.e. AFTER the capability was enabled, so it is not a stale profile.
App ID capability from the ASC API: APPLE_ID_AUTH with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT. Primary, ungrouped.
No wildcard App IDs anywhere in the team. All five identifiers are explicit. I know that is the usual suggestion; it does not apply here.
requestedScopes is empty by design on our side. Reports in this thread that DO request .fullName/.email fail identically, so that is not it either.
Survives reinstall, device restart, Apple Account sign-out and back in, a second Apple Account, and a second device class.
The same Apple Account signs in successfully to another team app on the same device (Goat Simulator: Pocket Edition is listed under Settings > Apple Account > Sign in with Apple), so the account and the device are fine.
Account and device state verified clean before one of the reproductions: two-factor on with a verified trusted number and eight trusted devices, no pending account prompt, Screen Time Content & Privacy Restrictions all set to Allow, not supervised, no MDM. Same failure.

App Review reproduced it on an iPad running iPadOS 26.6 and rejected our 1.0 under Guideline 2.1(a) on exactly this. We have since resubmitted 1.0 with Sign in with Apple withdrawn rather than ship a button that cannot work, and we want it back.

FB: FB24737678, with a full sysdiagnose captured 14 seconds after a reproduction, two extracted log chains and a screen recording attached. The Accounts/AuthKit logging profile was NOT installed, so the Client ID and team ID render as <private> in the akd lines - I can supply a profiled capture the same day if that matters.

Ask is the same as the resolved reports here (GW7XA5CX69, FRL3DTJQ62): a server-side re-registration of the team with the Sign in with Apple backend so the client-ID-to-team lookup resolves. Happy to supply anything else useful.

Oranzieus OP

20h

Same signature here, still failing as of today.

Team ID: CKR4VUYMCD
Bundle ID / client_id: com.packandpeek.app
Feedback: FB24739690 (sysdiagnose with the Accounts/AuthKit profile attached)
Devices: iPhone 15 Pro Max and a brand-new iPhone 17, iOS 26.6, with two different Apple Accounts (one that had never used the app)
Distribution: TestFlight

Capability enabled 10 August 2026. Native sheet renders, biometric completes, then "Sign Up Not Completed"; delegate receives ASAuthorizationError 1001 with empty userInfo only after dismissal; no credential, no request ever reaches our backend.

Verified before posting: com.apple.developer.applesignin = (Default) in the signed binary's code signature and in embedded.mobileprovision; App ID capability via ASC API is APPLE_ID_AUTH with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT; single App ID in the team, no wildcard; agreements accepted. Tried: portal re-save, delete/re-create of the capability via API, new provisioning profile generated after the re-registration with a new build signed against it, replacing our Capacitor plugin with a first-party ASAuthorizationController implementation identical to Apple's sample, Share My Email and Hide My Email, device restarts, and a month of waiting. No change.

This is blocking our App Store release - we were rejected under Guideline 4.8 and Sign in with Apple is the required remedy. @Paris X Pinkney, could Team ID CKR4VUYMCD be added to the server-side registration fix? Happy to provide anything else needed.

Pavan524 OP

20h

Same issue here

Integration done on iPhone app.

Team ID: 6FXUMT5X23

Error: Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.codebrew.applelogintest123} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={_LSLine=75, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler, _LSFile=LSDReadService.mm, NSDebugDescription=process may not map database} Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={_LSLine=75, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler, _LSFile=LSDReadService.mm, NSDebugDescription=process may not map database} Failed to get application extension record: Error Domain=NSOSStatusErrorDomain Code=-54 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)" "Error" "The operation couldn’t be completed. (com.apple.AuthenticationServices.AuthorizationError error 1001.)"

Pavan524 OP

20h

FeedbackID: FB24711730

cverbah OP

Same issue here, still unresolved. Adding our details so DTS can correlate.

Team ID: KT9P85VC2P
Bundle ID / Client ID: com.cvergarabah.piya
Feedback: FB24607596 (open, full sysdiagnose attached), FB24569985 (original, closed)

Same signature: the native sheet shows "Sign Up Not Completed" after Face ID confirmation, and the delegate receives ASAuthorizationError 1000/1001 with no credential. AuthKit logs from the sysdiagnose:

AKSQLError -6003 "No applications were found with the provided Client ID" AppleIDAuthSupport Code=2 "M2 missing (bad password)" AKAuthenticationServerError -24000

Verified: APPLE_ID_AUTH with PRIMARY_APP_CONSENT on the App ID; com.apple.developer.applesignin = ["Default"] in both the signed binary and the provisioning profile. Reproduced on two iPhones (iOS 18.7.8 and 26.6) with two different Apple Accounts. Google Sign-In works end to end in the same build.

This is blocking our first App Store submission. @Paris X Pinkney, could you please check whether our team's Sign in with Apple registration can be repaired like the others in this thread? Happy to provide fresh logs or a new reproduction at any time.

Thank you!