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.

Sign in with Apple works correctly on a physical iPhone in my Capacitor-based app, but fails in the Simulator, and this appears to be causing repeated App Store review rejections. I'm trying to figure out how to get past review.... What happens On a physical iPhone, Sign in with Apple works as expected. In the Simulator, if the user signs into their Apple ID (Settings) and returns to the app, tapping "Sign up with Apple" fails immediately with: The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError error 1000.) (Screenshot attached.) The native Apple sheet never appears — the error returns right away. The actual problem Every time I submit to App Store review, the app gets rejected because Sign in with Apple fails for the reviewer — I believe they're testing in an environment (Simulator, or a device not signed into iCloud) where it returns error 1000. It works on real hardware, so I keep getting stuck in a review loop over something I can't reproduce on device. What I've already checked Sign In with Apple capability is present in Signing & Capabilities for both Debug and Release, and the entitlement is in the built product. The App ID has Sign In with Apple enabled in the Developer portal, and the Services ID / return URLs are configured for Clerk. Resolved an earlier iPad-specific issue where connectedScenes was empty (added a UIApplicationSceneManifest + AppDelegate.window fallback), so ASAuthorizationController now has a valid presentation anchor. Questions Is error 1000 (ASAuthorizationError.unknown) in the Simulator a known environment issue (e.g. no usable Apple ID for the authorization flow) rather than an app bug — given it works on physical devices? For anyone who has been rejected because Sign in with Apple failed in the reviewer's environment: what actually got you through review? Reviewer notes explaining it works on device? Replying in Resolution Center with a screen recording from a real device? Something else? Any guidance appreciated — I'd rather fix the root cause than keep resubmitting.

Sign in with Apple (web flow) fails 100% reproducibly at the token exchange for our newly created identifiers. POST to https://appleid.apple.com/auth/token with a REAL authorization code → 400 {"error":"invalid_client"}. The exact same client_id + client_secret from the same production server with a dummy code → {"error":"invalid_grant"} — i.e. client authentication passes and only the code is rejected, as expected. 16/16 probe requests across both registered redirect_uris. The authorization phase succeeds (user completes the appleid.apple.com sheet; code arrives via form_post to the registered return URL) and the exchange happens within ~1 second, so code expiry is not the cause. client_secret is an ES256 JWT with correct iss/sub/aud, validity ~6 months, sent via client_secret_post with no Authorization header. I have reviewed TN3107 — none of the documented invalid_client causes fit, given the invalid_grant asymmetry above. Persisted 24+ hours and survived: recreating the Services ID under a new identifier with a freshly minted secret; toggling the Sign in with Apple capability off/on (as primary) on the App ID; re-saving the Services ID configuration (domains and both return URLs re-confirmed). Team ID: CGSLWL988T Primary App ID: app.bookagym (created 2026-07-10) Services ID: app.bookagym.signin (an earlier Services ID app.bookagym.web behaved identically) Key ID: C99J756C86 This looks like stuck or unpropagated server-side provisioning for these identifiers rather than a client-side error. Per the "Gathering required information for troubleshooting Sign in with Apple authorization and token requests" post, I have filed the full details (including the failing request with all parameter values and a long-lived client secret) in Feedback Assistant: FB23692739

I'm building an iOS app using Capacitor with a Next.js 14 backend. Authentication currently uses: NextAuth Prisma Sign in with Apple Google Sign-In Magic Link The web version works correctly. For the native iOS app, tapping Continue with Apple currently opens the NextAuth endpoint (/api/auth/signin/apple), which launches the web authentication flow. App Review rejected the app because the Sign in with Apple flow leaves the native experience and opens a web view/browser during sign in. My goal is to keep Sign in with Apple fully native while continuing to use the same Prisma user database and authentication system used by the web application. What is Apple's recommended architecture for this scenario? Should I: Perform native Sign in with Apple in the Capacitor app. Send the returned identity token to my backend. Verify the token server-side. Create my own authenticated session instead of using the NextAuth Apple provider. Or is there another approach Apple recommends for hybrid apps using Capacitor? Any guidance would be greatly appreciated.

