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

Question

Created Jul ’26

Replies 60

Boosts 4

Views 9.8k

Participants 51

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

Answer 1

Minderse OP

2d

Same issue for our team since at least 2026-08-24. Team ID R58645RRYR, client ID com.amenscroll.amenScroll (primary App ID, native app, no Services ID, no grouped App IDs). The sheet renders, the user approves, then "Sign-Up Not Completed". akd shows AKSQLError -6003, "No applications were found with the provided Client ID", GrandSlam postdata HTTP 401, and SRP fails with "M2 missing (bad password)" despite a correct password. Entitlements verified in the signed binary and embedded provisioning profile; APPLE_ID_AUTH with PRIMARY_APP_CONSENT confirmed via the App Store Connect API; deleting and re-creating the capability had no effect. This also cost us an App Review rejection (2.1a, the button reads as unresponsive). Filed as FB24582063. Requesting the same server-side registration repair applied to the other teams in this thread.

Answer 2

kokky OP

2d

Same signature here — adding our team in case it helps Apple batch the server-side fix.

Team ID: 2L9BRR2X97 Bundle ID (primary App ID): com.niman.watagumo Feedback: FB24584055 Device: iPhone, iOS 26.6 (23G71), TestFlight build

Sign in with Apple has never succeeded for this App ID — zero successful authorizations across an entire sysdiagnose containing 33 attempts. The sheet renders, Face ID succeeds, the user confirms name + email, then "Sign Up Not Completed"; the app receives ASAuthorizationError 1000.

akd shows the same -6003 as everyone else in this thread:

akd [siwa] Fetching developer team for client with ID: <bundle id> akd [siwa] Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 akd [siwa] No applications were found with the provided Client ID: <bundle id> akd [siwa] Application has no shared credentials akd [siwa] Using personal credential state - 2, error - AKAuthenticationError Code=-7074 akd Adding passwordlessToken: NO, and idmsDataToken: NO, to auth-params akd Performing SRP request with context -> HTTP 200 akd (second SRP request) -> HTTP 200 akd AppleIDAuthSupport: setError: 2:M2 missing (bad password) akd Invalid/missing value for key acname / ut / authType / primary email vetted: (null) akd SRP authentication with server failed! Domain=com.apple.AppleIDAuthSupport Code=2 akd [siwa] Error performing auth request: AKAuthenticationError Code=-7003 / -7034 App Authorization failed: AKAuthenticationError Code=-7034

Both SRP requests return HTTP 200, but the server proof (M2) is absent and every account field comes back null. The "bad password" wording is misleading — the account password is definitely correct (removing Activation Lock with the same password succeeded).

Ruled out on our side: entitlement com.apple.developer.applesignin = ["Default"] present in the signed binary's embedded provisioning profile; APPLE_ID_AUTH + PRIMARY_APP_CONSENT confirmed via the App Store Connect API; capability deleted and re-created, then rebuilt and re-signed; Team ID consistent across App ID, profile and binary; HSA2 account; Apple Account signed out of the device and back in; Screen Time restrictions all set to Allow; nonce SHA-256 verified against seven test vectors.

Requesting the same server-side registration repair that was applied to GW7XA5CX69 and FRL3DTJQ62.

Happy to provide a fresh sysdiagnose, the entitlements dump, or the binary on request.

Answer 3

mg_dev OP

1d

Same issue on our side. Team V96BHRSU6X, bundle com.moneytrain (App ID enabled for Sign in with Apple for several weeks, capability verified via App Store Connect API). Filed FB24518599.

On device (iPhone, iOS 26.6): the authorization sheet completes, then iOS shows "Sign Up Not Completed" and no credential is returned. Device logs show:

akd(AppleIDAuthSupport): "M2 missing (bad password)"
SRP authentication with server failed, AKAuthenticationServerError Code=-24000
serverProvidedData is nil, AUTH_ALERT_SIGN_UP_NOT_COMPLETED

Independent check: https://appleid.apple.com/auth/authorize?client_id=com.moneytrain still returns {"errorCode":"invalid_client"} as of day 5.

This exactly matches the AKSQLError -6003 "No applications were found with the provided Client ID" signature in this thread. Could the server-side Sign in with Apple registration for this App ID/team please be re-provisioned? Thank you.

Answer 4

markobarackov OP

1d

Adding a team to the list, and a controlled comparison from a single capture.

Team ID XJ5D4FX66P, bundle ID gg.wishtrap.game. Same fault as this thread: Apple's own sheet opens, names the app correctly, Face ID succeeds, and then Apple shows Sign-Up Not Completed. No authorization ever reaches our server.

