Sign in with Apple: "Sign Up Not Completed" for every App ID in our team — framework returns canceled (1001) with empty userInfo

Same issue for our team since at least 2026-08-24. Team ID R58645RRYR, client ID com.amenscroll.amenScroll (primary App ID, native app, no Services ID, no grouped App IDs). The sheet renders, the user approves, then "Sign-Up Not Completed". akd shows AKSQLError -6003, "No applications were found with the provided Client ID", GrandSlam postdata HTTP 401, and SRP fails with "M2 missing (bad password)" despite a correct password. Entitlements verified in the signed binary and embedded provisioning profile; APPLE_ID_AUTH with PRIMARY_APP_CONSENT confirmed via the App Store Connect API; deleting and re-creating the capability had no effect. This also cost us an App Review rejection (2.1a, the button reads as unresponsive). Filed as FB24582063. Requesting the same server-side registration repair applied to the other teams in this thread.

Same signature here — adding our team in case it helps Apple batch the server-side fix.

Team ID: 2L9BRR2X97 Bundle ID (primary App ID): com.niman.watagumo Feedback: FB24584055 Device: iPhone, iOS 26.6 (23G71), TestFlight build

Sign in with Apple has never succeeded for this App ID — zero successful authorizations across an entire sysdiagnose containing 33 attempts. The sheet renders, Face ID succeeds, the user confirms name + email, then "Sign Up Not Completed"; the app receives ASAuthorizationError 1000.

akd shows the same -6003 as everyone else in this thread:

akd [siwa] Fetching developer team for client with ID: <bundle id> akd [siwa] Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 akd [siwa] No applications were found with the provided Client ID: <bundle id> akd [siwa] Application has no shared credentials akd [siwa] Using personal credential state - 2, error - AKAuthenticationError Code=-7074 akd Adding passwordlessToken: NO, and idmsDataToken: NO, to auth-params akd Performing SRP request with context -> HTTP 200 akd (second SRP request) -> HTTP 200 akd AppleIDAuthSupport: setError: 2:M2 missing (bad password) akd Invalid/missing value for key acname / ut / authType / primary email vetted: (null) akd SRP authentication with server failed! Domain=com.apple.AppleIDAuthSupport Code=2 akd [siwa] Error performing auth request: AKAuthenticationError Code=-7003 / -7034 App Authorization failed: AKAuthenticationError Code=-7034

Both SRP requests return HTTP 200, but the server proof (M2) is absent and every account field comes back null. The "bad password" wording is misleading — the account password is definitely correct (removing Activation Lock with the same password succeeded).

Ruled out on our side: entitlement com.apple.developer.applesignin = ["Default"] present in the signed binary's embedded provisioning profile; APPLE_ID_AUTH + PRIMARY_APP_CONSENT confirmed via the App Store Connect API; capability deleted and re-created, then rebuilt and re-signed; Team ID consistent across App ID, profile and binary; HSA2 account; Apple Account signed out of the device and back in; Screen Time restrictions all set to Allow; nonce SHA-256 verified against seven test vectors.

Requesting the same server-side registration repair that was applied to GW7XA5CX69 and FRL3DTJQ62.

Happy to provide a fresh sysdiagnose, the entitlements dump, or the binary on request.

Same issue on our side. Team V96BHRSU6X, bundle com.moneytrain (App ID enabled for Sign in with Apple for several weeks, capability verified via App Store Connect API). Filed FB24518599.

On device (iPhone, iOS 26.6): the authorization sheet completes, then iOS shows "Sign Up Not Completed" and no credential is returned. Device logs show:

• akd(AppleIDAuthSupport): "M2 missing (bad password)"
• SRP authentication with server failed, AKAuthenticationServerError Code=-24000
• serverProvidedData is nil, AUTH_ALERT_SIGN_UP_NOT_COMPLETED

Independent check: https://appleid.apple.com/auth/authorize?client_id=com.moneytrain still returns {"errorCode":"invalid_client"} as of day 5.

This exactly matches the AKSQLError -6003 "No applications were found with the provided Client ID" signature in this thread. Could the server-side Sign in with Apple registration for this App ID/team please be re-provisioned? Thank you.