Apple Developer Support Request - Sign in with Apple Failure Date prepared: 2026-07-08 App name: LingJing / XiaoLing Bundle ID: com.jachymchen.xiaoling Apple Developer Team ID: 765B64SW9Z Platform: iOS Summary Sign in with Apple fails before the app receives a usable Apple identity token. The user-facing Apple system sheet ends with the Chinese alert "未完成注册" ("Sign Up Not Completed"). The app callback does not receive an identityToken, so our backend auth provider is not reached successfully. We reproduced the same failure in a minimal native Swift app that only uses AuthenticationServices and the same Bundle ID / provisioning profile, without Supabase or any app-specific backend code. This suggests the failure is likely in the Apple Sign in with Apple authorization flow, account/device state, or App ID/provisioning configuration recognized by Apple's auth services, rather than in our app's backend implementation. Environment Mac: macOS 26.5 Apple Silicon MacBook Pro Xcode 26.5 iPhone: Real device connected over USB Device name: 硬糖的iPhone iOS 26.5.1 Device UDID: 00008150-000344540C99401C App: Bundle ID: com.jachymchen.xiaoling App version currently used for testing: 0.1.0 App Store Connect app ID observed during TestFlight work: 6784075688 TestFlight build upload previously succeeded for version 0.1.0 build 2 Provisioning / Entitlements Checked Development provisioning profile: Profile name: XiaoLing Dev application-identifier: 765B64SW9Z.com.jachymchen.xiaoling com.apple.developer.applesignin: [Default] com.apple.developer.team-identifier: 765B64SW9Z get-task-allow: true keychain-access-groups includes: 765B64SW9Z.* com.apple.token Profile includes the test device UDID: 00008150-000344540C99401C Expiration: 2027-06-27 Distribution / TestFlight provisioning profile: Profile name: XiaoLing AppStore application-identifier: 765B64SW9Z.com.jachymchen.xiaoling com.apple.developer.applesignin: [Default] beta-reports-active: true get-task-allow: false Signed app entitlements were checked from the executable and matched the expected Bundle ID / Team ID / Sign in with Apple entitlement. Important note: Running codesign -d --entitlements :- XiaoLing.app against the .app bundle may print an "invalid entitlements blob" style result. Running codesign against the actual executable inside the .app is the useful check, and that showed the expected entitlements. Reproduction Steps Install and launch the iOS app with Bundle ID com.jachymchen.xiaoling on the real iPhone. Tap "Sign in with Apple". Complete the Apple ID system prompt. The Apple system flow fails and shows "未完成注册". The app does not receive a valid ASAuthorizationAppleIDCredential identity token. Observed Result The Apple authorization flow fails before returning a usable credential to the app. The system UI shows "未完成注册" ("Sign Up Not Completed"). Expected Result AuthenticationServices should return an ASAuthorizationAppleIDCredential with an identityToken so the app can continue its own backend sign-in. Key Device Logs Observed During real-device attempts, the following log lines appeared around the failure: AuthKit continuation-key-creation token is missing AppleIDAuthSupport: setError: 2:M2 missing (bad password) SRP authentication with server failed AUTH_ALERT_SIGN_UP_NOT_COMPLETED -> 未完成注册 AKRemoteViewController did complete with authorization (null) AKAuthenticationServerError Code=-24000 The private framework error code by itself is not enough to identify the root cause, but the flow consistently fails inside Apple's AuthKit / Apple ID authorization path before our app receives an identity token. Minimal Native Demo Test To exclude app-specific implementation and backend issues, we created a minimal native SwiftUI app using only: AuthenticationServices SignInWithAppleButton ASAuthorizationAppleIDProvider The same Bundle ID: com.jachymchen.xiaoling The same Team ID / provisioning entitlement setup No Supabase No custom backend No React Native No third-party auth library The minimal native demo produced the same user-facing failure: "未完成注册". This strongly suggests the issue is not caused by Supabase, nonce hashing, OAuth handling, React Native, or our app UI. The failure happens before any backend auth exchange can occur. Additional Context The tester tried another Apple ID and still reproduced the failure. The tester stated the Apple ID itself is otherwise usable. The app's Bundle ID is intended to be exactly: com.jachymchen.xiaoling We specifically checked for provisioning profile / Bundle ID mismatch and did not find a mismatch in the installed build. Questions for Apple Developer Support Can Apple check whether App ID 765B64SW9Z.com.jachymchen.xiaoling has any server-side Sign in with Apple configuration issue? Can Apple explain what conditions produce: AUTH_ALERT_SIGN_UP_NOT_COMPLETED AKAuthenticationServerError Code=-24000 "M2 missing (bad password)" "AuthKit continuation-key-creation token is missing" in a native AuthenticationServices Sign in with Apple flow? Is there any known issue on iOS 26.5.1 or with development-signed apps where Sign in with Apple fails before returning an ASAuthorizationAppleIDCredential? Are there account-level or device-level requirements beyond normal Apple ID login that can cause Sign in with Apple to show "Sign Up Not Completed"? Can Apple verify whether this Bundle ID / Team ID is correctly enabled for Sign in with Apple on Apple's backend? Minimal Code Shape Used for Native Demo The native demo used a standard SignInWithAppleButton: SignInWithAppleButton(.signIn) { request in request.requestedScopes = [.fullName, .email] } onCompletion: { result in switch result { case .success(let authorization): // Check authorization.credential as ASAuthorizationAppleIDCredential // and read identityToken. case .failure(let error): // Log NSError domain, code, localizedDescription, and userInfo. } } Support Request Please help determine why Apple's Sign in with Apple authorization flow fails for Bundle ID com.jachymchen.xiaoling before returning a credential, despite the app having the Sign in with Apple entitlement and matching provisioning profile / Bundle ID.

