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

Sign in with Apple fails for our Team ID with "Sign Up Not Completed"

Team ID: 3CKFWN9ZBM Bundle ID: app.kardea App: Kardea (App Store ID 6793991476), live on the App Store since September 7, 2026

Symptom: the native Sign in with Apple sheet appears, Face ID succeeds, then the sheet shows "Sign Up Not Completed". No credential is returned to the app, and no request ever reaches our backend. Not a single Apple-created account exists in our database since the App ID was created in July 2026. This happens for every user and every build, on both TestFlight and App Store builds.

Configuration verified on our side:

• App ID app.kardea has Sign in with Apple enabled as a primary App ID.
• The signed binary and its App Store provisioning profile both carry the entitlement com.apple.developer.applesignin = ["Default"].
• The app uses ASAuthorizationAppleIDProvider with requestedScopes fullName and email.
• Our backend verifies the identity token against https://appleid.apple.com/auth/keys.

This matches the server-side registration issue described in Developer Forums thread 837986, where the reported signature is "No applications were found with the provided Client ID" and the app receives ASAuthorizationError.canceled with an empty userInfo. Several teams listed in that thread were repaired server-side with no client changes.

Please check whether our Team ID 3CKFWN9ZBM and App ID app.kardea are correctly registered in the Sign in with Apple authorization database.

@Paris X Pinkney — same issue, still present, team not yet in the list.

Team ID: U8D7WQV7NA Bundle ID: vision.unleashed.mobile (App ID registered July 2026)

Capability (APPLE_ID_AUTH, primary app consent), entitlement in both the signed binary and the embedded provisioning profile, and agreements all verified. Reproduced 2026-09-08 20:24 +0100 on iOS 26.6 (TestFlight build). akd logs with the Accounts profile installed:

Fetching developer team for client with ID: vision.unleashed.mobile Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 No applications were found with the provided Client ID: vision.unleashed.mobile AlertHandler called with error: Error Domain=AKAuthenticationError Code=-7003 {AKClientBundleID=vision.unleashed.mobile}

Sign in with Apple works in unrelated apps on the same device and Apple Account. Also reproduced by App Review (2.1(a) rejection).

Filed as FB24705640 with the sysdiagnose attached. Could our team be added to the server-side re-registration queue?

Same issue here. Team ID K322BCXN7N, bundle ID com.vmatusevic.ListReel, App ID registered 2026-09-01 with Sign in with Apple enabled as a primary App ID. The sheet renders, authentication succeeds, then "Sign-Up Not Completed"; the app gets no callback. Reproduced in a development build on 2026-09-02 and in a TestFlight build under an App Store profile on 2026-09-09. Feedback filed: FB24708261. Could someone please re-provision the team's Sign in with Apple registration?

@Paris X Pinkney — could the same server-side team-registration fix applied to GW7XA5CX69 and FRL3DTJQ62 be applied to 44P7GPF4HC? Same signature as the rest of this thread, captured today, with a server transaction ID to pull it from your side. Team ID: 44P7GPF4HC · App ID: app.padimu (resource 3XPCF75FKV) · App Store ID 6797140332 Feedback Assistant: FB24712097 — sysdiagnose with the Accounts/AuthKit profile attached Server transaction: ptxid 1b8098e2-e4e0-439a-b0a5-3bd269b5be41 (2026-09-09 08:41:07 CEST) The app has been live on the App Store since 24 August 2026: 0 successful Sign in with Apple authorizations out of 88 accounts created. Every other sign-in path works. Device log — iPhone, iOS 23G83, TestFlight build, Accounts/AuthKit profile installed: 08:40:53.695 akd [authkit:siwa] Client has default access level in SiwA entitlement 08:40:53.698 akd [authkit:siwa] Setting clientID to app.padimu 08:40:53.698 akd [authkit:siwa] Setting teamID to 44P7GPF4HC 08:40:53.705 akd [authkit:siwa] Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 08:40:53.705 akd [authkit:siwa] No applications were found with the provided Client ID: app.padimu 08:41:07.731 akd [authkit:core] { ec = "-24000"; em = "Invalid client."; hsc = 200; ptxid = "1b8098e2-e4e0-439a-b0a5-3bd269b5be41"; } for executed request (<AKSRPRequest>) 08:41:07.742 akd [authkit:core] SRP authentication with server failed! com.apple.AppleIDAuthSupport Code=2 "M2 missing (bad password)" 08:41:12.827 Runner [authkit:siwa] Authorization failed: AKAuthenticationError Code=-7003 UserInfo={AKClientBundleID=app.padimu} Face ID succeeds 14 seconds before the server rejects the exchange, so this is not a cancellation. As Ozvern noted earlier in this thread, the -6003 line reads as a first-authorization cache miss; the decisive event is the -24000 "Invalid client" GSA response — which is what the ptxid above points to. Client side re-verified today via the App Store Connect API: APPLE_ID_AUTH with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT; the team contains exactly one App ID (app.padimu), no wildcard and no grouped identifiers; com.apple.developer.applesignin = ["Default"] is present in the signed binary, and iOS confirms reading it in the log above. Native ASAuthorizationController, no third-party plugin. Same failure on App Store, TestFlight, debug and Simulator builds, with several Apple Accounts and devices. Happy to verify and close the Feedback the moment it is re-provisioned.

