We urgently need a response from the relevant authorities

Hi everyone! We recently integrated "Sign in with Apple" into our application using standard social login flows. For the vast majority of our users, the integration works perfectly—we receive the user's email during sign-in and sign-up. However, we are noticing an edge case where a small subset of users are returning an ID token that is completely missing the email. We can't seem to reproduce this error ourselves during testing. Every time we test a sign-up or sign-in, the email payload is included exactly as expected. My Questions: Is there a specific reason why Apple would omit the email claim from the ID token? Any insights or guidance would be greatly appreciated. Thank you!

Hi, Feedback ID - FB24176019 I am investigating a Sign in with Apple issue affecting my production application and would appreciate guidance on what Apple may be rejecting during the token exchange. The authorization stage succeeds and Apple returns an authorization code to our callback. The failure occurs when the authorization code is exchanged at: https://appleid.apple.com/auth/token The production OAuth implementation uses Better Auth 1.6.13. Apple configuration: Primary App ID / Bundle ID: com.whatsupplier.uk Services ID / client_id: com.whatsupplier.uk.signin Registered return URL: https://www.whatsupp.uk/api/auth/callback/apple We have checked the client secret JWT and confirmed: alg = ES256 kid matches the active Apple key iss matches our Apple Team ID sub = com.whatsupplier.uk.signin aud = https://appleid.apple.com iat/exp are valid the JWT signature verifies locally against the configured Apple private key the signature is P1363/raw r||s rather than ASN.1 DER the private key is EC / prime256v1 the redirect_uri exactly matches the registered return URL the token request uses application/x-www-form-urlencoded The unusual behaviour is reproducible: The real Better Auth token exchange reaches Apple's /auth/token endpoint but Apple responds: HTTP 400 error: invalid_client We created a diagnostic request directly to the same Apple token endpoint using the same configured credentials and a deliberately invalid authorization code. Apple responds: HTTP 400 error: invalid_grant "The code has expired or has been revoked." This indicates Apple accepts the client credentials/JWT in the direct request and proceeds as far as validating the authorization code. We also performed an A/B test using the exact same generated client-secret JWT: Test A: grant_type code redirect_uri client_id client_secret Result: invalid_grant Test B: grant_type code redirect_uri client_id client_secret code_verifier Result: invalid_grant Therefore code_verifier alone does not change Apple's classification. We then captured the observable shape of the real Better Auth token request and compared it with a direct request. The client_id, redirect_uri, grant_type, client-secret JWT claims, URLSearchParams/form encoding and absence of an Authorization header were consistent. Despite this, the real framework-generated exchange returns invalid_client while the direct diagnostic request is accepted at the client-authentication stage and returns invalid_grant. Could Apple advise what additional property of the token request could cause this difference in classification? In particular, is there any server-side state or request characteristic used by Sign in with Apple that could cause an otherwise valid client_secret to be classified as invalid_client only during the real authorization-code exchange? I have also prepared detailed diagnostic evidence and can submit the requested sensitive request information through Feedback Assistant rather than posting JWTs, authorization codes, or other credentials publicly. Thank you.

