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 33

Boosts 2

Views 7.7k

Participants 27

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.

AgentSciX OP

I'm having the same issue. I even coded a test app specifically with no other features because I've had the issue a couple times in a row. Same issue occurred with minimal code. Appears to be a token issue (apple not issuing sign-in token from server), specifically on Apples side.

AgentSciX OP

I should add, this appears to only be occurring with new apps created around the time the first post in this thread was posted.

khor6281 OP

Update with Accounts/AuthKit sysdiagnose evidence from TestFlight 1.0.0 (5): LAYR now has the exact failure signature reported by other affected teams. On 2026-08-22 at 01:49:49 and 01:57:20 +0800, akd derived the correct identifiers from the signed app: clientID: cc.brue.layr  teamID: 5RCJW4N328  It then logged: Fetching developer team for client with ID: cc.brue.layr AKSQLError Code=-6003 No applications were found with the provided Client ID: cc.brue.layr The Apple network request itself completed successfully with HTTP 200, but Apple’s AuthKit response was: ec = -24000  em = Invalid client.  ptxid ab797933-b4db-443c-ba9e-9667d10db920  ptxid 43bf2953-2933-4cef-b3ff-3131131f8bc2  For the second capture, biometric authentication completed successfully immediately before this response. AuthKit then returned authorization (null); no Apple credential or identity token reached LAYR. We also removed and re-added the Sign in with Apple capability, deleted the old distribution profile, generated a fresh App Store profile, rebuilt, and uploaded build 5. The signed binary still contains application-identifier = 5RCJW4N328.cc.brue.layr and com.apple.developer.applesignin = [Default]. The fresh build fails identically. This rules out the app backend, JWT/client-secret generation, and stale provisioning as the failure point. @Paris X Pinkney, could Apple please repair/re-provision the server-side Sign in with Apple registration lookup for Team 5RCJW4N328, App ID 3F7B7MNFHY, bundle cc.brue.layr? A fresh sysdiagnose is available.

tcndtht OP

Same issue for our team — and the flow has never once succeeded, starting from our very first attempt.