The comparison

One idevicesyslog capture on 2026-08-31 held two Sign in with Apple sign ups 33 seconds apart, on the same iPhone 16 Pro (iOS 26.6.1) and the same personal Apple Account. The first was Temu (com.einnovation.temu), an App Store app from another team, and the second was ours. Both were genuine first-time sign ups for that account.

com.einnovation.temugg.wishtrap.game

`Attempting to authorize request`	yes	yes
`No applications were found with the provided Client ID`	yes	yes
`Encountered error while fetching developer team: AKSQLError Code=-6003`	yes	yes
`Application has no shared credentials`	yes	yes
`Checking for genesis event!`	yes	yes
SRP `stateClientNeg1` / `Neg2` / `Neg3`	all three	all three
final SRP response body	4373 bytes, `contents: <private>`	733 bytes, `contents: (null)`, `M2 missing`
outcome	`did complete with authorization <private> (error: (null))`	`AKAuthenticationError Code=-7003`

The pre-flight is identical line for line, the same daemon ran the same protocol, the account had just proved it can complete a sign up, and the only variable left is which App ID the sign up is for.

One correction to the thread's diagnosis

AKSQLError Code=-6003 and No applications were found with the provided Client ID are not the signature of this fault. Both appear in the attempt that succeeded, 33 seconds earlier, in the same capture. They are local cache misses during pre-flight. Invalid value for key authType: (null) is benign for the same reason, logged on the successful sign up as well. Of the four missing-key complaints, only acname, ut and primary email vetted belong to the failure. The discriminator is the SRP result and nothing before it:

akd(AppleIDAuthSupport)  stateClientNeg3: <private>
akd(AppleIDAuthSupport)  AppleIDAuthSupport: setError: 2:M2 missing (bad password)
akd                      Creating AKAuthenticationServerResponse with status: <private> contents: (null)
akd              <Error>  Invalid/missing value for key acname: (null)
akd                       ThirdPartyDeviceDataResponseHandler fromResponse serverProvidedData is nil
akd              <Error>  SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2
akd              <Error>  Error performing auth request: Error Domain=AKAuthenticationError Code=-7003
Runner(AuthKit)  <Error>  Authorization failed: Error Domain=AKAuthenticationError Code=-7003

(bad password) is the daemon's generic label for a response that carried no server proof. It is not a statement about any password: the same stored credential completed Temu's exchange 29 seconds earlier.

Worth noting for anyone matching symptoms: the error does reach the app here, as AKAuthenticationError Code=-7003. Reports in this thread of canceled (1001) with an empty userInfo are what the AuthenticationServices layer surfaces on top of it, so an implementation that treats a cancellation as "the user closed the sheet" will hide this fault completely.

Client side, verified rather than assumed

APPLE_ID_AUTH with APPLE_ID_AUTH_APP_CONSENT: PRIMARY_APP_CONSENT, read from the App Store Connect API on 2026-08-31, not from the portal UI
com.apple.developer.applesignin = [Default] in the signed binary via codesign -d --entitlements, and in embedded.mobileprovision via security cms -D
explicit primary App ID, no wildcard, no grouping, seedId XJ5D4FX66P on both
requested scopes empty and also tried with email and fullName, no difference
SHA-256 nonce, personal Apple Account with 2FA, developer mode on
reproduced on two Apple Accounts and two devices
the same account signs in successfully to other teams' apps on the same device
Google Sign-In through the same code path works end to end

The Apple Developer Program License Agreement was also accepted on 2026-08-30 after finding it pending, which changed nothing.

Request: server side re-provisioning of the Sign in with Apple registration for team XJ5D4FX66P. Happy to supply the filtered akd window covering both attempts, or a sysdiagnose taken with the Accounts/AuthKit logging profile, whichever is more useful.

Answer 5

darkshut OP

1d

Adding our case with the same confirmed server-side signature.

Feedback Assistant: FB24587131 App ID resource ID: GUYR4794T9 (The app name and bundle identifier are intentionally omitted from this public reply; full identifiers are included in the Feedback report.)

The native Sign in with Apple sheet appears normally and Face ID succeeds, but it then shows “Sign Up Not Completed.” No credential is returned, and no request reaches our backend.

The attached sysdiagnose confirms:

AKSQLError Code=-6003: “No applications were found with the provided Client ID”
AppleIDAuthSupport Code=2: “M2 missing”
AKAuthenticationServerError Code=-24000