Sign in with Apple never completes for our app. The authorization sheet presents, the user confirms, and we get ASAuthorizationError 1000. The akd log shows the local entitlement check PASSING and the failure happening server-side. Environment: native ASAuthorizationAppleIDProvider (no web flow, no Services ID), TestFlight build, iOS 26. New App ID created 2026-08-06. akd, abridged — local check passes: akd Requesting password only: NO akd Client has default access level in SiwA entitlement akd Client has underage-users access level in SiwA entitlement sheet presents, user confirms: akd presenting authorization UI for request akd Remote view sent a user response event akd Attempting authorization with response then the server rejects it, after returning HTTP 200: akd Adding passwordlessToken: NO, and idmsDataToken: NO, to auth-params akd No password, but CK is available. Will ask for ck-based auth. akd Performing SRP request with context akd Task ... received response, status 200 content K akd AppleIDAuthSupport: setError: 2:M2 missing (bad password) akd Invalid/missing value for key acname: (null) akd SRP authentication with server failed! Domain=com.apple.AppleIDAuthSupport Code=2 akd Error performing auth request: Domain=AKAuthenticationError Code=-7003 What we have already ruled out: Sign in with Apple enabled on the App ID, configured as "Enable as a primary App ID" (verified in the portal UI, not just via the App Store Connect API). Provisioning profiles deleted and regenerated AFTER enabling the capability, twice, the second time a full day later. The embedded .mobileprovision in the shipped build contains com.apple.developer.applesignin = (Default). The signed binary carries the entitlement (codesign -d --entitlements on the archive). More than 24 hours elapsed since enabling the capability, per the guidance on -7003 in thread 789697. requestedScopes tried as both [.email] and [.fullName, .email]. App deleted and reinstalled; device restarted. Reproduced on a SECOND device (an iPad) that had never had the app installed. Control: a third-party App Store app created a brand-new Sign in with Apple association (it prompted for name, so first-time consent) on the same device and same Apple ID, minutes after our failure, so the account and device can create new associations. Question: what causes Apple's identity service to reject the SRP exchange for one client while accepting it for others on the same device and account? Is there additional App ID or account state we cannot see from the portal? Happy to provide the full akd log.

In order to use Sign in with Apple, I issued a JWT client according to the instructions and was able to connect without any problems, but suddenly an INVALID_CLIENT error started to occur. The error was resolved by re-obtaining the JWT client token and resetting it. The validity period of the JWT client token is 6 months and it has not expired yet, but I would like to know why I am getting an INVALID_CLIENT error.

I am looking for help diagnosing a Sign in with Apple failure that occurs after Face ID and before a credential is returned. Environment iPhone 15 Pro iOS 26.2 Xcode 26.3 TestFlight distribution builds Team ID 42U……D944 Bundle IDs com.vybers.vybers-ios com.vybers.vybers Reproduction Install the app from TestFlight. Tap Sign in with Apple. Complete Face ID. Face ID succeeds but the authorization sheet reports that registration could not be completed. The app receives no ASAuthorizationAppleIDCredential and no identityToken. The same behavior occurs Across multiple builds. On multiple physical devices. With multiple Apple IDs. In both Bundle IDs belonging to the same team. In Apple's official Juice sample app using the official Sign in with Apple flow. Control experiment The same iPhone successfully signs in with Apple in a newly downloaded unrelated App Store app. The relevant device log captured immediately after the failure includes Apple server response HTTP 200 AppleIDAuthSupport setError 2M2 missing bad password SRP authentication with server failed AKRemoteViewController did complete with authorization null AKAuthenticationServerError Code=-24000 The “bad password” text is confusing but the Apple ID works in unrelated apps and the failure happens after successful Face ID. The application server is never contacted because no credential or identityToken is produced. Could this be caused by a team-scoped Sign in with Apple/AuthKit registration or synchronization problem rather than by the client implementation or server-side token verification In particular I would appreciate guidance on Checking the Sign in with Apple registration for the team. Checking whether multiple client IDs in one team can become stale or out of sync. Whether an individual Developer Program membership changes any requirement for this flow. Which diagnostic information Apple needs to investigate the AuthKit backend response. I can provide the full Team ID build details signing entitlements and a sysdiagnose through a private support case.

