Sign in with Apple — ASAuthorizationError 1001 immediately after sheet, same AKSQLError -6003 pattern as other threads Adding our case to this thread, matches the pattern already confirmed for other teams here (e.g. GW7XA5CX69, FRL3DTJQ62). App / Team info: Bundle ID: de.schonwiedernudelnapp.iosApp Team ID: 7JX3TW8R6B Sign In with Apple capability: enabled on the App ID (APPLE_ID_AUTH), configured as Primary (APPLE_ID_AUTH_APP_CONSENT → PRIMARY_APP_CONSENT), confirmed via the App Store Connect API. Distribution provisioning profile carries com.apple.developer.applesignin = ["Default"] and aps-environment = production (verified via codesign -d --entitlements). Entitlements file (iosApp.entitlements) correctly embedded in the signed build. Symptom: Native ASAuthorizationController flow (Sign In with Apple button in our app). The system sheet appears correctly, user authenticates with Face ID successfully. Sheet then dismisses with "Sign Up Not Completed", and our app receives: com.apple.AuthenticationServices.AuthorizationError error 1001 (ASAuthorizationError.canceled) userInfo is empty, no NSUnderlyingErrorKey present — indicating the failure happens before any request reaches our backend / Apple's auth servers respond with a real error. Zero requests ever reach our own server's token-verification endpoint. What we've ruled out: Not a retention/deallocation bug — tried two different ASAuthorizationController retention strategies (captured context, then a static holder), byte-identical failure both times. Not a device/Apple ID problem — reproduced independently on two different physical devices, with two different Apple ID accounts, identical failure both times, both with real (non-Sandbox) Apple IDs with 2FA enabled. Not a stale profile/entitlement issue — only one valid distribution provisioning profile exists for this Team/App ID, verified server-side and on the build machine, entitlements confirmed correct on the signed binary. Not a code signing / capability config issue — App ID capability and consent settings verified correct via the ASC API. Tried regenerating the provisioning profile after re-toggling the capability — no change. This looks identical to the AKSQLError Code=-6003 / "No applications were found with the provided Client ID" / GSA Invalid client (ec=-24000) failure mode described earlier in this thread — i.e. our Team/Bundle ID's registration in Apple's authorization server appears broken, while everything on our (client) side checks out. Request: Could someone from Apple DTS please check our Team ID (7JX3TW8R6B) / Bundle ID (de.schonwiedernudelnapp.iosApp) registration server-side, the same way it was fixed for the teams above? Happy to file a Feedback Assistant report with a sysdiagnose/akd log if that's still the preferred path — let us know the best next step. Thanks!