@Paris X Pinkney — a status request, and a structural problem with the escalation path that I think Apple should be aware of. WHERE THIS THREAD STANDS Counting from the posts above: two teams have been repaired — GW7XA5CX69 on 31 July and FRL3DTJQ62 on 12 August. Since 12 August, three weeks ago, not one further resolution has been reported here. In that same window at least fifteen additional teams have posted the same signature, four of them in the last twelve hours. The last reply in this thread from anyone at Apple was in July. Every one of those reports carries the same evidence: the entitlement verified inside the signed binary and the embedded provisioning profile, APPLE_ID_AUTH / PRIMARY_APP_CONSENT read back from the App Store Connect API, and a device log showing the GSA exchange returning HTTP 200 with no server proof and ec=-24000 "Invalid client." The two teams that were fixed were fixed with no client-side change at all — their own words. So the client side is not where this lives, and there is nothing left for any of us to try. This is also not new, and the precedent is the part I would ask you to weigh. On 18 June 2025 the same failure hit, and Apple handled it very differently. You opened thread 790827 as an official notice, named the cause - "a configuration issue impacted some developer accounts that created new app or Services ID configurations" - listed the exact two symptoms we are all reporting now, "invalid_client" and "Sign Up Not Completed", told developers what to do, and posted "On Monday, June 23, 2025, this issue was resolved." Five days, start to finish, with a notice up the whole time. Thread 790821 did the same for the 12 June occurrence. The failure we are reporting is that failure. Same symptoms, same wording in the logs, same class of account - newly created App IDs. It began around 15 July 2026. It is now week eight, with no notice, no acknowledgement, and two teams repaired out of more than twenty. I am not asking why 2025 was faster. I am asking that this be recognised as the same incident it was recognised as then. THE ESCALATION PATH IS A CLOSED LOOP This is the part I would ask someone at Apple to look at, separately from the outage itself. I filed a code-level support request. The form requires a focused sample Xcode project that reproduces the issue. There is no such project to build: the failure is in Apple's server-side team registration, and Apple's own sample code reproduces it (learnbybits reported exactly that above). Answering "no sample project" produces this: "If you're unable to provide a sample Xcode project, or unsure how to proceed, please ask your question in the Apple Developer Forums." So the form directs us here. This thread has had no Apple reply since July. Feedback reports sit open — mine shows "similar recent reports: more than 10", so the duplicate detection plainly recognises the pattern — with no response. Every documented route back to Apple leads to a queue that is not moving. WHAT THIS COSTS, CONCRETELY The failure does not merely block a feature. It makes App Review unpassable in both directions at once: Guideline 2.1(a): reviewers reproduce the failure on their own devices and reject the build as broken. At least eight teams in this thread have been rejected on exactly this ground, mine included. Guideline 4.8: because Sign in with Apple is the only login service that satisfies the guideline for most of us, and it does not work, we are told to remove Google, Kakao and every other third-party login instead. Read together: Apple's server-side outage makes Apple's own guideline impossible to satisfy, and the developer is rejected for it. Some teams in this thread have taken the only exit available and shipped email-only, discarding working social login to escape a guideline they cannot comply with because of a fault on Apple's side. That is not a reasonable outcome for anyone. Our own case: team FP43Y46F5X, two unrelated apps (com.leverage.sayeon, com.leverage.dreamfund), both blocked. One rejected under 2.1(a) with "We were unable to complete signing up with Apple due to an error", the other under 4.8. FB24618135, filed 2 September with the akd log and sysdiagnose. Detail in my post above. WHAT I AM ASKING FOR Re-provision the server-side Sign in with Apple registrations for the teams still waiting in this thread. It is one operation per team, and it has already been performed twice. If that cannot be done team-by-team at this volume, say so, and treat it as the incident it is — with a status page entry, so that developers stop spending days re-verifying entitlements that were never the problem. Until it is fixed, instruct App Review not to reject builds under 2.1(a) or 4.8 for a Sign in with Apple failure that Apple's own logs attribute to -24000 "Invalid client" on Apple's servers. A Feedback ID with a sysdiagnose should be enough to establish that. The third item costs Apple nothing and unblocks every team in this thread today. We are not asking to bypass review; we are asking not to be failed for a defect none of us can reach. Happy to provide a fresh sysdiagnose, the akd window, the entitlements dump, or the binary — anything that helps.

Same failure on team FP43Y46F5X — adding our data in case it helps batch this with the earlier cases. Two unrelated apps in the team, different bundle IDs, separate codebases, different backend stacks, both failing identically on the same device: com.leverage.sayeon (ASC 6804366500) com.leverage.dreamfund (ASC 6778789855) The native sheet renders the account-creation step, the user authenticates with Face ID, and then the sheet reports "Sign Up Not Completed". No credential reaches the delegate, and our backends record zero inbound requests (verified with a probe request in the same window that was logged immediately, so the log pipeline was working). Device log (iPhone 17 Pro Max, iOS 26.6.1, from a sysdiagnose taken during a failing attempt): akd: [authkit:siwa] Fetching developer team for client with ID: akd: [authkit:siwa] No applications were found with the provided Client ID: AuthKitUIService: [siwa] Finished biometric authentication successfully. AuthKitUIService: [core] AKRemoteViewController did complete with authorization (null) (error: Domain=com.apple.AppleIDAuthSupport Code=2, NSUnderlyingError = Domain=AKAuthenticationServerError Code=-24000) akd: [authkit:siwa] Error performing auth request: AKAuthenticationError Code=-7003 A second attempt seconds later repeats identically and ends with Code=-7034. Both hit -24000. The client error surfaces as ERR_REQUEST_UNKNOWN (ASAuthorizationError.unknown) via expo-apple-authentication. Same on the client side as the other teams here, all verified: Sign in with Apple enabled, "Enable as a primary App ID" (ASC API reports APPLE_ID_AUTH / PRIMARY_APP_CONSENT) com.apple.developer.applesignin = ["Default"] in both the signed binary and the embedded provisioning profile Profiles regenerated after enabling the capability; the invalidated older ones are not used (deleted for one app, leaving exactly one profile) No wildcard App IDs and no Services IDs in the team; membership and agreements active Fails with both "Share My Email" and "Hide My Email"; persists after removing the app from Settings > Apple Account > Sign in with Apple and after reinstalling from TestFlight Sign in with Apple works normally on the same device for other developers' apps Both App IDs are recent: com.leverage.sayeon was registered in August 2026, and Sign in with Apple was enabled on com.leverage.dreamfund on 2026-09-01. Filed as FB24618135 with the akd log and the sysdiagnose attached. Both apps are blocked from release — one was rejected under 2.1(a) with "We were unable to complete signing up with Apple due to an error", the other under 4.8. Requesting the same server-side re-provisioning that resolved GW7XA5CX69 and FRL3DTJQ62. Happy to provide anything else that would help.