Hello, We already have an existing iOS app on this Apple Developer team that successfully uses Sign in with Apple. However, Sign in with Apple consistently fails for our second and newer App ID, com.siremo.flare, before any Apple credential or identity token is returned. Both apps belong to the same Apple Developer team and have equivalent Sign in with Apple configurations. App information: Affected app: Flare Affected Bundle ID: com.siremo.flare Working existing Bundle ID: com.siremo.aily Team ID: JYGN9K53XA Distribution: iOS Simulator and TestFlight TestFlight build: 0.2.3 (2) Developer Support case: 102947765951 Symptoms: In the iOS Simulator, the Sign in with Apple sheet becomes unresponsive after entering the Apple ID password. In TestFlight on physical devices, the system sheet displays “Sign Up Not Completed”. No Apple credential or identity token is returned to the app. Firebase Authentication and our backend authentication code are never reached. Console output from a reproduction using Apple’s native SwiftUI SignInWithAppleButton: Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.siremo.flare} ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)" The user did not cancel the authorization request. What we have verified: Sign in with Apple is enabled for com.siremo.flare in Certificates, Identifiers & Profiles. Apple Developer Support confirmed that Sign in with Apple is enabled for this App ID under case 102947765951. We removed and re-added the Sign in with Apple capability in Xcode and the Developer Portal. We regenerated the provisioning profile, created a new Archive, and distributed a new TestFlight build. The issue persists. We inspected the entitlements embedded in the actual archived Flare app: application-identifier = JYGN9K53XA.com.siremo.flare com.apple.developer.applesignin = [Default] The embedded provisioning profile contains the same application identifier and Sign in with Apple entitlement. The issue reproduces with multiple Apple ID accounts and multiple physical devices. Flare is our second app and newer App ID on this Apple Developer team. Our existing app, com.siremo.aily, successfully completes Sign in with Apple using: the same Apple Developer team the same physical device the same Apple ID an equivalent native Sign in with Apple implementation an equivalent entitlement and provisioning configuration Only the newer App ID, com.siremo.flare, fails with AKAuthenticationError -7003 and AuthorizationError 1001. We reproduced the same failure using Apple’s native SwiftUI SignInWithAppleButton. This rules out our custom ASAuthorizationController delegate, controller retention, presentation-anchor implementation, and custom button implementation. Our diagnostic logging confirms that the failure occurs before the Apple authorization callback succeeds and before an identity token is issued. Firebase Authentication and our backend are downstream of this callback and are therefore not involved in the failure. The combination of: AKAuthenticationError -7003 AKClientBundleID=com.siremo.flare AuthorizationError 1001 without a user cancellation the “Sign Up Not Completed” system message an existing App ID on the same team working correctly only the second and newer App ID failing the failure reproducing with Apple’s native SignInWithAppleButton appears similar to other reports where existing App IDs continue to work while newly registered App IDs fail, despite having valid Sign in with Apple capabilities, entitlements, and provisioning profiles. Could an Apple engineer please compare the server-side Sign in with Apple registration state of: Working: JYGN9K53XA.com.siremo.aily Failing: JYGN9K53XA.com.siremo.flare and verify whether the newer App ID was correctly registered and propagated in the Sign in with Apple backend? If the registration is incomplete, stuck, or inconsistent, could it be repaired or re-provisioned on Apple’s side? We can provide reproduction timestamps, Archive entitlement dumps, provisioning profile details, screenshots, and additional diagnostic logs if needed. Thank you.