Adding a team to the list, and a controlled comparison from a single capture.

Team ID XJ5D4FX66P, bundle ID gg.wishtrap.game. Same fault as this thread: Apple's own sheet opens, names the app correctly, Face ID succeeds, and then Apple shows Sign-Up Not Completed. No authorization ever reaches our server.

The comparison

One idevicesyslog capture on 2026-08-31 held two Sign in with Apple sign ups 33 seconds apart, on the same iPhone 16 Pro (iOS 26.6.1) and the same personal Apple Account. The first was Temu (com.einnovation.temu), an App Store app from another team, and the second was ours. Both were genuine first-time sign ups for that account.

The pre-flight is identical line for line, the same daemon ran the same protocol, the account had just proved it can complete a sign up, and the only variable left is which App ID the sign up is for.

One correction to the thread's diagnosis

AKSQLError Code=-6003 and No applications were found with the provided Client ID are not the signature of this fault. Both appear in the attempt that succeeded, 33 seconds earlier, in the same capture. They are local cache misses during pre-flight. Invalid value for key authType: (null) is benign for the same reason, logged on the successful sign up as well. Of the four missing-key complaints, only acname, ut and primary email vetted belong to the failure. The discriminator is the SRP result and nothing before it:

akd(AppleIDAuthSupport)  stateClientNeg3: <private>
akd(AppleIDAuthSupport)  AppleIDAuthSupport: setError: 2:M2 missing (bad password)
akd                      Creating AKAuthenticationServerResponse with status: <private> contents: (null)
akd              <Error>  Invalid/missing value for key acname: (null)
akd                       ThirdPartyDeviceDataResponseHandler fromResponse serverProvidedData is nil
akd              <Error>  SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2
akd              <Error>  Error performing auth request: Error Domain=AKAuthenticationError Code=-7003
Runner(AuthKit)  <Error>  Authorization failed: Error Domain=AKAuthenticationError Code=-7003

(bad password) is the daemon's generic label for a response that carried no server proof. It is not a statement about any password: the same stored credential completed Temu's exchange 29 seconds earlier.

Worth noting for anyone matching symptoms: the error does reach the app here, as AKAuthenticationError Code=-7003. Reports in this thread of canceled (1001) with an empty userInfo are what the AuthenticationServices layer surfaces on top of it, so an implementation that treats a cancellation as "the user closed the sheet" will hide this fault completely.

Client side, verified rather than assumed

• APPLE_ID_AUTH with APPLE_ID_AUTH_APP_CONSENT: PRIMARY_APP_CONSENT, read from the App Store Connect API on 2026-08-31, not from the portal UI
• com.apple.developer.applesignin = [Default] in the signed binary via codesign -d --entitlements, and in embedded.mobileprovision via security cms -D
• explicit primary App ID, no wildcard, no grouping, seedId XJ5D4FX66P on both
• requested scopes empty and also tried with email and fullName, no difference
• SHA-256 nonce, personal Apple Account with 2FA, developer mode on
• reproduced on two Apple Accounts and two devices
• the same account signs in successfully to other teams' apps on the same device
• Google Sign-In through the same code path works end to end

The Apple Developer Program License Agreement was also accepted on 2026-08-30 after finding it pending, which changed nothing.

Request: server side re-provisioning of the Sign in with Apple registration for team XJ5D4FX66P. Happy to supply the filtered akd window covering both attempts, or a sysdiagnose taken with the Accounts/AuthKit logging profile, whichever is more useful.

Adding our case with the same confirmed server-side signature.

Feedback Assistant: FB24587131 App ID resource ID: GUYR4794T9 (The app name and bundle identifier are intentionally omitted from this public reply; full identifiers are included in the Feedback report.)

The native Sign in with Apple sheet appears normally and Face ID succeeds, but it then shows “Sign Up Not Completed.” No credential is returned, and no request reaches our backend.

The attached sysdiagnose confirms:

• AKSQLError Code=-6003: “No applications were found with the provided Client ID”
• AppleIDAuthSupport Code=2: “M2 missing”
• AKAuthenticationServerError Code=-24000

