Sign in with Apple fails on ALL apps under our developer team with "Sign Up Not Completed" / "No se ha podido completar el registro."

Question

Created 1w

Replies 2

Boosts 0

Participants 1

Team ID: 2357A78TMR Affected App ID: me.manulorenzo.crossfittracker (App Store Connect app 6760609857) Reproduces identically across every app under this team, on a real device, personal (non-managed) Apple ID with 2FA enabled, persisting for multiple days across device reboots.

Symptom matches the documented pattern in developer.apple.com/forums/thread/837986 and /thread/789222: native SIWA sheet renders, biometric/password succeeds, then "Sign Up Not Completed" — no credential ever returned. This matches Apple's own described root cause of an App ID/team never being fully provisioned server-side for Sign in with Apple (AKSQLError -6003 / GSA "Invalid client" / ASAuthorizationError 1001 with empty userInfo).

Client-side configuration has been independently verified correct: provisioning profile carries com.apple.developer.applesignin entitlement, App ID capability APPLE_ID_AUTH is configured with PRIMARY_APP_CONSENT, Firebase's apple.com provider has the correct bundle ID registered. Requesting the server-side team registration fix described as the resolution in the linked threads.

Answer 1

noloman OP

1w

Update: captured a live device log during reproduction (Console.app, connected via cable), which confirms this exactly rather than just matching the pattern:

error akd Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 default akd No applications were found with the provided Client ID: <private> default akd Client has default access level in SiwA entitlement ... (same AKSQLError -6003 / "No applications were found" repeats a second time later in the same auth attempt) ... error akd Error performing auth request: Error Domain=AKAuthenticationError Code=-7003 error Crossfit Tracker Authorization failed: Error Domain=AKAuthenticationError Code=-7003 UserInfo={AKClientBundleID=<private>}

Client has default access level in SiwA entitlement confirms the entitlement itself is being read correctly by the OS — so this is specifically the team/App ID lookup failing on your side (AKSQLError -6003, "no applications found"), not anything in our provisioning or entitlements. AKAuthenticationError -7003 is the real underlying failure; ASAuthorizationController collapses it into the generic .canceled (1001) with empty userInfo by the time it reaches our app, which is why it initially looked like a plain cancellation on our end.

This is the same AKSQLError -6003 signature described as resolved by a server-side team registration fix in the threads I linked above. Happy to provide a full sysdiagnose if that helps move this along.

Answer 2

noloman OP

1w

Update: captured a live device log during reproduction (Console.app, connected via cable), which confirms this exactly rather than just matching the pattern:

error akd Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 default akd No applications were found with the provided Client ID: <private> default akd Client has default access level in SiwA entitlement ... (same AKSQLError -6003 / "No applications were found" repeats a second time later in the same auth attempt) ... error akd Error performing auth request: Error Domain=AKAuthenticationError Code=-7003 error Crossfit Tracker Authorization failed: Error Domain=AKAuthenticationError Code=-7003 UserInfo={AKClientBundleID=<private>}

Client has default access level in SiwA entitlement confirms the entitlement itself is being read correctly by the OS — so this is specifically the team/App ID lookup failing (AKSQLError -6003, "no applications found"), not anything in our provisioning or entitlements. AKAuthenticationError -7003 is the real underlying failure; ASAuthorizationController collapses it into the generic .canceled (1001) with empty userInfo by the time it reaches the app, which is why it initially looked like a plain cancellation.

I can also reproduce the identical failure — same AKSQLError -6003 signature in Console — in a second, unrelated app under the same team: com.nulltwenty.Remoti (App Store Connect app 1567902235, "AnywhereRoles Remote Jobs"). Both apps share Team ID 2357A78TMR. This confirms the registration failure is at the team level in Apple's backend, not specific to a single App ID, matching exactly how the resolution was applied in the threads I linked above (fixed per Team ID, not per app).

This is the same AKSQLError -6003 signature described as resolved by a server-side team registration fix in those threads. Happy to provide a full sysdiagnose if that helps move this along.