FYI guys, this issue has been solved automatically after a few days.

@Paris X Pinkney — same issue, still present, team not yet in the list.

Team ID: Z7B8KX297F (Organization, enrolled 2026-08-31) · Bundle ID: fr.deliciomap.app (App ID D6SNV93YM8, APPLE_ID_AUTH / PRIMARY_APP_CONSENT) · App: DelicioMap, TestFlight Feedback Assistant: FB24688196 (filed 2026-09-07, updated today with the akd capture)

Symptom identical to the rest of the thread: native sheet renders, Face ID succeeds, then "Sign Up Not Completed"; the app receives ASAuthorizationError 1001 with empty userInfo, nothing reaches our backend. Reproduced 2026-09-07 and again 2026-09-09 15:37 CEST on iOS 26.5.1 (23F81), fresh Release build.

akd, 2026-09-07: Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003, then No applications were found with the provided Client ID: fr.deliciomap.app

akd, 2026-09-09: 15:37:04.562 AppleIDAuthSupport: setError: 2:M2 missing (bad password) 15:37:04.563 SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2 15:37:13.254 Error performing auth request: Error Domain=AKAuthenticationError Code=-7003 {AKClientBundleID=fr.deliciomap.app} 15:37:13.256 ASAuthorizationController credential request failed: AuthorizationError Code=1001

Client side verified: com.apple.developer.applesignin = ["Default"] and application-identifier = Z7B8KX297F.fr.deliciomap.app in the signed binary (codesign -d --entitlements). The same Apple Account signs in fine to other teams' apps on the same device.

Could the same server-side team-registration fix applied to GW7XA5CX69 and FRL3DTJQ62 be applied to Z7B8KX297F? Happy to re-test and confirm immediately, and to close the Feedback once repaired.

@Paris X Pinkney — could the same server-side team-registration fix applied to GW7XA5CX69 and FRL3DTJQ62 be applied to 44P7GPF4HC? Same signature as the rest of this thread, captured today, with a server transaction ID to pull it from your side.

• Team ID: 44P7GPF4HC · App ID: app.padimu (resource 3XPCF75FKV) · App Store ID 6797140332
• Feedback Assistant: FB24712097 (sysdiagnose with the Accounts/AuthKit profile attached)
• Server transaction: ptxid 1b8098e2-e4e0-439a-b0a5-3bd269b5be41, 2026-09-09 08:41:07 CEST
• Live on the App Store since 24 August 2026: 0 successful Sign in with Apple authorizations out of 88 accounts created. Every other sign-in path works.

Hi everyone,

If you have not yet created a Feedback ID for these "Sign Up Not Completed" errors, please submit a bug report via Feedback Assistant:

Gathering required information for troubleshooting Sign in with Apple authorization and token requests

https://developer.apple.com/forums/thread/801173

Remember to include your Team ID, Client ID/Services ID, affected user ID/email, and sysdiagnose logs. Once submitted, please reply with your Feedback ID.

Cheers,

Paris X Pinkney |  WWDR | DTS Engineer

Same signature here, on an App ID created in August 2026.