APPLE_ID_AUTH with PRIMARY_APP_CONSENT, the signed binary entitlement, and the embedded provisioning profile have all been verified.

Could an Apple DTS engineer please inspect and re-provision the server-side Sign in with Apple registration for this App ID? Thank you.

Same issue here. Team S83WK69VDC, bundle ID com.overdrivesoftwares.zelu, Sign in with Apple capability enabled Aug 28. Sheet renders, Face ID succeeds, "Sign Up Not Completed", app receives ASAuthorizationError.canceled (1001) with empty userInfo, nothing reaches our backend. akd logs show AKSQLError -6003 / "No applications were found with the provided Client ID", and the server answers HTTP 200 with ec=-24000 "Invalid client." An older App ID on the same team (com.overdrive.agendaPro) works on the same device with the same Apple Account. Filed as FB24593873 with a sysdiagnose attached covering two reproductions. First public release blocked in review by this.

We are experiencing the same issue.

Team ID: 4FWTPL58XN Bundle ID: com.minimax.code Feedback Assistant ID: FB24606268

Face ID succeeds, followed by “Sign Up Not Completed”. The app receives AKAuthenticationError -7003 and ASAuthorizationError 1001.

The sysdiagnose and exact reproduction timestamp are attached to the feedback report.

Could you please investigate the server-side Sign in with Apple registration for our team?

Thank you.

Our team is affected as well.

Team ID: JPL3AZ6T39 Bundle ID: com.volkankiyici.formpano (Sign in with Apple enabled, PRIMARY_APP_CONSENT verified via App Store Connect API) App: Wealthen (App Store id 6797299929, live version 1.2)

Identical signature to this thread: the sheet authenticates successfully (Face ID OK), then shows "Sign-Up Not Completed"; ASAuthorizationController fails and no authorization request ever reaches our backend (server logs confirm all other app traffic arriving normally). Reproduced on a physical iPhone (iOS 26) with TestFlight build 1.3 (108); App Review hit the same on iPhone 17 Pro Max / iOS 26.6 and rejected our submission (2.1a). Sign-in with the identical code worked until Aug 31, 21:48 (UTC+3); failures began Sep 1, shortly after an automatic-signing provisioning refresh. Entitlements verified inside the distribution-signed binary and embedded profile; capability re-saved via ASC API with no effect, consistent with earlier reports here.

Could this team please be checked/repaired server-side like the earlier teams in this thread? Happy to provide sysdiagnose/akd logs and a Feedback ID if useful.

Filed as FB24607357 (Team ID JPL3AZ6T39).

Same issue here. Team ID: GJP7Y5Q68D

Sign in with Apple fails for every App ID in our team. The system sheet appears, the user picks an account, and authorization then fails with an empty ASAuthorizationError (1000/1001). No request ever reaches our backend.

akd logs match this thread exactly:

Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 AuthKit continuation-key-creation token is missing! No password, but CK is available. Will ask for ck-based auth. Failed to fetch device token. Proceeding with cert headers. Error: AKAuthenticationError Code=-7027 AppleIDAuthSupport: setError: 2:M2 missing (bad password) SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2

Both HTTPS requests to the Apple ID server return status 200, so this is not a networking problem.

Ruled out on our side:

• Minimal test case: a brand-new App ID (com.rm.siwaprobe, created 2026-09-01) with Sign in with Apple enabled as a primary App ID, and a single-screen SwiftUI app containing nothing but one SignInWithAppleButton. Fails identically.
• Entitlement verified in the signed binary (codesign -d --entitlements) and in the decoded embedded.mobileprovision: com.apple.developer.applesignin = ["Default"]
• Capability removed and re-added via App Store Connect API — no change.
• Profiles regenerated, clean build, fresh install on physical devices.
• Two different iPhones with two different personal Apple IDs.
• Same Apple ID signs in successfully with apps from other teams on the same device.
• iCloud and Media & Purchases set to the same Apple ID — no change.
• Screen Time restrictions off, personal (not managed) accounts.
• All agreements accepted, membership active.