Hi all, I tried to implement Apple Login in my Expo App for iOS (as I also want to use Google login and Apple makes Apple login mandatory in this case). But I always get an error when I try to sign in. Problem Sign in with Apple never completes. The system sheet appears, the user taps "Continue", then the sheet shows "Sign up not completed" and the API returns: ASAuthorizationError with message "The user canceled the authorization attempt" (no error code is provided; the error object is otherwise empty) This happens on every attempt, with no user cancellation involved. What I have already verified App ID capability: APPLE_ID_AUTH is enabled with setting APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (verified via App Store Connect API and visible as enabled in the Developer Portal UI). Provisioning profile: freshly generated AFTER enabling the capability. Decoded profile contains: com.apple.developer.applesigninDefault Signed binary: I downloaded the built IPA and inspected it. codesign -d --entitlements shows: com.apple.developer.applesignin = ["Default"] The embedded.mobileprovision inside the IPA is the newly generated one. No app extensions: the IPA contains no PlugIns directory, so there is no bundled extension missing the entitlement. Not account-specific: reproduced with two different Apple IDs (both with two-factor authentication enabled). Not bundle-ID or distribution-specific: reproduced with both com.enplace.app.dev (Ad Hoc) and com.enplace.recipes (App Store build distributed via TestFlight). No stale authorization: Settings > Apple Account > Sign in with Apple lists no entry for this app. Agreements: "Free Apps" agreement is active. Expected signInAsync() returns a credential with an identityToken. Actual Promise rejects with "The user canceled the authorization attempt" without any user cancellation, on every attempt, on all tested configurations. Environment Device: iPhone SE (Touch ID), iOS 26.5.2 Framework: React Native / Expo SDK 56 with expo-apple-authentication (wraps ASAuthorizationController; no custom native code involved) The app bundles no app extensions Capability was enabled on 2026-07-28; still failing on 2026-07-29 Has anyone found the actual cause for this? Several older threads describe the same symptom, but none of them ends with a resolution.

Our app can no longer complete native Sign in with Apple: the system sheet appears, the user authenticates (Face ID / password succeeds), and the sheet then fails before any credential is returned to the app. Console shows AKAuthenticationError -7003 from the AppleAccount/AuthorizationServices stack. Details: App: "Antes y Después: Fotos" — bundle ID com.jpbaldi.antesydespues, live on the App Store Team ID: PZDWZHXF9V (individual membership) Implementation: ASAuthorizationController (via expo-apple-authentication), scopes full name + email; the identityToken is exchanged with our backend (Supabase). The failure happens inside the native sheet, before any token is issued. Reproducible across devices, networks and Apple IDs — and App Review reproduced it too: our build was rejected under 2.1(a) because the reviewer hit the same failure. It does not look device- or account-specific. What we've already tried, with no change: Removed and re-added the Sign in with Apple capability on the App ID in Certificates, Identifiers & Profiles, regenerated provisioning profiles, rebuilt and resubmitted. Verified com.apple.developer.applesignin (Default) is present in the shipped binary's entitlements. Fresh devices, different Apple IDs, different networks. As a workaround we shipped v1.0 with Sign in with Apple disabled (email/password only), so guideline 4.8 doesn't apply — but we want to restore it. Since -7003 appears to be returned server-side for our client ID rather than by anything in the app, is there any account-side registration state for the App ID that can be checked or reset? Has anyone resolved this exact error without creating a new App ID (not viable for a shipped app)? Feedback Assistant: FB23890204 (sysdiagnose + screen recording attached) Developer Support case ref: 102944296016