Team ID: 276UBMJFVS Bundle ID / Client ID: com.openshimmy.open (App ID V2XX9T4FG9, platform Universal) App ID created: 2026-08-12; Sign in with Apple capability enabled 2026-08-15 (APPLE_ID_AUTH, PRIMARY_APP_CONSENT) Feedback Assistant: FB24734174 App: OPEN, App Store id 6800488516 (live since 2026-08-13, currently 1.0.17)

Symptom: the native sheet renders, the user authenticates, then "Sign Up Not Completed". ASAuthorizationController returns ASAuthorizationError 1000 (our client instrumentation records the code; 1001 would be recorded as well). No credential, and zero requests ever reach our backend. Zero Apple identities have ever been created for this app; Google sign-in on the same devices works.

Verified: com.apple.developer.applesignin = ["Default"] in the signed App Store binary and its embedded provisioning profile; bundleIdCapabilities shows PRIMARY_APP_CONSENT; membership, certificate and profile all valid.

Reproduced on: multiple iPhones and Apple IDs since 2026-08-18, across every App Store build from 1.0.6 to 1.0.17 (from timing, App Review devices included). One anomaly for the record: a single iPhone did receive a credential from the sheet on 2026-08-17, and the same phone hit "Sign Up Not Completed" the next day.

Sysdiagnose with the Accounts/AuthKit profile available on request as soon as we have an affected device in hand.

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

Same signature here, still failing as of today.

• Team ID: CKR4VUYMCD
• Bundle ID / client_id: com.packandpeek.app
• Feedback: FB24739690 (sysdiagnose with the Accounts/AuthKit profile attached)
• Devices: iPhone 15 Pro Max and a brand-new iPhone 17, iOS 26.6, with two different Apple Accounts (one that had never used the app)
• Distribution: TestFlight

Capability enabled 10 August 2026. Native sheet renders, biometric completes, then "Sign Up Not Completed"; delegate receives ASAuthorizationError 1001 with empty userInfo only after dismissal; no credential, no request ever reaches our backend.

Verified before posting: com.apple.developer.applesignin = (Default) in the signed binary's code signature and in embedded.mobileprovision; App ID capability via ASC API is APPLE_ID_AUTH with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT; single App ID in the team, no wildcard; agreements accepted. Tried: portal re-save, delete/re-create of the capability via API, new provisioning profile generated after the re-registration with a new build signed against it, replacing our Capacitor plugin with a first-party ASAuthorizationController implementation identical to Apple's sample, Share My Email and Hide My Email, device restarts, and a month of waiting. No change.

This is blocking our App Store release - we were rejected under Guideline 4.8 and Sign in with Apple is the required remedy. @Paris X Pinkney, could Team ID CKR4VUYMCD be added to the server-side registration fix? Happy to provide anything else needed.

Same issue here

Integration done on iPhone app.

Team ID: 6FXUMT5X23

Error: Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.codebrew.applelogintest123} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={_LSLine=75, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler, _LSFile=LSDReadService.mm, NSDebugDescription=process may not map database} Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={_LSLine=75, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler, _LSFile=LSDReadService.mm, NSDebugDescription=process may not map database} Failed to get application extension record: Error Domain=NSOSStatusErrorDomain Code=-54 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)" "Error" "The operation couldn’t be completed. (com.apple.AuthenticationServices.AuthorizationError error 1001.)"

FeedbackID: FB24711730

Same issue here, still unresolved. Adding our details so DTS can correlate.

• Team ID: KT9P85VC2P
• Bundle ID / Client ID: com.cvergarabah.piya
• Feedback: FB24607596 (open, full sysdiagnose attached), FB24569985 (original, closed)

Same signature: the native sheet shows "Sign Up Not Completed" after Face ID confirmation, and the delegate receives ASAuthorizationError 1000/1001 with no credential. AuthKit logs from the sysdiagnose:

AKSQLError -6003 "No applications were found with the provided Client ID" AppleIDAuthSupport Code=2 "M2 missing (bad password)" AKAuthenticationServerError -24000

Verified: APPLE_ID_AUTH with PRIMARY_APP_CONSENT on the App ID; com.apple.developer.applesignin = ["Default"] in both the signed binary and the provisioning profile. Reproduced on two iPhones (iOS 18.7.8 and 26.6) with two different Apple Accounts. Google Sign-In works end to end in the same build.