Impact: our production app (com.rm.fitnessassistant) has zero successful Sign in with Apple registrations since launch, and App Review rejected our build under Guideline 2.1(a) on 2026-08-12 for exactly this failure — the reviewer hit the same wall.

Feedback: FB<номер>

Could a server-side fix be applied to team GJP7Y5Q68D as was done for other teams in this thread?

Same failure signature, another affected team — Team PAG2G4C6RW / kr.co.fordex.app

Adding our team to this thread. The signature matches this thread exactly, and Sign in with Apple has never once succeeded for this App ID.

Team ID: PAG2G4C6RW Bundle ID / App ID: kr.co.fordex.app (App ID resource B9D9577PS9, platform UNIVERSAL, seedId PAG2G4C6RW) App Store Connect app: 6805027868 ("FORDEX") Feedback Assistant: FB24616817

App ID registration history

• App ID created and Sign in with Apple enabled on 2026-08-21 via the App Store Connect API. Capability APPLE_ID_AUTH with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (single option; no grouping, no secondary/relay App ID, no wildcard App IDs in the team).
• Distribution provisioning profile Q275S5WWFS, created 2026-08-21, IOS_APP_STORE, state ACTIVE, expires 2027-08-21. It is the profile embedded in the failing build.
• Entitlement com.apple.developer.applesignin = ["Default"] is present both in the embedded provisioning profile and in the signed Mach-O of the IPA. The app has zero app extensions.
• No pending agreements; App Store Connect reads and writes both succeed.

Devices and builds