App: Subio - Quản lý đăng ký Bundle ID: io.ausynclab.subio Team ID: DMB7A87LM9 App Store Connect App ID: 6785710632 SUMMARY Sign in with Apple in our app consistently fails during the account-creation flow with the system error "Sign-Up Not Completed" (shown by iOS's own native AuthenticationServices UI, before any of our app code runs). This has caused App Review to reject our app 5+ times over the past week (builds 16, 17, 19, 20, 21, 22), each citing Guideline 2.1(a) with this exact error. KEY EVIDENCE THIS IS SERVER-SIDE, NOT APP-SIDE The failure reproduces for TWO COMPLETELY INDEPENDENT Apple ID accounts: Our own developer test account (used repeatedly since build 16) Apple App Review's own test account/device (different devices each time: iPad Air 11" M3, iPad Air 11" M4, iPhone 17 Pro Max — running iPadOS 26.5.2 and iOS 27.0) Two unrelated accounts hitting the identical failure strongly suggests the issue is in our app's Sign-In-With-Apple server-side registration (tied to our Team ID/Bundle ID), not any individual user's account state. Our backend receives ZERO HTTP requests at the moment of failure, confirmed via server-side logging. This proves the failure occurs entirely within iOS's native account-creation sheet, before our JavaScript code (or the identityToken) is ever produced. TROUBLESHOOTING ALREADY COMPLETED (to save engineering time) We have verified all of the following are correctly configured, and the issue persists regardless: Bundle ID capability: APPLE_ID_AUTH is enabled with APPLE_ID_AUTH_APP_CONSENT = PRIMARY_APP_CONSENT (confirmed via App Store Connect API) Provisioning profile: App Store distribution type, contains com.apple.developer.applesignin entitlement (Default), correct Team ID Signing certificate: valid iOS Distribution cert, serial number matches the certificate linked to the provisioning profile in App Store Connect Entitlements embedded in the actual signed, submitted binary (extracted directly from the .ipa and inspected with codesign -d --entitlements) match expectations exactly Tried requesting full scopes (FULL_NAME + EMAIL), reduced scopes (FULL_NAME only), and zero scopes at all (requestedScopes: []) — the failure is identical in all three configurations Added a guard to prevent concurrent/duplicate calls to signInAsync() (in case of rapid double-taps) — failure persists Confirmed the failure occurs both when the button is presented inside a React Native Modal and when presented on a plain (non-modal) screen — ruling out a presentation-context conflict WHAT WE'D LIKE APPLE'S HELP WITH Please check, on your side, whether there is a stuck, incomplete, or corrupted Sign-In-With-Apple account-linking record associated with Bundle ID io.ausynclab.subio / Team ID DMB7A87LM9 that could be causing account-creation requests to fail at the server level. We are happy to provide additional logs, device details, or a screen recording if useful. We would greatly appreciate guidance, as this is blocking our very first App Store submission and we've been unable to identify anything further to fix from the client side. Thank you for your time.

Sign in with Apple consistently fails with the sheet error "Sign up not completed" for every user and device we have tested. The authorization sheet presents correctly (name/email choices are shown); the failure happens on completion, so no credential is returned to the app. We have eliminated all client-side and account-side causes and believe this is a server-side registration issue with our App ID, matching previously reported cases that were ultimately fixed on Apple's side (forums threads 716252, 122458, 750633). App details: Team ID: Q7BH7CYU67 Client ID (Bundle ID): com.hohomom.baby (App ID resource id RN35DS29UD) Native flow: ASAuthorizationController identity token verified via Firebase signInWithCredential; audience = the bundle ID (no web Services ID involved) Distribution: TestFlight (external), build 1.0 (1784386654) Feedback Assistant report (with sysdiagnose + akd log): FB23839922 Developer Support case: 102946147992 What we verified (all pass): Delivered IPA binary entitlements: com.apple.developer.applesignin = [Default] (via codesign -d --entitlements). Embedded provisioning profile carries the same entitlement (via security cms -D). Signed with a fresh App Store profile created after a capability reset. Developer portal: App ID has APPLE_ID_AUTH enabled as primary (APPLE_ID_AUTH_APP_CONSENT: PRIMARY_APP_CONSENT). We also disabled/re-enabled the capability and rebuilt — no change. Every embedded target now has the entitlement too — we found and fixed a bundled Controls app-extension (com.hohomom.baby.Controls) that was missing the Sign in with Apple entitlement, added it, rebuilt and re-uploaded. Still fails. App Store Connect: no pending agreements. Apple System Status: Sign in with Apple operational at test time. The tester's Apple ID and device are fine: Sign in with Apple works in third-party apps from other teams on the same device. Device-side: rebooted the iPhone and retried on both Wi-Fi and LTE — same failure. Device log evidence (log collect during a failed attempt): at the moment of the attempt, a freshly spawned akd repeatedly fails to fetch the GrandSlam configuration: akd [com.apple.authkit:core] Bag fetch failed! Error Domain=NSURLErrorDomain Code=-1008 URL: https://gsa.apple.com/grandslam/GsService2/lookup/v2 (x4 consecutive) Could an Apple engineer please check the server-side Sign in with Apple registration state for Team Q7BH7CYU67 / com.hohomom.baby and repair or re-provision it? Full details, the affected Apple ID email, and a sysdiagnose are in FB23839922. This is currently blocking our App Store submission (guideline 4.8). Thank you.

Native Sign in with Apple fails with "Sign Up Not Completed" inside the AuthenticationServices sheet for every NEWLY registered App ID on our team (V4DCPCSM54) — including a clean-room probe App ID created via the ASC API with the capability enabled at creation — while an App ID registered in 2025 on the same team works. Entitlements, profiles, and capability config are all verified correct; capability toggle and fresh builds change nothing. This matches the server-side registration issue described in thread 790827. Filed as FB[23726069] with full details. Would appreciate DTS taking a look — this is currently blocking our App Store review (rejected 2.1(a)).

Hi all, I just enabled Sign in with Apple for my app for the first time. The app is built with FlutterFlow using its native Authenticate with Apple action. When I tap Sign in with Apple, nothing happens: the Apple authorization sheet never appears. To investigate further, I created a custom action that directly calls: SignInWithApple.getAppleIDCredential(...) and catches any exception. It consistently returns: SignInWithAppleAuthorizationException( AuthorizationErrorCode.unknown, The operation couldn't be completed. (Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1000) ) The app is distributed through TestFlight and the issue occurs on a real device. I'm wondering whether anyone has experienced the same behavior after enabling Sign in with Apple on a new App ID. If so: Did the issue resolve itself after some time? Was there any Apple-side propagation delay involved? Or was there an additional FlutterFlow or Apple Developer configuration that I might be missing? What I've already verified ✅ Sign in with Apple capability is enabled on the App ID. ✅ Distribution certificate is valid. ✅ Provisioning profile was regenerated after enabling the capability and lists Sign in with Apple under Enabled Capabilities. ✅ Firebase Authentication has the Apple provider enabled. ✅ Google Sign-In works correctly in the same TestFlight build. ✅ Tested only on a physical device via TestFlight. ✅ Rebuilt and redeployed the app from FlutterFlow after every configuration change. ✅ Disabled Firebase App Check enforcement for Authentication as a test (no change). Any suggestions or similar experiences would be greatly appreciated.

On a physical device, the native Sign in with Apple sheet fails INSTANTLY with ASAuthorizationError.unknown (code 1000) — before any Apple account UI appears. It fails for every Apple ID we try. The app shows "Sign Up Not Completed". App ID: brp.sohsostory.app · Team: JZZUYHU3UU (a newly enrolled account) Already verified (config looks fully correct): "Sign in with Apple" capability is ENABLED on the App ID (Primary App consent), confirmed in both the Developer portal and via the App Store Connect API. The active distribution provisioning profile includes com.apple.developer.applesignin, and the built binary carries the entitlement. Program License Agreement is accepted. The SAME client code + backend works on a DIFFERENT (older) team's app, so this looks specific to this App ID / team — as if a server-side activation for a new team never completed. Questions: For a newly enrolled team, is there a known activation delay before Sign in with Apple starts working, and how long? Is there any additional step required to "activate" the capability beyond enabling it on the App ID and regenerating the profile? Has anyone resolved ASAuthorizationError.unknown that persisted for days on a new team? Environment: iOS (physical device), React Native / Expo, backend uses Apple as an OpenID provider (Supabase Auth).

I’m experiencing the same “Sign Up Not Completed” issue with native Sign in with Apple. The authorization logs report “No applications were found with the provided Client ID” and “Invalid client”, although the App ID capability, provisioning profile, and signed application entitlement appear to be configured correctly. I submitted the requested information and sysdiagnose through Feedback Assistant. Feedback ID: FB23819378

@Paris X Pinkney — Looking for help with a team-scoped SIWA failure. Feedback ID: FB23839261 Bundle ID: com.yyssd Team ID: U3KSLBV22Q iOS: 26.5.2 (23F84) production Device: iPhone 13 (iPhone14,5) Failure window: 2026-07-19 14:51:28 – 14:51:40 +0800 (Beijing time) Symptom SIWA fails immediately after Face ID succeeds. The app sees ASAuthorizationError Code=1001. The system alert says "Sign-Up Not Completed". The same Apple ID on the same device works fine for SIWA in other teams' apps (e.g. Notion). akd failure chain (from sysdiagnose with AuthKit profile) [authkit:siwa] Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 [authkit:siwa] No applications were found with the provided Client ID [authkit:siwa] Using personal credential state - 2, error - AKAuthenticationError Code=-7074 [authkit:core] Performing SRP request with context [AppleIDAuthSupport] setError: 2:M2 missing (bad password) [authkit:core] SRP authentication with server failed! [authkit:siwa] Error performing auth request: AKAuthenticationError Code=-7003 This is identical to the failure signature reported in thread 838075. What we've verified App Store Connect API: SIWA capability (APPLE_ID_AUTH + PRIMARY_APP_CONSENT) is enabled on the App ID Tried deleting & recreating the capability via API — same failure com.apple.developer.applesignin is in entitlements AND embedded provisioning profile (verified via security cms -D) Same failure on two different Apple IDs Tried deleting app + Reset Location & Privacy — same failure Removed SIWA from sibling App ID com.yyssd.game to eliminate prefix conflict — same failure iOS is production 26.5.2, not beta Notion (different team) works fine on same device with same Apple ID Diagnosis The AKSQLError -6003 "No applications were found with the provided Client ID" line strongly suggests that Apple's SIWA backend does not recognize com.yyssd as having SIWA enabled, even though App Store Connect API says otherwise. The two databases are out of sync. The subsequent setError: 2:M2 missing (bad password) is a phantom error — the SRP handshake fails because the backend can't find a valid credential state for (Apple ID, com.yyssd), not because the password is wrong. Ask Could DTS confirm whether the team-scoped SIWA provisioning state for Team U3KSLBV22Q can be re-initialized server-side? Happy to share the full sysdiagnose logarchive (already attached to FB23839261). Sysdiagnose: sysdiagnose_2026.07.19_15-32-28+0800_iPhone-OS_iPhone_23F84_2CBB9352-E02D-547E-9213-5C5C7514A41F.tar.gz Many thanks.

Hello, our Sign in with Apple Button no longer works and throws an 7003 error. It worked a few days ago but suddenly fails. Any ideas how to fix this? Thanks in advance! plist: <dict> <key>com.apple.developer.applesignin</key> <array> <string>Default</string> </array> ... Code: var body: some View { VStack { SignInWithAppleButton(.signUp) { request in request.requestedScopes = [.fullName, .email] } onCompletion: { result in switch result { case .success(let authResults): handleSuccess(authorization: authResults) case .failure(let error): self.credentialFailure = true self.errorMessage = .appleSignInError logger.error("SIWA login failure: \(error)") } } .signInWithAppleButtonStyle(.white) .cornerRadius(GlobalValues.cornerRadius) } } Error: Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.our.app} ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)" SIWA login failure: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)"

