Hello, I just want to inform that i will be closing FB24150280 since it is now working (with no changes on my side) Thank you

Hello, @Paris X Pinkney — still failing for team W2V4HBXWLJ as of 13 August 2026. Device logs now captured; FB24150280 updated with the sysdiagnose. Bundle ID fr.animapulse, TestFlight build 1.0.0 (24), iPhone on iOS 26.6 (23G71). Six attempts between 19:50 and 20:05 CEST, all identical. With the Accounts/AuthKit profile installed, the GSA response is explicit — your server answers HTTP 200 with no server proof and says why: AppleIDAuthSupport: setError: 2:M2 missing (bad password) ThirdPartyDeviceDataResponseHandler fromResponse serverProvidedData is nil SRP authentication with server failed! Status={ ec = "-24000"; em = "Invalid client."; hsc = 200; ptxid = "7908aa53-b737-4725-a791-8fdbabb0c960"; } → AKAuthenticationError -7003, UserInfo={AKClientBundleID=fr.animapulse} → sheet shows "Sign Up Not Completed", app receives 1001 The six attempts carry six distinct ptxid values, all with ec=-24000 / em="Invalid client."; they are in the Feedback if that helps locate them server-side. A control falls out of the same log: five seconds before the first failure, the same akd process on the same Apple Account completed two GSA exchanges with ec=0. Reachability, credentials and SRP are fine — only the exchange carrying our client_id is rejected. Consistent with that, the public appleid.apple.com/auth/authorize endpoint returns invalid_client for fr.animapulse — the same wording the device log receives. One note that may help triage, offered tentatively: the AKSQLError -6003 line several of us have quoted comes, in our capture, from a query against the on-device database /var/mobile/Library/Application Support/com.apple.akd/authorization.db, and the flow continues past it to display the sheet. We suspect it is a first-authorization cache miss rather than the cause, and that the decisive event is the -24000 / "Invalid client." GSA response. Configuration re-verified today via the App Store Connect API: APPLE_ID_AUTH / PRIMARY_APP_CONSENT on fr.animapulse and on our throwaway App ID fr.animapulse.essai, both failing identically; signed binary and embedded profile both carry com.apple.developer.applesignin = ["Default"]. Could the same server-side re-provisioning applied to GW7XA5CX69 and FRL3DTJQ62 be applied to W2V4HBXWLJ? Happy to verify immediately.

Same failure mode here, on a different team — adding a data point in case it helps narrow down the server side. Team W2V4HBXWLJ · App ID fr.animapulse (Apple ID 6794420038), created 24 July 2026, never released (still in Prepare for Submission). Symptom — identical to the original report. The system sheet appears, authentication succeeds (Face ID accepted), the sheet then displays "Sign Up Not Completed", and ASAuthorizationController reports: ASAuthorizationError.canceled (rawValue = 1001) com.apple.AuthenticationServices.AuthorizationError "The operation couldn't be completed." userInfo: <empty> The user never cancelled. Zero Sign in with Apple requests reach our identity provider, so the authorization is abandoned before any token exchange. Google sign-in, which goes through the same native id-token path in the same app, works. Client configuration verified — the App ID has the Sign In with Apple capability enabled and is configured as a primary App ID (PRIMARY_APP_CONSENT). The signed binary carries com.apple.developer.applesignin = [Default], the embedded provisioning profile grants that same entitlement, and the distribution profile is active. Controlled experiment (3 August 2026) — to isolate the variable, we created a throwaway App ID fr.animapulse.essai that same day (default configuration, Sign In with Apple as a primary App ID), shipped the same binary under it through internal TestFlight, and tested it on the same device and Apple Account while watching our identity provider's logs live. Result: identical failure — sheet completes authentication, then "Sign Up Not Completed", 1001, zero requests server-side. On that same device and Apple Account, third-party App Store apps using Sign in with Apple work normally. Two App IDs of our team — one of them an hour old — fail where every other team's apps succeed. Feedback Assistant: FB24150280