Subject: Sign In with Apple consistently fails with AuthorizationError 1000 (empty userInfo) immediately after successful biometric authentication — native delegate logging confirms failure occurs before authorization is returned to app App ID: com.andresalecina.vant
Team ID: C6GK7Z5GY2
Services ID: com.andresalecina.vant.signin Summary:
Sign In with Apple fails 100% of the time in our native iOS app (Capacitor 7 wrapper) with error code 1000 and completely empty userInfo. The native authentication sheet displays correctly and the user completes Face ID successfully, but authentication fails immediately afterward. Critical new evidence (delegate-level logging):
We instrumented both ASAuthorizationControllerDelegate callback methods directly with NSLog to determine exactly where the failure occurs: authorizationController(controller:didCompleteWithAuthorization:) — never fires. Confirmed across multiple fresh test attempts. authorizationController(controller:didCompleteWithError:) — fires every time, receiving: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1000 "(null)" with completely empty userInfo. This confirms the failure originates inside AuthenticationServices itself, before any authorization object is ever returned to our app. Our app code is not receiving a token, credential, or authorization of any kind to process — there is nothing for our code to mishandle. Everything already verified clean on our end: Sign In with Apple capability present in Xcode target and confirmed in Apple Developer Portal (Primary App ID, not grouped) Entitlement com.apple.developer.applesignin confirmed present in both the development-signed binary and the App Store distribution provisioning profile Team ID in the compiled binary matches the entitlement (verified via codesign -dv and codesign -d --entitlements) Provisioning profile freshly regenerated after capability was added Apple Developer Program License Agreement and Developer Agreement both fully accepted, no pending items Reproduces identically on two separate physical devices (one iOS 27 beta, one non-beta), on both WiFi and cellular Reproduces with a completely clean Apple ID test account (no prior Family Sharing/managed account involvement, confirmed adult standard account) Device clock, timezone, and Screen Time/Content & Privacy Restrictions confirmed not a factor Native plugin code reviewed line-by-line: uses stock ASAuthorizationAppleIDProvider().createRequest(), standard .fullName/.email scopes only, robust presentation anchor resolution (no detached/fake UIWindow) Timeline:
The Sign In with Apple capability was added to this App ID within the past 24–48 hours (it was missing entirely on our initial rejected App Store submission). Error 1000 has persisted consistently across many rebuilds since the capability was added, which raises the possibility of a propagation delay on Apple's authentication backend, but this has now exceeded typical propagation windows for other capabilities we've observed (Push Notifications, Associated Domains). What we're asking:
Can you verify, on Apple's side, whether App ID com.andresalecina.vant under Team C6GK7Z5GY2 is fully provisioned and active on Apple's Sign In with Apple authentication backend? All client-side, code-side, and account-side factors we can verify are confirmed correct; the delegate-level logging above confirms the failure is occurring before any authorization is returned to the client, which points to a state on Apple's servers that isn't visible to us through the standard Developer Portal UI. Happy to provide device sysdiagnose logs, the full Xcode archive, or a minimal reproduction project (bare SwiftUI, no Capacitor/Supabase) if useful.