Sign in with Apple fails with the system alert "Sign-Up not completed" for every app belonging to our developer team, on every device we tested. The app itself only receives ASAuthorizationError code 1001 with an empty userInfo dictionary, so there is nothing actionable on the client side. We have systematically ruled out every configuration cause we could think of: Sign in with Apple capability is enabled on each App ID, set as primary (verified via the App Store Connect API) com.apple.developer.applesignin entitlement is present in the signed binaries and in the provisioning profiles (verified with codesign and security cms) Two-factor authentication is active on the test Apple ID No pending agreements (Paid Apps accepted; one of our apps is live on the App Store) Reproduction matrix — ALL of these combinations fail identically: Devices: two different physical devices (iPhone, iPad) Signing: development-signed AND TestFlight (App Store distribution) builds Network: Wi-Fi AND cellular App IDs: existing ones (capability enabled more than 48 hours ago) AND a minimal reproduction app whose App ID + capability were created minutes before the test Control test that WORKS: on the same devices, with the same Apple ID, a brand-new Sign in with Apple sign-up in App Store apps from other teams completes without any issue. The failure is therefore strictly scoped to apps of our team. The device log (log collect) shows the following akd sequence at the moment of every attempt: akd: [com.apple.authkit:siwa] Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 akd: [com.apple.aaafoundation:log] Error fetching keychain items - NSOSStatusErrorDomain Code=-25300 "no matching items found" akd: [com.apple.authkit:siwa] Using personal credential state - 2, error - AKAuthenticationError Code=-7074 akd: [com.apple.AppleIDAuthSupport:general] AppleIDAuthSupport: setError: 2:M2 missing (bad password) akd: [com.apple.authkit:core] SRP authentication with server failed! (com.apple.AppleIDAuthSupport Code=2) akd: [com.apple.authkit:siwa] Error performing auth request: AKAuthenticationError Code=-7003 Given that a freshly created App ID reproduces the failure immediately while other teams' apps work on the same devices with the same Apple ID, this looks like a broken server-side Sign in with Apple provisioning/registration state for our team rather than anything we can fix ourselves. Has anyone seen this resolved? Is there anything on the account/team level that can get a team's Sign in with Apple provisioning re-initialized? Happy to share the Team ID and full .logarchive with Apple folks via DTS/support.