• TestFlight build 7 of version 1.0.1 (build ID d242ff51-f376-4541-8fbb-cff072549083), uploaded 2026-08-31.
• Reproduced on iPhone 16 Pro, iOS 26.6.1 (developer's own device, video recorded).
• Independently reproduced by App Review on iPad Air 11-inch (M3), iPadOS 26.6, on 2026-09-01, which caused the submission to be rejected.

Symptom

1. The Sign in with Apple sheet is presented normally and shows the correct app name.
2. Face ID succeeds.
3. The sheet then shows "Sign Up Not Completed".
4. The app receives ASAuthorizationError.canceled (1001) with empty userInfo and no underlying error.
5. Zero requests reach our backend. Our auth database has never contained a single Apple identity row for the entire lifetime of the project (all other providers work normally).
6. Settings > Apple Account > Sign in with Apple does not list this app on the device, i.e. no credential was ever issued.

Public authorize endpoint probe A GET to https://appleid.apple.com/auth/authorize with client_id=kr.co.fordex.app returns HTTP 200 whose body contains errorCode":"invalid_client" / errorMessage":"Invalid client." (observed 2026-09-02 ~02:45 UTC). I want to be precise about the limits of this datapoint: this endpoint normally expects a Services ID, and I was not able to obtain a control result for a known-good native App ID because Apple's edge began returning HTTP 403 to my host after the first request. I am reporting it only because DanCue's resolution note above states that the same endpoint returned invalid_client for their client_id continuously during the outage and stopped once the server-side registration was repaired.

What we have deliberately NOT done Per this thread, we have not toggled the capability off/on, not regenerated profiles or certificates, and not changed the bundle ID, since those were reported ineffective by every team here. No client-side change has been made.

Request Could Apple please re-register / repair the Sign in with Apple server-side registration for Team ID PAG2G4C6RW, App ID kr.co.fordex.app? Our App Store submission is currently rejected solely because of this, and there is no client-side change available to us that would fix it. I will attach a sysdiagnose with the Accounts and AuthKit logging profile to FB24616817 and will report back here as soon as sign-in completes on device.

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: <private> akd: [authkit:siwa] No applications were found with the provided Client ID: <private> 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.

@Paris X Pinkney — could the same server-side team registration fix be applied to team AMH858VLP3 (client_id com.iplayertv.ios, App ID SBSF892C7B)? Same signature as above, reproduced 2026-09-02 on iOS 26.5 and Mac Catalyst (macOS 26.6):

• akd [authkit:siwa] Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003
• akd [authkit:siwa] No applications were found with the provided Client ID
• AppleIDAuthSupport: setError: 2:M2 missing (bad password) → AKAuthenticationServerError Code=-24000
• appleid.apple.com/auth/authorize returns invalid_client for this client_id

Capability is enabled as a primary App ID (deleted and re-created via the App Store Connect API with no effect), entitlement ["Default"] is in the signed binaries and in the development and App Store profiles, the DPLA is current, and the same Apple ID signs in fine to other teams' apps on the same devices. Fails with and without the .email scope.

Feedback Assistant: FB24625946 (with the akd log excerpt attached). Happy to verify immediately.

Paris X Pinkney — same signature, Team Z92482C52W, Client ID app.coachflat.ios (App ID P44VBP922Y). Filed as FB24626747.

On device (iPhone18,1, iOS 26.6.1, TestFlight build): the sheet presents, Face ID succeeds, "Sign Up Not Completed" appears, and the delegate receives ASAuthorizationError.canceled (1001) with empty userInfo. No credential is issued. 100% reproduction across three builds.

Verified before filing: com.apple.developer.applesignin = ["Default"] in the signed binary and the embedded App Store profile; APPLE_ID_AUTH with PRIMARY_APP_CONSENT via the App Store Connect API; nonce per documentation. Sign in with Google in the same build succeeds on the same device.

One detail that may help triage: this is the first and only App ID in our team to enable Sign in with Apple (enabled 2026-08-31) — consistent with the "fetching developer team" failure in the akd logs others have posted.

Requesting the same server-side re-provisioning applied to GW7XA5CX69 and FRL3DTJQ62. AuthKit-profile sysdiagnose to follow on the FB. Happy to verify immediately.

Same signature, another data point.

Team ID: HP8H99TPR5 (Individual). Bundle ID: app.lazylearn (explicit App ID, Sign in with Apple enabled as primary App ID, APPLE_ID_AUTH = PRIMARY_APP_CONSENT via the App Store Connect API). App: LazyLearn: Languages (6807144676), TestFlight build 1.0 (32), com.apple.developer.applesignin = Default present in the App Store provisioning profile and the signed binary. Agreements accepted.

On iPhone 15 Pro Max the native sheet renders, Face ID succeeds, then "Sign-Up Not Completed"; the app receives ASAuthorizationError 1001 (1000 on earlier attempts) with empty userInfo. No request reaches our backend. The same Apple Account on the same device completes Sign in with Apple with other teams' apps.

akd log captured over USB at the moment of the tap (02 Sep 2026, 22:43 UTC): akd: Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 akd: No applications were found with the provided Client ID: app.lazylearn akd: SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2 AuthKitUIService: AKRemoteViewController did complete with authorization (null) (error: com.apple.AppleIDAuthSupport Code=2, NSUnderlyingError AKAuthenticationServerError Code=-24000) AuthKitUIService: AUTH_ALERT_SIGN_UP_NOT_COMPLETED App(AuthenticationServices): ASAuthorizationController credential request failed with error: AuthorizationError Code=1001

The App ID was registered in late August 2026. Could Apple please inspect the server-side Sign in with Apple registration for Team HP8H99TPR5 / app.lazylearn and re-provision it, as was done for the teams above? Happy to provide a sysdiagnose or file a Feedback report if needed.

Same confirmed server-side registration failure for Chrona, Inc.

Team ID: ZC697J3VQ4

Affected primary App IDs:

• Gentium: A94TXV6J23 / com.gentiumcapital.contractor

• Cluby: J49QQZ5CQW / com.chrona.cluby

Both App IDs have APPLE_ID_AUTH with PRIMARY_APP_CONSENT, and the signed apps and provisioning profiles contain com.apple.developer.applesignin = [Default]. On-device akd logs show AKSQLError -6003, “No applications were found with the provided Client ID,” followed by AKAuthenticationServerError -24000. Apple’s public authorization endpoint independently returns invalid_client / -24000 for both clients, while older Sign in with Apple clients in the same team are recognized. No credential is returned and no request reaches our backend.

Feedback Assistant: FB24630675 (submitted under the Chrona, Inc. team with the evidence attached).

@Paris X Pinkney — could Apple please apply the same server-side registration repair/re-provisioning used for the other resolved teams in this thread to these two App IDs? We can provide additional diagnostics if engineering requests them.

Same failure signature for our team 9WGPXDVM8B on a newly registered App ID (com.bleacherbrag.app, created 2026-08-30): "Sign-Up Not Completed", akd AKSQLError -6003 while fetching the developer team, AKAuthenticationError -7034 delivered to the app. An older App ID on the same team (created 2026-08-06) signs in normally on the same device and Apple Account, and both App IDs show identical PRIMARY_APP_CONSENT settings in the App Store Connect API. Binary entitlements verified with codesign. Filed as FB24631586.

@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

1. 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.
2. 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.
3. 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 signature here — filed as FB24636472.

Team: 72FATVW9YG Bundle ID: com.papeo.app (App ID Y773GP2S8W) Device: iPhone Air, iOS 26.6.1 Failing since 2026-08-10, constant, every device and every Apple Account.

Captured 2026-09-03 14:22 CEST with the Accounts/AuthKit profile installed:

[authkit:siwa] Client has default access level in SiwA entitlement [authkit:siwa] Fetching developer team for client with ID: com.papeo.app [authkit:siwa] Encountered error while fetching developer team: AKSQLError Code=-6003 [authkit:siwa] No applications were found with the provided Client ID: com.papeo.app [authkit:core] Performing SRP request with context [AppleIDAuthSupport] setError: 2:M2 missing (bad password) [authkit:core] ThirdPartyDeviceDataResponseHandler serverProvidedData is nil [authkit:core] SRP authentication with server failed! Status={ ec = "-24000"; em = "Invalid client."; hsc = 200; ptxid = "b1d2feaa-9999-4aa3-a201-86c6e54b99b6"; } NSUnderlyingError = AKAuthenticationServerError Code=-24000 [authkit:core] AlertHandler: AKAuthenticationError Code=-7003 UserInfo={AKClientBundleID=com.papeo.app}

ptxid: b1d2feaa-9999-4aa3-a201-86c6e54b99b6

Portal side verified live via the App Store Connect API today: bundle Y773GP2S8W has APPLE_ID_AUTH with APPLE_ID_AUTH_APP_CONSENT / PRIMARY_APP_CONSENT. Entitlement is in the profile and the binary, and is honoured at runtime. Developer Support case 20000138452301 is open in parallel.

Requesting the same server-side registration repair that resolved GW7XA5CX69 and FRL3DTJQ62.

For anyone else stuck at error 1000/1001 with empty userInfo: install the Accounts/AuthKit profile from developer.apple.com/bug-reporting/profiles-and-logs/, reboot, reproduce, then sudo /usr/bin/log collect --device. Without the profile every useful field logs as <private> and there's no ptxid.

Following up on my earlier post for team XJ5D4FX66P, bundle gg.wishtrap.game, with the piece that was missing: a capture taken with the Accounts/AuthKit logging profile installed, so the server's own strings are not redacted.

Reproduced again today, and the response behind the sheet is:

ec = "-24000" em = "Invalid client." hsc = 200 ptxid = "bcdc243b-03b5-4e85-8b94-9a4a188d5d48"

That is an HTTP 200 refusing the client, which matches what everyone else in this thread is seeing. Posting the ptxid in case it helps locate the refusal server side, since the App ID has APPLE_ID_AUTH enabled in the portal the whole time.

Filed as FB24639435 with the full log window attached. Nothing on our side has changed and nothing on our side is expected to.

Same signature here — adding our team in case it helps with the server-side fix.

Team ID: CAL7UMLKNY App ID: 244F9PAT4X — com.olearis.swapown (the only App ID in this team) PLA accepted: 2026-08-26. App ID registered and Sign in with Apple enabled the same day. First TestFlight build: 2026-08-27. Still failing on a build uploaded 2026-09-03.

Symptom is identical to the rest of this thread: the system sheet renders correctly with our app name and icon, the user authenticates, then the sheet shows "Sign Up Not Completed" and the framework returns ASAuthorizationError 1001 (.canceled) with empty userInfo. No credential is returned, and zero requests reach our backend — our auth database has never recorded a single Apple identity.

Control that isolates it to the team, not the code: the exact same Flutter code, plugin version and device signs in successfully to our dev app com.olearis.swapown.dev, which lives under a different, long-established team (4M6W632NJ7). Same Apple ID, same phone, one works and one does not. Reproduced by two independent testers on separate devices and Apple IDs.

Verified on our side before posting:

• APPLE_ID_AUTH enabled with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT, read back from the App Store Connect API rather than the portal UI. Not grouped, no wildcard App IDs — this team contains exactly one App ID.
• com.apple.developer.applesignin = ["Default"] present in the signed binary that was actually uploaded, confirmed with codesign on the exported .ipa, not just in Xcode. Same value in the archive before re-signing and in the final .ipa.
• application-identifier = CAL7UMLKNY.com.olearis.swapown in both the binary and the App Store provisioning profile (created 2026-08-26 10:51 UTC, active, carries applesignin).
• Distribution certificate and profile both issued under CAL7UMLKNY; only one signing identity present at build time.
• Native ASAuthorizationController flow, scopes email + fullName, SHA-256 of the raw nonce sent to Apple. Nothing custom.

One detail specific to us, in case it is a useful subclass rather than noise: the bundle id com.olearis.swapown previously existed as App ID XQ887KP4RF under team 4M6W632NJ7 with Sign in with Apple enabled. It was deleted there on 2026-08-26 (DELETE /v1/bundleIds returned 204) and registered under CAL7UMLKNY the same day, without an App Transfer. We first assumed this was our cause — but this thread contains plenty of affected teams with no transfer or re-registration at all, so it looks incidental. Flagging it in case the backend state differs for re-registered bundle ids.

FB24649664

Team ID: CDLWFYN589 Bundle IDs affected: br.com.cesto, br.com.cestoparceiros App IDs created: 2026-08-20 (both recreated on that date) Build: TestFlight, iOS 26, physical iPhone Related: Developer Forums thread 837986 (same signature), FB24029082, FB24554959

SUMMARY

Every first-time Sign in with Apple authorization fails with "Sign Up Not Completed". The Apple sheet renders correctly with the app name and the user's account, the user authorizes, and the failure happens after consent, in the SRP exchange with the Apple ID server. Our backend is never reached — signInAsync never returns a credential.

DEVICE LOG (akd, 2026-09-05 17:21:06-13, UTC-3)

Client has default access level in SiwA entitlement Fetching developer team for client with ID: <private> Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 No applications were found with the provided Client ID: <private> Application has no shared credentials Using personal credential state - 2, error - Error Domain=AKAuthenticationError Code=-7074 presenting authorization UI for request <- sheet appears Got a response from user <- user authorizes No password, but CK is available. Will ask for ck-based auth. Task <59764A72-...> received response, status 200 AppleIDAuthSupport: setError: 2:M2 missing (bad password) Invalid/missing value for key acname: (null) Invalid value for key ut: (null) Invalid value for key authType: (null) SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2

The server returns HTTP 200 with the server proof (M2) absent. The "bad password" string is the generic label for error 2 — there is no password in this exchange, as the preceding line shows (No password, but CK is available).

WHAT WE HAVE ALREADY VERIFIED ON OUR SIDE

• Capability APPLE_ID_AUTH present on both App IDs, with APPLE_ID_AUTH_APP_CONSENT: PRIMARY_APP_CONSENT (App Store Connect API).
• com.apple.developer.applesignin: [Default] present in the shipped .ipa (codesign -d --entitlements :- on the extracted payload, not the archive).
• Embedded profile is "iOS Team Store Provisioning Profile" and carries the entitlement (security cms -D -i embedded.mobileprovision).
• Bundle IDs match across app.json, Identifiers and App Store Connect.
• No other App ID in the team declares APPLE_ID_AUTH.
• Program License Agreement accepted (2026-08-25); 2FA active on the account.
• The device log line "Client has default access level in SiwA entitlement" confirms the entitlement is read correctly on device.
• Requesting only fullName (no email scope) does not change the outcome.

EXPECTED

First-time authorization completes and returns an authorization code / identity token to the app.

ACTUAL

"Sign Up Not Completed", with the SRP failure above. 100% reproducible, on every attempt, for every one of our App IDs.

Team W4LV5W25SX — same fingerprint, adding us to the list.

FB24668445

Sheet authenticates, then "Sign Up Not Completed"; the framework returns AuthorizationError code 1001 with an EMPTY userInfo and nothing ever reaches our server (verified as zero rows in both our staging and production databases since 22 Aug 2026).

All three of our App IDs fail, including a MINIMAL CONTROL APP — one view, one ASAuthorizationAppleIDButton, no networking, no server, no shared code with our product, its App ID created after the failures began. It fails identically, which rules out our application code, our entitlements handling and our server.

com.anralabs.lifecompass APPLE_ID_AUTH / PRIMARY_APP_CONSENT com.anralabs.lifecompass.dev APPLE_ID_AUTH / PRIMARY_APP_CONSENT com.anralabs.signinrepro APPLE_ID_AUTH / PRIMARY_APP_CONSENT

Varied with no change: 3 Apple IDs (two different people), 3 devices, a development build and a TestFlight build of the production bundle, both scope combinations, fresh install after a power cycle. Sign in with Apple works normally in third-party apps on the same devices with the same Apple IDs. Capability, seedId and the applesignin entitlement are verified correct in the signed binary and the embedded profile.

One data point on the pattern several of you have noticed: all three of our App IDs were registered on 22 August 2026, and we have NONE predating that. That is consistent with the reports here of an older App ID still working while a newly registered one in the same team fails — it would explain why every one of ours fails rather than just some.

We have deliberately not toggled the capability, regenerated profiles or recreated App IDs, since those were reported here as making no difference and we would rather preserve the state for inspection.

DTS code-level request opened 25 Aug 2026; only the automated acknowledgement so far. Our own thread: https://developer.apple.com/forums/thread/844736

Requesting the same server-side re-registration that resolved GW7XA5CX69 and FRL3DTJQ62.

Same issue here, identical signature.

Team ID: 54D736559Z Bundle ID: com.puzzlelogic.nonogram App ID: HU7X7Q39JR

The sheet presents correctly, Face ID succeeds, scopes are selected, then "Sign Up Not Completed" and the delegate gets ASAuthorizationError.canceled (1001) with empty userInfo. No credential is issued, so nothing reaches our backend.

akd logs match this thread exactly:

Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 No applications were found with the provided Client ID: com.puzzlelogic.nonogram AppleIDAuthSupport: setError: 2:M2 missing (bad password) SRP authentication with server failed! Code=2 AKRemoteViewController did complete with authorization (null) (error: NSLocalizedDescription=Invalid client., NSUnderlyingError=AKAuthenticationServerError Code=-24000) ... Domain=AKAuthenticationError Code=-7003

Client side is verified correct:

• com.apple.developer.applesignin = ["Default"] present in the signed

binary on device (codesign -d --entitlements)

• APPLE_ID_AUTH with PRIMARY_APP_CONSENT confirmed via the App Store

Connect API (GET /v1/bundleIds/{id}/bundleIdCapabilities)

• Entitlement also present in the App Store provisioning profile
• Bundle ID consistent across Info.plist, profile and App ID

Ruled out: the same Apple Account on the same device signs in with Apple successfully to another team's App Store app immediately before and after a failing attempt. Also reproduces with a second Apple Account on a simulator, on both Wi-Fi and cellular, and in debug and profile builds. Apple system status showed Sign in with Apple as OK throughout.

Device: iPhone 15 Pro Max, iOS 26.6.1 (23G83). Xcode 26.3.

Feedback filed: FB24669750

Could our team's App ID registration be re-provisioned server-side as was done for GW7XA5CX69 and FRL3DTJQ62 earlier in this thread? Happy to provide a sysdiagnose.

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!