I'm implementing Sign in with Apple for a web-only service (Services ID associated with a primary App ID, plus a private key for the client secret JWT). Before I finalize the setup I want to confirm one prerequisite, because two of Apple's own pages give different answers. "Configuring your environment for Sign in with Apple" states that to authenticate users with a web service you must have an existing app in the App Store that uses Sign in with Apple: https://developer.apple.com/documentation/signinwithapple/configuring-your-environment-for-sign-in-with-apple "Configure Sign in with Apple for the web" (Account Help) only says to associate your website with an existing primary App ID enabled for Sign in with Apple — i.e., just a registered identifier, with no mention of a published app: https://developer.apple.com/help/account/capabilities/configure-sign-in-with-apple-for-the-web/ My question: for a web-only service, is a published (or in-review) App Store app actually required, or is a registered App ID identifier with the Sign in with Apple capability enabled sufficient on its own? And if a published app isn't required, is the "existing app in the App Store" wording just meant to describe the App ID rather than a live listing? I've contacted Developer Support and was pointed back to the general docs, which are the source of the contradiction rather than the answer, so I'm hoping an engineer or someone who has shipped a web-only setup can confirm which prerequisite governs. Thanks in advance.

Hello, We recently transferred our iOS app to a different Apple Developer team. App Store URL: https://apps.apple.com/kr/app/id6759354260 Bundle ID: com.kimchisushi.app Our app uses Sign in with Apple. In our legacy implementation, some existing Apple login users were stored in our backend by email only. For those users, we did not store the original team-scoped Apple user identifier (sub). The app transfer has already been completed, and we are currently within the 60-day migration window. For many users, the migration path is clear: If we have the old team-scoped sub, we can generate or exchange the transfer identifier according to Apple’s migration documentation. If a user signs in after the transfer and the identity token contains transfer_sub, we may be able to use that claim to complete the migration. However, our difficult case is this: Some legacy users used Sign in with Apple with Hide My Email / Private Relay. For those users, we only have the old private relay email address in our database. We do not have their old team-scoped sub. Questions: If we do not have the old team-scoped sub, is there any Apple-supported way to recover or map those legacy users using the old private relay email address? During the 60-day migration window, if one of these users signs in again after the app transfer, will the identity token include transfer_sub even if we did not generate a transfer identifier for that user before the transfer? If the identity token includes transfer_sub, is there any Apple-supported way to correlate that transfer_sub back to the user’s old private relay email address or old app account when the old sub was never stored? If the answer is no, is the recommended recovery path to implement our own account recovery / account relinking flow for these users? We understand that the Apple user identifier (sub) should have been stored as the stable identifier, and that email should not be treated as stable. We are trying to confirm whether there is any official recovery path for the subset of legacy users where the old sub was not stored before the app transfer. Thank you.