APPLE_ID_AUTH with PRIMARY_APP_CONSENT, the signed binary entitlement, and the embedded provisioning profile have all been verified.

Could an Apple DTS engineer please inspect and re-provision the server-side Sign in with Apple registration for this App ID? Thank you.

Answer 6

claudiobasckeira OP

1d

Same issue here. Team S83WK69VDC, bundle ID com.overdrivesoftwares.zelu, Sign in with Apple capability enabled Aug 28. Sheet renders, Face ID succeeds, "Sign Up Not Completed", app receives ASAuthorizationError.canceled (1001) with empty userInfo, nothing reaches our backend. akd logs show AKSQLError -6003 / "No applications were found with the provided Client ID", and the server answers HTTP 200 with ec=-24000 "Invalid client." An older App ID on the same team (com.overdrive.agendaPro) works on the same device with the same Apple Account. Filed as FB24593873 with a sysdiagnose attached covering two reproductions. First public release blocked in review by this.

Answer 7

DianLee OP

15h

We are experiencing the same issue.

Team ID: 4FWTPL58XN Bundle ID: com.minimax.code Feedback Assistant ID: FB24606268

Face ID succeeds, followed by “Sign Up Not Completed”. The app receives AKAuthenticationError -7003 and ASAuthorizationError 1001.

The sysdiagnose and exact reproduction timestamp are attached to the feedback report.

Could you please investigate the server-side Sign in with Apple registration for our team?

Thank you.

Answer 8

guneyegeli OP

14h

Our team is affected as well.

Team ID: JPL3AZ6T39 Bundle ID: com.volkankiyici.formpano (Sign in with Apple enabled, PRIMARY_APP_CONSENT verified via App Store Connect API) App: Wealthen (App Store id 6797299929, live version 1.2)

Identical signature to this thread: the sheet authenticates successfully (Face ID OK), then shows "Sign-Up Not Completed"; ASAuthorizationController fails and no authorization request ever reaches our backend (server logs confirm all other app traffic arriving normally). Reproduced on a physical iPhone (iOS 26) with TestFlight build 1.3 (108); App Review hit the same on iPhone 17 Pro Max / iOS 26.6 and rejected our submission (2.1a). Sign-in with the identical code worked until Aug 31, 21:48 (UTC+3); failures began Sep 1, shortly after an automatic-signing provisioning refresh. Entitlements verified inside the distribution-signed binary and embedded profile; capability re-saved via ASC API with no effect, consistent with earlier reports here.

Could this team please be checked/repaired server-side like the earlier teams in this thread? Happy to provide sysdiagnose/akd logs and a Feedback ID if useful.

Answer 9

guneyegeli OP

14h

Filed as FB24607357 (Team ID JPL3AZ6T39).

Answer 10

Bulak OP

9h

Same issue here. Team ID: GJP7Y5Q68D

Sign in with Apple fails for every App ID in our team. The system sheet appears, the user picks an account, and authorization then fails with an empty ASAuthorizationError (1000/1001). No request ever reaches our backend.

akd logs match this thread exactly:

Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 AuthKit continuation-key-creation token is missing! No password, but CK is available. Will ask for ck-based auth. Failed to fetch device token. Proceeding with cert headers. Error: AKAuthenticationError Code=-7027 AppleIDAuthSupport: setError: 2:M2 missing (bad password) SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2

Both HTTPS requests to the Apple ID server return status 200, so this is not a networking problem.

Ruled out on our side:

Minimal test case: a brand-new App ID (com.rm.siwaprobe, created 2026-09-01) with Sign in with Apple enabled as a primary App ID, and a single-screen SwiftUI app containing nothing but one SignInWithAppleButton. Fails identically.
Entitlement verified in the signed binary (codesign -d --entitlements) and in the decoded embedded.mobileprovision: com.apple.developer.applesignin = ["Default"]
Capability removed and re-added via App Store Connect API — no change.
Profiles regenerated, clean build, fresh install on physical devices.
Two different iPhones with two different personal Apple IDs.
Same Apple ID signs in successfully with apps from other teams on the same device.
iCloud and Media & Purchases set to the same Apple ID — no change.
Screen Time restrictions off, personal (not managed) accounts.
All agreements accepted, membership active.

Impact: our production app (com.rm.fitnessassistant) has zero successful Sign in with Apple registrations since launch, and App Review rejected our build under Guideline 2.1(a) on 2026-08-12 for exactly this failure — the reviewer hit the same wall.

Feedback: FB<номер>

Could a server-side fix be applied to team GJP7Y5Q68D as was done for other teams in this thread?