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