I’m trying to understand the recommended configuration for Sign in with Apple across two separate iOS apps and one website/Services ID under the same Apple Developer team. Goal: A user signs in with Apple in either iOS app or on the website, and our backend can recognize it as the same Apple identity/account, including when the user chooses Hide My Email. Current question: Should both iOS App IDs be configured as separate primary App IDs, or should one be primary and the other grouped with it? The website uses a Services ID associated with the primary App ID. I'm seeing behavior where the user can get a “create/sign in” style prompt in both iOS apps, and we want to avoid accidentally creating separate backend accounts if Apple returns different sub values for each app/client. What is the correct Apple Developer configuration if I need a stable backend identity across: iOS app A (existing, existing users) iOS app B (new, no existing users) web Services ID (new, no existing users) [preferred go forward "create account" service name if possible] Should our backend expect the sub claim in the Apple identity token to be identical across those clients when they are grouped, or should I treat each App ID/Services ID as potentially returning a different sub and link accounts another way? Current configuration and observed behavior: The web Services ID and iOS App B are currently grouped under iOS App A as the primary App ID for Sign in with Apple. This mostly works: when users sign in through App B, they appear to be associated with the same Apple credential/account, and no additional Sign in with Apple entry appears in the Passwords app. However, App B still presents the “create a login” flow and asks the user to choose/share their name and email again. The system prompt also shows App B’s display name, not the web Services ID name or App A’s primary App ID name. This could confuse users into thinking they are creating a separate App B account rather than signing into the same account used by App A and the website. Because of that, users may choose a different name/email option, including a different Hide My Email choice, which could lead our backend to treat the sign-in as a separate account if the Apple identity token differs by client configuration. I'm trying to confirm whether this prompt/UI behavior is expected for a grouped App ID, and whether the Apple identity token’s sub claim should remain stable across App A, App B, and the associated web Services ID.

I'm developing a Unity iOS app using the official "Sign In with Apple" Unity plugin (v1.5.0), and I'm encountering persistent errors during authentication. Here’s the full context: App Info: Unity version: 6000.0.32f1 Bundle ID: com.pfcgaming.applesignin Sign In with Apple enabled in the Apple Developer portal Real iOS device, not simulator Error Logs: txt Copy Edit Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.pfcgaming.applesignin} ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)" Description: The operation couldn’t be completed. No credentials available for login. What I’ve Done So Far: Verified "Sign In with Apple" is enabled under the App ID in developer.apple.com. Provisioning profile has been regenerated with correct entitlements. Xcode project has the “Sign In with Apple” capability added. Tested on multiple real iOS devices with iCloud + Keychain enabled. Tried both PerformQuickLogin() and LoginWithAppleId() approaches in the plugin. My Observations: These errors started occurring right after enabling "Sign In with Apple" in the developer portal. Based on some community feedback, there may be a backend propagation delay after enabling SIWA (Sign In With Apple) which might cause these errors. Questions: Is it expected to receive error -7003 or 1001 immediately after enabling SIWA in the Developer Portal? How long does it typically take for entitlement changes to fully propagate? Is there any Apple-recommended workaround to test during this wait time? Any insight or confirmation would be helpful. Thanks in advance!

Hey everyone, I'm hitting an absolute brick wall with Sign in with Apple on an Expo/React Native project distributed via TestFlight. The native API (isAvailableAsync() via expo-apple-authentication) is returning false globally across multiple physical devices, different user Apple IDs, and different network environments. We have completely ruled out a local code crash—the framework initializes, but the local iOS kernel is explicitly returning a hard false on the availability check before even attempting to present the modal sheet. Here is exactly what we have isolated and verified based on DTS documentation: Identifiers & App ID Setup: Team ID: NJ5JQ25956 (Luxor Interactive LLC) iOS Bundle Identifier: com.myoseph.carswipeapp App ID Capabilities: Checked and verified that "Sign in with Apple" is explicitly enabled on the Apple Developer Portal for this explicit bundle ID. Credentials & Provisioning Purge: We suspecting a cached provisioning profile or identifier cross-talk (our Android layout previously used a different package string, though we just unified it to com.myoseph.carswipeapp across the configuration scripts to rule out cryptographic hash collisions). We completely revoked and purged all old Distribution Certificates and App Store Provisioning Profiles from both the build engine cache and the Apple Developer Portal. Regenerated a completely fresh Distribution Certificate (Serial: 7383AE36E5D21E93F3F0B907D3A87DF3) and a brand-new, active Provisioning Profile (ID: L328ZDW2A4). Entitlements Inspection: Inspecting the compiled .ipa container structure shows the explicit com.apple.developer.applesignin entitlement key array is correctly present and injected. Despite having pristine, newly-minted cryptographic certificates tightly bound to a verified App ID, Build 62 on TestFlight still rejects the authentication framework instantly at the OS level. Is there a known propagation lag on Apple's identity database servers for newly updated Team ID capabilities, or is there an internal backend entitlement lock on our corporate Team ID container that isn't reflecting on the developer portal UI? Any insights or a sanity check from DTS would be an absolute lifesaver. Thanks in advance.