Team ID: AJ36Q485L4 (Individual, enrolled August 2026). Client ID / bundle: com.tcndtht.outpawtient (the team's only App ID, APPLE_ID_AUTH enabled as primary App ID).

The signature matches this thread exactly: the sheet renders fully, Face ID succeeds, then "Sign-Up not completed"; zero requests reach our backend. Two different personal Apple Accounts (2FA) on two different iPhones; Sign in with Apple works in other apps on the same devices at the same minute. Entitlement verified in the signed binary and embedded profile; agreements accepted; removing and re-adding the capability on 23 Aug 2026 (profile reissued) changed nothing. The public authorize endpoint returns a bare 403 Forbidden for our client_id — identical to a nonexistent client — while a known-good client id from the same network renders the normal sign-in page.

Filed as FB24490686. We would appreciate the same server-side registration fix being applied to our team.

techeyenet OP

We are hitting the same issue. Team ID 7XWPRV3856, App IDs com.fixli.user.me and com.fixli.me, both registered 2026-08-18. Native sheet authenticates with Face ID, then "Sign Up Not Completed" / ASAuthorizationError.canceled (1001) with empty userInfo, on TestFlight builds on physical devices.

Entitlement com.apple.developer.applesignin verified present in the signed binaries and embedded provisioning profiles; PRIMARY_APP_CONSENT confirmed via the App Store Connect API; capability re-registered and both App Store profiles regenerated on 2026-08-25 with no change. Fails identically with Share My Email and Hide My Email.

Filed as FB24504006 (screen recording attached; sysdiagnose with the Accounts/AuthKit profile to follow — the affected devices are with remote testers).

Requesting the same server-side registration repair applied to the other teams in this thread.

junseongkim OP

Same issue, same signature — Team ID F3THR995U3, bundle ID com.todaywe.app (App Store Connect app 6801750747), App ID created 2026-08-15.

Native sheet renders, user authenticates and gets through the name / Hide My Email step, then "Sign Up Not Completed"; ASAuthorizationError 1000/1001 with empty userInfo; zero requests reach our backend. Reproduced by App Review on iOS 26.6 / 26.6.1 / iPadOS 26.6 across three builds; rejected four times under 2.1(a). Capability (APPLE_ID_AUTH, PRIMARY_APP_CONSENT) and the applesignin entitlement in both the embedded profile and the code signature of the submitted binary are verified; all agreements active; removing and re-adding the capability did not help.

Feedback ID: FB24504521. Requesting the same server-side team registration fix that resolved GW7XA5CX69 and FRL3DTJQ62. Thank you.

vypercat OP

Same issue, same signature - Team ID 8U9TDRFRQL, bundle ID org.bldsf.community (App Store Connect app 6804963217), Sign in with Apple capability enabled on the App ID 2026-08-25.

Native sheet renders, Face ID authenticates, then "Sign Up Not Completed"; zero requests reach our backend (our /auth/apple endpoint logs nothing, and an unrelated empty POST to it still answers its normal 401, so the route is up and reachable).

akd on device, 2026-08-25 20:45:57 -0700, TestFlight build 1.0.0 (6), iPhone 14 Pro on iOS 26.6:

akd Client has default access level in SiwA entitlement akd Fetching developer team for client with ID: <private> akd Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 akd No applications were found with the provided Client ID: <private>

Note the entitlement is read correctly on-device immediately before the team lookup fails.

Verified on our side: com.apple.developer.applesignin = [Default] is present both in the code signature of the submitted binary (codesign -d --entitlements) and in the embedded provisioning profile; the identifier is configured as "Enable as a primary App ID", not grouped under another primary and not a wildcard; the bundle contains no app extensions that could be missing the entitlement; the bundle ID matches the aud we validate.

This App ID is new - the capability was enabled the day before the failure - which matches the pattern others have reported here.

Requesting the same server-side team registration fix that resolved GW7XA5CX69 and FRL3DTJQ62. Happy to supply a sysdiagnose or a GSA ptxid if that helps locate the server logs. Thank you.

HipicoNica OP

Adding another affected team: T84UX6J624 (Cilantro & Co., LLC), App ID com.cilantroco.hipiconica.

Same signature as the rest of the thread. The system sheet renders, the user authenticates with Face ID, the sheet then shows "Sign Up Not Completed", and no credential is returned — ASAuthorizationError .canceled (1001) with an empty userInfo. Zero requests reach our backend; our server logs show no failed authentication attempts at all. Reproduced on two physical devices with two different standard (non-managed) Apple Accounts.

Ruled out on the client side:

APPLE_ID_AUTH with PRIMARY_APP_CONSENT on the App ID, read back from the App Store Connect API. Explicit primary App ID; no wildcard and no grouped identifiers.
com.apple.developer.applesignin = ["Default"] verified inside the signed binary with codesign -d --entitlements, not just in the portal.
We diffed a build from 20 August that authenticated successfully against a build from 25 August that fails: identical embedded provisioning profile (same UUID, same creation date), identical signing certificate, identical entitlements, identical linked frameworks. The only delta between them is unrelated JavaScript.
Agreements active, membership in good standing; Apple System Status shows Sign in with Apple as available.

So a binary that signed in successfully on 23 August now fails, with nothing changed in our Sign in with Apple configuration or signing chain.

A device-free reproduction, with controls. Following DanCue's note about the public authorize endpoint, this can be checked with a plain HTTP request — no device, no logging profile, no build. Captured 2026-08-26 06:49 UTC against appleid.apple.com/auth/authorize, varying only client_id and holding every other parameter fixed:

com.cilantroco.hipiconica (ours) — invalid_client, "Invalid client."
host.exp.Exponent — invalid_request, "Invalid client id or web redirect url."
com.burbn.instagram — invalid_request, "Invalid client id or web redirect url."
com.cilantroco.definitely-not-real-abc123 (never registered) — invalid_client, "Invalid client."

Known-good Sign in with Apple clients get past client validation and are rejected on the redirect URL instead. Our registered App ID is rejected at the same stage, with the same wording, as a bundle identifier that has never existed — which is the em = "Invalid client." that Ozvern, moty66 and nazacheres captured in the GSA response on device, reachable without one. Offering it in case it is a useful triage shortcut for others here; DanCue reported this flipping the moment their team was re-provisioned.

This is also blocking us in App Review: our 1.0.10 submission was rejected under Guideline 2.1(a), "An error appeared when attempting to log in with Apple", because the reviewer hit this same failure. We have had to disable Sign in with Apple in production so that users can sign in at all — and Google with it, per 4.8.

Developer Support case: 20000147837597.

@Paris X Pinkney — could the same server-side team registration fix applied to GW7XA5CX69 and FRL3DTJQ62 be applied to T84UX6J624? Happy to verify and confirm immediately, and to attach a sysdiagnose with the Accounts/AuthKit profile if that would help.