Whenever I go to sign in with Apple on my new app, I press Continue and it takes my Face ID, but it says 'Sign in not completed' right after and there is no debug details at all. How can I debug this? My Apple Account has 2FA, terms accepted, I have selected Sign in with Apple in the App ID Configuration, I don't know what the issue is.

Summary: invalid_client on a Services ID whose portal configuration is complete and correct, AND the same team's native App ID cannot be revoked from the iOS Settings UI ("Stop authorisation has failed - Invalid client"). Both started on 17 July 2026. Sign in with Apple on this App ID worked normally earlier the same day. Team ID: 8ASV5HF9RR Primary App ID: co.uk.2point45.calendarapp Services ID: co.uk.2point45.web Issue 1 (web): a request to the authorize endpoint with client_id set to the Services ID and redirect_uri set to a registered Return URL returns invalid_client. This reproduces with plain curl - no browser, no JS SDK, no popup, no scope, no nonce. The minimal request (response_type=code, response_mode=query) fails identically, so no application code is involved. Issue 2 (native): Settings > Apple Account > Sign in with Apple > [the app] > Stop using Apple ID returns "Stop authorisation has failed - Invalid client". This is the Settings app failing against the Sign in with Apple backend for the native App ID, with no third-party code in the path. sysdiagnose attached to the Feedback, captured with the Accounts/AuthKit profile installed. Already verified, so please don't return these as the cause: App ID has Sign in with Apple enabled and is set to "Enable as a primary App ID" Services ID has Sign in with Apple enabled, grouped to that primary App ID, with 6 Website URLs attached client_id is the Services ID, not the App ID redirect_uri is a character-for-character match of a registered Return URL Domains registered without a scheme; Return URLs registered with https TLS 1.2+ on all domains No domain association file uploaded, per the documentation ("You don't need to upload a file on your server to complete the registration process for domains and subdomains") Not applicable: no client secret JWT, refresh token or access token can be supplied, because this integration never calls the token endpoint. It uses Sign in with Apple JS with response_type=code id_token and verifies the returned id_token against the published JWKS. The failure is at the authorize endpoint, before any token exchange. The only portal changes between working and failing were: (1) creating the Services ID and selecting the App ID above as its Primary App ID, and (2) renaming the App ID's Description from the Xcode-generated default. No capabilities were changed.