Hi! We're having issues with the sign in flow, starting today. As per the documentation, the issuer of the tokens should be https://appleid.apple.com sign in docs. But in the published configuration, it is now stated as https://account.apple.com metadata endpoint. Once the token is received through the sign in flow, the issuer is however still appleid.apple.com. This is causing problems for us where we expect the issuer in the metadata endpoint to be the same as the actual token issuer. What is correct here?

When use apple login, It always failed, other app developer by me is success, but the new app failed, the code is the same, it tips Sign up not Completed

I have been working on integrate sign in with apple. I failed for a while. So I download the demo app from this link: https://developer.apple.com/documentation/authenticationservices/implementing-user-authentication-with-sign-in-with-apple And change the bundle id and add it to my paid apple developer account team. Then run it and test it on my all device. It always failed with showing sign up not completed and the log like below: Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.shuaichang.testsignin} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} 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={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} 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)" authorizationController error: The operation couldn’t be completed. (com.apple.AuthenticationServices.AuthorizationError error 1001.)

I was experiencing a weird sign in error when using apple sign in with my app and wanted to put it here for anyone else who might experience it in the future, and so apple can make this requirement more clear. I was using CloudKit and apple sign in. If you are not using both this probably does not apply to you. Every time I would go to sign in in the iOS simulator I would enter my password, hit "sign in", and everything just froze. The very odd reason for this is if you are using iCloudKit and apple sign in you need to go to specifically the "identifiers" in the "Certificates, Identifiers & Profiles" menu (https://developer.apple.com/account/resources/identifiers/list). And from there you specifically need an App ID Configuration with apple sign in enabled. From there you have to have the same exact bundle identifier in Xcode under project settings(not an upper tab just click your project in the left panel). And that should allow you to both pass validation and have your sign in work. Hope this helps!

Hi Community, We've implemented Sign In with Apple in our application. Our domains are properly registered in the developer console, but we're experiencing inconsistent email functionality with Apple's privacy email service. Some domains work correctly while others show delivery problems, even though all domains have identical configurations. Apple's console displays green verification status for all domains, yet testing reveals that emails to privacy-protected accounts don't arrive as expected. We're using SendGrid as our email service provider, and all domains have valid authentication records (SPF, DKIM, DMARC) in place. Has anyone encountered similar inconsistencies with Apple's privacy email service? Would appreciate any configuration tips or troubleshooting guidance. Thanks.

I am having trouble with one of my apps that will not let me log in via Apple Sign In. I am using Firebase and Firebase UI for the sign in process. I have many other apps with the same exact config that currently work just fine, but this one I have gone as far as completely deleting the targets and rebuilding and it will not return from the login screen I checked the following: Sign in with Apple ID Capability is available in XCode and on the dev certificate on developer.apple.com I have also toggled both of them on and off. I have double checked the config in Firebase to turn on the Apple Login identifier. Again I have toggle it on and off. I have cleaned the project multiple times to no avail. I have logged out and back into my developer account in XCode. It seams like after I put in the correct password to log in, it just never returns to the app, there is no logging. I do get a notified(shaking input box) if I put in an incorrect password, but when I put in the correct one, the login window never dismisses and my app is not notified. I checked the Console and the last message from akd on a working app is: Notifying client (bundle) of credential state change 1. Remote view sent a finish event On the one not working, using the same user and password akd returns: SRP authentication with server failed! Error: Error Domain=com.apple.AppleIDAuthSupport Code=2 "M2 missing (bad password) I have 100% verified I am putting in the correct user password. I was only notified of this issue because Policy is having the same issue logging in during App Review. Also, if I put in a bad password the input window shakes and when this is happening, the input window is not shaking