This is blocking our first App Store submission. @Paris X Pinkney, could you please check whether our team's Sign in with Apple registration can be repaired like the others in this thread? Happy to provide fresh logs or a new reproduction at any time.

Thank you!

Same signature here. Team ID 4QF8GJDJ5B, bundle ID com.outfitai.outfitai (App Store app Awtfit). Native ASAuthorizationAppleIDProvider, scopes name and email. The sheet presents, the user authenticates, then "Sign Up Not Completed", and the app receives ASAuthorizationError.canceled (1001). Zero successes ever since the feature shipped on 2026-08-30: in the last five days alone 235 taps from 131 devices on 21 iOS versions (18.7 through 27.0), with a median of 11.7 seconds on the sheet before the error, so these are not dismissals. Google sign-in works on the same devices. The entitlement is in the signed binary and the App Store profile; the App ID is a primary App ID with APPLE_ID_AUTH / PRIMARY_APP_CONSENT (enabled through the App Store Connect API on 2026-08-29); agreements active. Feedback filed: FB24770553, with the telemetry attached. Developer Support case 102962516449.

We're hitting this exact issue on our team and would be grateful to be added to the fix. Same symptoms: native Sign in with Apple shows "Sign Up Not Completed," the app gets no callback, and Console shows akd SRP authentication with server failed (Code=2). The entitlement is present (the sheet + Face ID appear), the App ID has Sign in with Apple enabled as a primary App ID, our web (Services ID) flow works, and the same Apple ID signs in fine with Apple in other apps. Apple's own App Review team also reproduced it, blocking our submission under 2.1(a).

Team ID: D9A9BLNR6U App ID: com.narralife.lifestorycompiler Feedback: FB24774025

Could our team's backend Sign in with Apple registration be repaired as well? Thank you.

Update, September 14: Sign in with Apple is now working for us, including in our actual Expo/Supabase app. Sharing what we found in case it helps others.

We reproduced the failure in a minimal native Swift app using AuthenticationServices, with no Expo or Supabase involved. The app received authorization error 1001; with Apple’s Accounts/AuthKit logging profile installed, device logs showed the underlying rejection: -24000 / Invalid client. The cancellation-style error did not mean we had manually canceled.

The most actionable finding: although the provisioning profile embedded in our failing builds had the correct Sign in with Apple entitlement and a future expiration date, Apple’s API reported its state as INVALID.

We then built the same native test with a freshly generated ACTIVE provisioning profile, keeping the same bundle ID, developer team, distribution certificate, SDK, and request parameters. It succeeded. An Expo build using that same fresh profile also succeeded, including the Supabase identity-token exchange. We subsequently verified login, onboarding, session persistence after restart, and sign-out/sign-in in the actual app.

Caveat: this is a successful recovery, not proof that the profile alone caused or fixed the problem. We cannot rule out Apple-side state changes or propagation during testing, and we don’t know why the previous profile was invalid. Our successful tests so far are internal/ad hoc builds; we have not yet verified the updated App Store distribution.

For anyone still stuck, checking the profile’s current status with Apple, rather than relying only on its embedded entitlements and expiration date, seems worth investigating. We did not need to change our production bundle ID, upgrade the Expo Apple-auth wrapper, or change Supabase’s provider configuration.

Also, a correction to my earlier post: I mistakenly labeled the App ID resource identifier as our Team ID. Our actual Team ID is GNNA76QH2C.

Update: Sign in with Apple is now working for us as well, and I want to confirm the fresh-provisioning-profile finding above — we're an Expo/EAS + Clerk app and hit the identical "Sign Up Not Completed" / akd SRP Code=2 failure.

Our App Store provisioning profile looked completely healthy: status Active in the Developer portal, a future expiration, and the correct com.apple.developer.applesignin = Default entitlement. Native Sign in with Apple still failed for every user and even for Apple's App Review team, while our web (Services ID) flow worked fine.

What we did — nothing but a fresh profile:

Regenerated ONLY the iOS App Store provisioning profile (via EAS), keeping the same bundle ID (com.narralife.lifestorycompiler), same team (D9A9BLNR6U), and the same distribution certificate. No new certificate. The new profile came back ACTIVE (live from Apple's API) with the Sign in with Apple entitlement intact. Rebuilt with the fresh profile and uploaded a new TestFlight build. No app code, no Expo apple-authentication change, no Clerk/provider change, no bundle ID change.

Result: native Sign in with Apple now completes and returns the identity token; login, onboarding, and session persistence all work.

Caveat (same as noted above): I can't prove the profile alone was the cause — Apple-side state may have changed or propagated during the same window. But regenerating the profile is the only thing we changed, so for anyone still stuck on Expo/EAS, generating a fresh App Store provisioning profile and rebuilding is worth trying. Feedback filed as FB24774025.

Same signature here, never worked once: team 58SQGZ3X8Y, bundle no.ungevil.stride, App ID created 2026-08-24. Native sheet authenticates, then "Sign-Up Not Completed", ASAuthorizationError 1001 with empty userInfo, nothing reaches the relying party. Entitlement verified in profile and binary, APPLE_ID_AUTH / PRIMARY_APP_CONSENT read back from the ASC API, same Apple ID registers fine in other apps. Filed FB24811063 and Developer Support case 102965715927. If anyone at Apple can look at the registration record for this client ID, we would be grateful.

Same failure here, still ongoing.

Team ID: 3S5339K8KX (enrolled 2026-06-27)

Bundle ID: co.streamind.meli

Feedback: FB24701950 (filed 2026-09-08, no reply yet)

Sign in with Apple has never completed once for this app. Retested today on iPadOS 27.0 with the Accounts/AuthKit logging profile installed, so the identifiers are not redacted:

akd: Fetching developer team for client with ID: co.streamind.meli
akd: Executing query: SELECT team_id FROM authorized_applications WHERE client_id = 'co.streamind.meli'
akd: Rows changed: 0
akd: Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003
akd: No applications were found with the provided Client ID: co.streamind.meli

The request then reaches Apple's authentication server, which returns ec = -24000, em = "Invalid client.", with HTTP status 200.

On our side the App ID has Sign in with Apple enabled as a primary App ID (verified through the App Store Connect API as well as the portal), the signed binary carries com.apple.developer.applesignin, and Google sign-in works in the same build. Nothing in the app or on the device changes the outcome, and this is currently blocking our App Store release.

If an Apple engineer reading this can route our team registration for re-provisioning, we would be grateful. We can retest and confirm the same day.

Update for team 58SQGZ3X8Y (no.ungevil.stride, FB24811063): Sign in with Apple works for us as of 17 September, tested on device with the same TestFlight build that failed this morning. No change on our side — same App Store provisioning profile from 30 August (ACTIVE), same certificate, same binary configuration. So this looks like Apple's server-side fix reaching another team, consistent with the reports above. Closing our Feedback as resolved. Thank you to everyone who documented the signature here.

Same symptom here, for Team 64565S7RQD / bundle com.dinizquiz.quizbiblico (App Store app 6772226808, DINIZ QUIZ Biblico).

The native Sign in with Apple sheet renders, the user authenticates and taps Continue, then the sheet shows "Sign Up Not Completed" and the delegate receives ASAuthorizationError Code=1001 with empty userInfo. No credential is delivered and our backend never receives a request (confirmed with server logs). Reproduced on a physical iPhone (iOS 18.7) three times today (2026-09-20, 17:42Z / 17:58Z / 18:07Z), and by App Review on iPad Air 11-inch (M3), iPadOS 26.6, which rejected 1.0.1 twice under Guideline 2.1(a) (submissions 875b2735 on Aug 28 and 1e8b3abd on Sep 19).

Checked and ruled out: com.apple.developer.applesignin = [Default] is in the signed binary and in the embedded App Store provisioning profile; the App ID (PKYNWAGZUL) has APPLE_ID_AUTH enabled as PRIMARY_APP_CONSENT (verified via the App Store Connect API); the request uses requestedScopes fullName+email, a raw nonce, a state and a presentationContextProvider; the same flow also fails with the community Capacitor plugin used in the live 1.0 build. On the iOS 26.5 Simulator with no Apple Account the failure is the expected AKAuthenticationError -7026 -> 1000, so the device failure is different and server-side.

Filed FB24866093 (Authentication Services Framework, iOS). Could the Sign in with Apple server-side registration for Team 64565S7RQD / com.dinizquiz.quizbiblico be checked, as was done for the teams above? Thank you.

Same signature here — adding our Team ID so it can be included in the server-side fix.

Team ID: WCCJWRTJZU Bundle ID: app.myquota.ios (App Store Connect app 6789743758) Feedback Assistant: FB24867593 Sign in with Apple enabled on the App ID on 2026-07-24 (APPLE_ID_AUTH with PRIMARY_APP_CONSENT, read back through the App Store Connect API on 2026-09-20). The account was converted from Individual to Organization on 2026-09-10 (same Team ID) and the membership was inactive between 2026-09-05 and 2026-09-10.

Symptom: the native sheet renders, the user authenticates with Face ID, then the sheet shows "Sign Up Not Completed" (Spanish devices: "Registro no completado") and ASAuthorizationError.canceled (1001) is returned with an empty userInfo. Same result with "Share My Email" and "Hide My Email". Reproduced on TestFlight builds 1387 and 1388 on several iPhones with real users' Apple IDs, and by App Review on an iPad Air (iPadOS 26.6.2).

Ruled out on our side: com.apple.developer.applesignin = ["Default"] present and wired to the target, automatic cloud signing, bundle ID equal to the audience our backend validates, and Google Sign-In completing normally through the same plugin, binary, device, network and backend.

App Review rejected the app under 2.1(a) on 2026-09-14 for this exact failure and stated they cannot provide technical assistance. Developer Program Support case 102963412403 (opened 2026-09-14) has had no engineer reply so far.

Could App ID app.myquota.ios be included in the re-provisioning? Happy to provide akd logs or a ptxid on request.

Follow-up for Team WCCJWRTJZU: FB24867593 is now complete with everything requested in thread 801173.

Reproduced on 2026-09-20 at 19:33 (America/Mexico_City, UTC-5) on a physical iPhone running iOS build 23G90, with the Accounts/AuthKit logging profile installed beforehand, using TestFlight build 1.11.188 (1391) of app.myquota.ios. The sysdiagnose captured right after the failure (19:35:34) is attached to the Feedback report, together with the affected user's Apple ID and the exact timestamp.

One detail that may matter for triage: the report still shows "Recent similar reports: None", so it does not appear to be grouped with the other teams in this thread despite the identical signature (ASAuthorizationError.canceled 1001 with empty userInfo, AKSQLError -6003). Could App ID app.myquota.ios be linked to this known issue and included in the same server-side re-provisioning that resolved GW7XA5CX69 and FRL3DTJQ62?

Developer Program Support case 102963412403 is also open since 2026-09-14 with no engineer reply. Happy to provide akd logs or a ptxid if that helps.

We are affected by the same issue.

Team ID: SW8F94Y42Y Bundle ID: com.homyaid.app (App Store Connect app 6781570051, TestFlight)

Symptoms identical to the reports above: the native Sign in with Apple sheet appears, Face ID completes, then "Sign-Up Not Completed" is shown and ASAuthorizationController returns error 1000 (.unknown) with no credential. No request ever reaches our servers. Reproduces 100% on real devices and simulator, across multiple days.

Client side is fully verified: com.apple.developer.applesignin = ["Default"] is present in the signed binary's entitlements, the distribution profile is ACTIVE, the App ID has APPLE_ID_AUTH enabled as PRIMARY_APP_CONSENT (checked via the App Store Connect API), and the Program License Agreement was accepted on September 20, 2026 - the failure persisted unchanged for 3+ days after acceptance.

Server-side evidence matching this thread: https://appleid.apple.com/auth/authorize?client_id=com.homyaid.app&... returns {"errorCode":"invalid_client","errorMessage":"Invalid client."} - the same response as a nonexistent client_id, while a known-working SIWA app queried with the identical request shape returns invalid_request (redirect URL) instead. Our App ID appears to be missing from the SIWA backend registration despite correct portal configuration.

Filed as FB24922696 with a sysdiagnose from an affected iPhone 17 attached.

Could this team/App ID be included in the server-side re-provisioning? Happy to provide akd logs if useful.