Hi, Before I begin my investigation, I want to explain our code-level support process for issues related to Sign in with Apple—as the issue you’re reporting may be the result of any of the following: An error in your app or web service request. A configuration issue in your Developer Account. An internal issue in the operation system or Apple ID servers. To ensure the issue is not caused by an error within your app or web service request, please review TN3107: Resolving Sign in with Apple response errors to learn more about common error causes and potential solutions when performing requests. If the technote does not help identify the cause of the error, I need more information about your app or web services to get started. To prevent sending sensitive JSON Web Tokens (JWTs) in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback. Gathering required information for troubleshooting Sign in with Apple authorization and token requests For issues occurring with your native app, perform the following steps: Install the Accounts/AuthKit profile on your iOS, macOS, tvOS, watchOS, or visionOS device. Reproduce the issue and make a note of the timestamp when the issue occurred, while optionally capturing screenshots or video. Gather a sysdiagnose on the same iOS, macOS, tvOS, watchOS, or visionOS device. Create a report in Feedback Assistant, and ensure your feedback contains the following information: the primary App ID or Bundle ID the user’s Apple ID, email address, and/or identity token the sysdiagnose gathered after reproducing the issue the timestamp of when the issue was reproduced screenshots or videos of errors and unexpected behaviors (optional) For issues occurring with your web service, ensure your feedback contains the following information: the primary App ID and Services ID the user’s Apple ID, email address, and/or identity token the failing request, including all parameter values, and error responses (if applicable) the timestamp of when the issue was reproduced (optional) screenshots or videos of errors and unexpected behaviors (optional) Important: If providing a web service request, please ensure the client secret (JWT) has an extended expiration time (exp) of at least ten (10) business days, so I have enough time to diagnose the issue. Additionally, if your request requires access token or refresh tokens, please provide refresh tokens as they do not have a time-based expiration time; most access tokens have a maximum lifetime of one (1) hour, and will expire before I have a chance to look at the issue. Submitting your feedback Before you submit to Feedback Assistant, please confirm the requested information above (for your native app or web service) is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hi, Please see TN3159: Migrating Sign in with Apple users for an app transfer for more information on the expected end-to-end app transfer and user migration flow. Additionally, if you'd like for the iCloud and App Store engineering teams to confirm if the errors are related to a revoked authorization to previous users accounts, please submit a report via Feedback Assistant and include the following information: Gathering required information for troubleshooting Sign in with Apple user migration To prevent sending sensitive JSON Web Tokens (JWTs) in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback. For issues occurring with your user migration, ensure your feedback contains the following information: the primary App ID and Services ID the client secret for the transferring team (Team A) and the recipient team (Team B) the failing request(s), including all parameter values, and error responses (if applicable) the timestamp of when the issue was reproduced (optional) screenshots or videos of errors and unexpected behaviors (optional) Important: If providing a web service request, please ensure the client secret (JWT) has an extended expiration time (exp) of at least ten (10) business days, so I have enough time to diagnose the issue. Additionally, if your request requires access token or refresh tokens, please provide refresh tokens as they do not have a time-based expiration time; most access tokens have a maximum lifetime of one (1) hour, and will expire before I have a chance to look at the issue. Submitting your feedback Before you submit via Feedback Assistant, please confirm the requested information above (for your native app or web service) is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hi, Before I begin my investigation, I want to explain our code-level support process for issues related to Sign in with Apple—as the issue you’re reporting may be the result of any of the following: An error in your app or web service request. A configuration issue in your Developer Account. An internal issue in the operation system or Apple ID servers. To ensure the issue is not caused by an error within your Private Email Replay configuration, please review Configuring your environment for Sign in with Apple to learn more about registering your email sources and authenticated domains. To prevent sending sensitive message details in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback. Gathering required information for troubleshooting Private Email Relay with Sign in with Apple For issues occurring with your email delivery, ensure your feedback contains the following information: the primary App ID and Services ID the user’s Apple ID and/or email address the email message headers the Private Email Relay Service or Hide My Email message delivery failure, and SMTP error codes Submitting your feedback Before you submit to Feedback Assistant, please confirm the requested information above is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

The revoke tokens endpoint (/auth/revoke) is the only way to programmatically invalidate user tokens associated to your developer account without user interaction. This endpoint requires either a valid refresh token or access token for invalidation, as Sign in with Apple expects all apps to securely transmit and store these tokens for validation and user identity verification while managing user sessions. If you don’t have the user’s refresh token, access token, or authorization code, you must still fulfill the user’s account deletion request and meet the account deletion requirement. You'll need to follow this workaround to manually revoke the user credentials: Delete the user’s account data from your systems. Direct the user to manually revoke access for your client. Respond to the credential revoked notification to revert the client to an unauthenticated state Important: If the manual token revocation isn’t completed, the next time the user authenticates with your client using Sign in with Apple, they won’t be presented with the initial authorization flow to enter their full name, email address, or both. This is because the user credential state managed by Sign in with Apple remains unchanged and returns the.authorizedcredential state, which may also result in the system auth UI displaying the “Continue with Apple” button. Respond to the credential revoked notification Once the user’s credentials are revoked by Apple, your client will receive a notification signaling the revocation event:  For apps using the Authentication Services framework to implement Sign in with Apple, register to observe the notification named credentialRevokedNotification. For web services, if an endpoint is registered for server-to-server notifications, Apple broadcasts a notification to the specified endpoint with the consent-revokedevent type. When receiving either notification, ensure you’ve already performed the following operations to meet the requirements of account deletion: Deleted all user-related account data, including: The token used for token revocation; Any user-related data stored in your app servers; and Any user-related data store in the Keychain or securely on disk in the native app or locally on web client. Reverted the client to an unauthenticated state. Securely store user tokens for account creations For all new user account creations, follow the expected authorization flow below: Securely transmit the identity token and authorization code to your app server. Verify the identity token and validate the authorization code using the /auth/token endpoint.  Once the authorization code is validated, securely store the token response — including the identity token, refresh token, and access token. Validate the refresh token up to once per day with Apple servers (to manage the lifetime of your user session and for future token revocation requests), and obtain access tokens (for future token revocation, app transfer, or user migration requests). For information about verifying an identity token and validating tokens, visit Verifying a user and Generate and validate tokens. If you have questions about implementing these flows, including client authorization, token validation, or token revocation, please submit a Technical Support Incident.

We operate a website-only service using Sign in with Apple. On iPhone Safari, the native authorization sheet displays a gray tile containing “N” beside our service name. We would like that tile to display our company logo. This concerns the service icon inside Apple’s native sheet, not the Sign in with Apple button on our website. Our Services ID is associated with an existing primary App ID enabled for Sign in with Apple. As of our latest account review on October 15, 2026, our team had no App Store Connect app record for this service. We have not found a separate logo upload field in the Services ID or primary App ID settings. Apple Developer Support directed us here for technical guidance. Could Apple clarify the currently supported approach? Can a website-only service configure this logo independently? If so, what exact setting or process, asset specifications, and eligibility requirements apply? If the icon must come from a native app, what is the earliest qualifying stage: an App Store Connect record, a processed build upload, TestFlight availability, App Review submission, approval, or public release? Does a build that is never publicly released qualify? What determines the gray letter tile when the company logo is unavailable? After a qualifying icon is added or changed, what propagation/cache time should we expect, and how can we verify or refresh it safely on a physical iPhone without revoking existing users’ authorizations? If there is currently no supported solution for a website-only service, could you confirm that limitation and any supported alternative? We need to retain the existing Services ID, primary App ID, and user associations. We reviewed the web configuration guide, WWDC22 session 10122, the historical Apple Staff replies in thread 123054, and Add an app icon. These describe the primary app icon, but do not clearly establish the supported website-only path or the precise eligibility stage for this native sheet. Thank you.

⚠ It'd be great to get some Apple Dev eyes on this -- it's one of my last remaining issues before submission. Regarding migrating Sign In with Apple users from team PLR8R96VKA to team Y76F338229... I'm following the migration steps at the bottom of https://developer.apple.com/documentation/signinwithapple, in the Transfers Across Teams section. My call to the /auth/usermigrationinfo endpoint results in a 400 error: invalid_request, but my request params all look correct: transfer_sub is set to the the value I got from a successful /auth/usermigrationinfo response. client_id is set to Services ID of the new team's Sign In with Apple service. client_secret was built from the new team's Key ID, Team ID and Services ID. I know it's content and format is valid because it worked fine when calling the /auth/token endpoint. I know my auth token is fine (the one I got from /auth/token)--I'm sure I'd see an auth error if it wasn't. Is there any way I can get more information about what is invalid about the request?

Hello, I currently have an app that includes the "Sign in with Apple" feature, and I need to transfer this app to another app team. I have reviewed all official documentation but have not found the answer I need. My situation has some specificities, and I hope to receive assistance. The .p8 key created by the original developer team has been lost, and the app’s backend does not use a .p8 key for verification—instead, it verifies by obtaining Apple’s public key. However, according to the official documentation I reviewed, obtaining a transfer identifier during the app transfer process requires a client_secret generated from the original team’s .p8 key. This has left us facing a challenge, and we have two potential approaches to address this issue: Q1: During the transfer, is it possible to skip obtaining the transfer identifier and proceed directly with the app transfer, without performing any backend operations? Is this approach feasible? Q2: If the above approach is not feasible, should we create a new .p8 key in the original team’s account and use this new key for the transfer? If a new key is generated, do we need to re-release a new version of the app before initiating the transfer? If neither of the above approaches is feasible, are there better solutions to resolve our issue? I hope to receive a response. Thank you. TN3159: Migrating Sign in with Apple users for an app transfer | Apple Developer Documentation/ https://developer.apple.com/documentation/signinwithapple/transferring-your-apps-and-users-to-another-team

Hello Apple Developer Support, We need assistance with migrating Sign in with Apple users after completing an app transfer between two Apple Developer Teams. Current situation The app transfer has been completed and accepted by the recipient team. The recipient team has not yet released a new version on the App Store. Our production server, database, API domain, Bundle ID, and existing application user accounts remain unchanged. Before the transfer, we had never created a Sign in with Apple private key under the transferor team. Therefore, we do not have a previously generated .p8 private key for this app. This is not a case of a lost or revoked key. After the transfer, the app’s identifier is no longer listed under the transferor team’s Certificates, Identifiers & Profiles. When attempting to create a Sign in with Apple key under that team, we cannot select the transferred App ID as the primary App ID. Migration blocker According to Apple’s migration documentation, the transferor team must use its own client_secret to obtain a migration access token and generate a transfer_sub for each existing user. We are unsure how to obtain valid transferor-team credentials now that the App ID has moved to the recipient team and no private key was created before the transfer. Questions What is the supported procedure for obtaining valid transferor-team migration credentials in this situation? Can the transferor team create or configure a new Sign in with Apple private key for the transferred App ID after the transfer has been completed? If this cannot be done through the developer portal, can Apple Developer Support assist, or is there another supported migration method? Is transferring the app back to the original team, preparing the migration credentials and user transfer identifiers, and then transferring it again necessary in this situation? We would like to confirm whether this is required before making any further changes to the app’s ownership. We understand that the user migration process has a 60-day transfer window. We would appreciate guidance on resolving this credential issue promptly so that existing users can continue signing in to their original application accounts. Thank you for your assistance.

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!

We are in the process of transferring our existing Apple account to a new account. We read the documentation and we realized that "Sign in with Apple" users needs to be migrated via API. This API seems to require "sub" which we are not currently storing in our systems. So we are planning to "collect subs" over a period before we can start transfer. I want to make sure we are collecting correct data so I am looking for confirmation from Apple engineers on this. Should we get "sub" from "user" property in ASAuthorizationAppleIDCredential or by decoding identityToken and get "sub" from the token? I think both are same but wanted to double check. Thank you!

We’re trying to determine whether an iOS authentication flow is safe for production when ASWebAuthenticationSession ultimately returns a reusable backend bearer token because the authentication provider does not support a native authorization-code/PKCE exchange. We have an iOS app built with React + Capacitor that uses @capgo/capacitor-inappbrowser for Apple/Google social login. The iOS flow uses ASWebAuthenticationSession. Our backend/auth provider is Base44. Base44 supports web OAuth, but they have confirmed they do not provide a supported native authorization-code / PKCE session exchange for externally wrapped Capacitor apps. Current flow: The app starts Base44 OAuth in ASWebAuthenticationSession. Base44 completes Apple or Google authentication. Base44 redirects to an HTTPS bridge page hosted on our Base44 app domain. The bridge receives the Base44 access token. The bridge redirects to our app callback URL scheme and includes that Base44 bearer token in the callback. The active ASWebAuthenticationSession receives the callback. The app validates the callback URL, verifies a one-time random state, sets the Base44 token and immediately calls auth.me() to confirm the authenticated account. We have already hardened the flow by: using a 256-bit random one-time state expiring pending login attempts after 10 minutes binding the state to the provider and locally stored return path validating callback scheme/host/path removing unsolicited/global deep-link authentication listeners using prefersEphemeralWebBrowserSession = true scrubbing token artifacts from the hosted bridge URL/local storage not trusting callback-supplied return paths verifying the Base44 account before marking native login complete We understand that the preferred native OAuth model is authorization code + PKCE, but the backend provider does not expose that capability for this integration. My question is: Given that ASWebAuthenticationSession delivers the authentication callback to the initiating session, is passing a reusable backend bearer token through that callback still considered unsuitable for a production iOS app? If it is unsuitable, is there any secure pattern available when the authentication provider does not support a native one-time code / PKCE exchange? We also need to preserve existing Apple/Google-linked Base44 accounts, user data and subscription entitlements, so replacing the authentication backend is not a simple migration. I would particularly appreciate guidance on whether: ASWebAuthenticationSession materially mitigates custom-scheme interception in this scenario changing to a Universal Link callback would materially improve the design if the bearer token still has to be transferred this architecture would be considered acceptable for an App Store production release

Hello, I am experiencing a persistent Sign in with Apple issue for our production web application, Sai＊aus. When Sign in with Apple is initiated using our registered custom-domain return URL, Apple returns: invalid_request Invalid web redirect url. Configuration: Services ID: com.saiaus.app.auth Production domain: sai-aus.com Registered Return URL: https://sai-aus.com/__/auth/handler We have verified that the redirect_uri sent in the authorization request exactly matches the registered Return URL. As a comparison test, using the Firebase-hosted handler URL https://sai-aus.firebaseapp.com/__/auth/handler with the same Services ID proceeds successfully to the Apple Account sign-in screen. The failure occurs with the registered custom-domain handler. We previously contacted Apple Developer Support regarding this issue: Support Case: 102958526964 Support Case: 102960544416 Feedback Assistant: FB24784951 We submitted the issue through Feedback Assistant as directed and also provided follow-up information, but the issue remains unresolved. We tested the production flow again on October 4, 2026, and the same invalid_request / Invalid web redirect url. error is still reproducible. Could an Apple engineer please review FB24784951 and advise why the registered custom-domain Return URL is being rejected while the Firebase-hosted Return URL works? Thank you.

We have an iOS app built with React + Capacitor that uses @capgo/capacitor-inappbrowser for Apple/Google social login. The iOS flow uses ASWebAuthenticationSession. Our backend/auth provider is Base44. Base44 supports web OAuth, but they have confirmed they do not provide a supported native authorization-code / PKCE session exchange for externally wrapped Capacitor apps. Current flow: The app starts Base44 OAuth in ASWebAuthenticationSession. Base44 completes Apple or Google authentication. Base44 redirects to an HTTPS bridge page hosted on our Base44 app domain. The bridge receives the Base44 access token. The bridge redirects to our app callback URL scheme and includes that Base44 bearer token in the callback. The active ASWebAuthenticationSession receives the callback. The app validates the callback URL, verifies a one-time random state, sets the Base44 token and immediately calls auth.me() to confirm the authenticated account. We have already hardened the flow by: using a 256-bit random one-time state expiring pending login attempts after 10 minutes binding the state to the provider and locally stored return path validating callback scheme/host/path removing unsolicited/global deep-link authentication listeners using prefersEphemeralWebBrowserSession = true scrubbing token artifacts from the hosted bridge URL/local storage not trusting callback-supplied return paths verifying the Base44 account before marking native login complete We understand that the preferred native OAuth model is authorization code + PKCE, but the backend provider does not expose that capability for this integration. My question is: Given that ASWebAuthenticationSession delivers the authentication callback to the initiating session, is passing a reusable backend bearer token through that callback still considered unsuitable for a production iOS app? If it is unsuitable, is there any secure pattern available when the authentication provider does not support a native one-time code / PKCE exchange? We also need to preserve existing Apple/Google-linked Base44 accounts, user data and subscription entitlements, so replacing the authentication backend is not a simple migration. I would particularly appreciate guidance on whether: ASWebAuthenticationSession materially mitigates custom-scheme interception in this scenario changing to a Universal Link callback would materially improve the design if the bearer token still has to be transferred this architecture would be considered acceptable for an App Store production release

Sign in with Apple fails for every App ID in our team (K9UFUZF2XW), on every device and every Apple ID we have tried. The system sheet appears, the user authenticates successfully, the sheet then shows "Sign Up Not Completed", and no credential is returned. The failure happens after authentication — this is not a client-side rejection. I have spent several days isolating this and have ruled out everything on my side. Posting the full evidence in case an Apple engineer can look at the server-side state for our team, and in case it helps others hitting the same wall. WHAT THE FRAMEWORK ACTUALLY RETURNS The client library we use (expo-apple-authentication) discards the original NSError, so I patched its native layer to surface the raw error verbatim. This is what ASAuthorizationController hands back to didCompleteWithError, immediately after the user authenticated and the sheet displayed "Sign Up Not Completed": ASAuthorizationError .canceled (rawValue = 1001) domain = com.apple.AuthenticationServices.AuthorizationError code = 1001 desc = The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError, error 1001) userInfo: NSUnderlyingError: So the framework reports a user cancellation that never happened, with a completely empty userInfo and no underlying error. There is no diagnostic information on the client at all — I cannot debug this any further from my side, because the information does not exist there. Note: the same failure surfaces as a different error code depending on the client library version — .unknown (1000) with the older version, .canceled (1001) with the current one. The user-visible behaviour ("Sign Up Not Completed") is identical in both. So the error code is not a reliable signal here. WHAT I RULED OUT Not the App ID. I created a brand-new App ID (kz.auraai.ios) with Sign in with Apple enabled as a primary App ID, built a fresh binary, tested on the same device with the same Apple ID — identical failure. Two independent App IDs in the same team fail the same way. Not the entitlement. Verified inside the signed binary, not just in the portal: application-identifier = K9UFUZF2XW.kz.auraai.ios com.apple.developer.applesignin = ["Default"] I also tried the workaround suggested elsewhere on these forums (removing the entitlement while keeping the capability in the portal). That made it strictly worse: iOS then rejects the request instantly, without showing the sheet at all. Which confirms iOS reads the entitlement correctly, the sheet works, and the user authenticates — the failure is downstream of all of that. No stray or wildcard App IDs. A commonly cited cause is other App IDs in the team lacking the entitlement. I enumerated the whole team via the App Store Connect API: it contains exactly two App IDs, both with APPLE_ID_AUTH = PRIMARY_APP_CONSENT. No wildcard identifiers exist. Not the Apple ID, the device, or the iOS version. The same Apple ID, on the same device, with the same iOS, signs in successfully through another app belonging to a different team (Expo Go, host.exp.Exponent) — a valid identity token is returned. A second, unrelated Apple ID on another device fails in my app in exactly the same way. So this is not scoped to one account: it affects every user of the app. Agreements and membership are in good standing. Program License Agreement accepted 30 June 2026; Developer Agreement accepted 26 June 2026; membership active. Both distribution types fail. TestFlight and ad-hoc. WHAT IS LEFT After all of the above, the only variable that differs between the working case (a different team's app, same device, same Apple ID) and the failing case (my app) is the Apple Developer team itself. This exact signature — sheet renders fully, final server submit fails, "Sign Up Not Completed", delegate reports canceled with no userInfo, not reproducible in other apps on the same device — is documented in thread 122458 ("Error: Sign-Up Not Completed"). In that case it affected multiple developers, including Apple's own sample app, and was ultimately resolved by Apple on the server side, with a recurrence reported in June 2025. THE ASK Could someone from Apple check the server-side Sign in with Apple registration for team K9UFUZF2XW (App IDs kz.auraai.app and kz.auraai.ios)? I am not looking for configuration advice — I have exhausted the client side and there is nothing left to configure. This looks like the same server-side state that was fixed in the referenced cases. Feedback Assistant: FB23716661 (includes sysdiagnose with the Accounts/AuthKit profile, timestamp, and video of the failure). This is currently blocking us: because Sign in with Apple works for none of our users, guideline 4.8 prevents us from offering Google Sign-In, so we are shipping with email-only login. Happy to provide the binary, entitlements dump, or a fresh sysdiagnose on request.

Sign-In with Apple stopped returning the email property in my backend service for about 40% of new users who sign up for my app. My app requires email property on initial signup for accounts to work correctly. The changes I made leading up to this problem were: I updated my app's capabilities by enabling the com.apple.developer.authentication-services.account-creation-requires-phone-number I regenerated the provisioning profiles through the Apple developer portal I tried reverted the capability and regenerated the provisioning profiles but the email field is still missing. The response includes: iss, aud, exp, iat, sub, c_hash, auth_time, and nonce_supported properties but is missing the email, email_verified and is_private_email properties. For users who already have an account, I can use the sub property to locate their account. But the experience is now broken for a lot of new users and I fail to log them in. Does anyone know if I'm doing something incorrectly? Thanks so much for the help!

Hello, I am developing an application that integrates with Apple Music to provide a personalized music video experience for Apple Music subscribers. We are working on support for many devices like Android TV / Google TV / WebOS / etc. and would like to implement an authorization experience suitable for a television, where entering account credentials with a remote control is cumbersome. Intended authorization flow We would like to implement the following experience: The application on the TV displays a QR code or short activation code. The user scans the QR code with their phone and opens an Apple-hosted authentication and authorization page. The user signs in to their Apple Account if necessary and approves Apple Music access for the application on the TV. The TV application receives or retrieves the resulting authorization and can use it for the supported Apple Music functionality. The objective is for the TV application itself to be authorized following approval on the phone, with no need to enter the Apple Account credentials on the television. Relevant implementation evidence found on Apple’s website While researching this integration, we examined JavaScript publicly served by link.apple.com. In the following OAuth view bundle, we observed these identifiers: PartnerAuthorizationRequest isOffDeviceOAuth2Flow DEVICE_CODE Source: Apple-hosted OAuth view bundle — oauth-views-OAuth-vue.4db9105e.js In the associated OAuth initializer bundle, we observed properties including: client_id scope response_type Source: Apple-hosted OAuth initializer bundle — oauth-views-OAuthInitializer-vue.23605d03.js These elements suggest that Apple’s authorization interface includes an off-device authorization path associated with partner clients. We understand that these implementation details are not public API documentation and do not establish whether this flow is available to third-party developers. We are looking for the officially supported integration and enrollment process, if one is available. Clarification requested 1. Availability for third-party TV applications Does Apple offer a supported Apple Music authorization flow of this kind for third-party applications running on non-Apple devices? If the observed flow is limited to certain integrations or partners, what are the eligibility requirements for obtaining access? 2. Client registration and account configuration What is the official process for registering or obtaining a client_id authorized to use this flow? We have reviewed the standard MusicKit configuration involving Media IDs, Media Services keys, App Services and Capability Requests, but have not identified the configuration or application process for off-device authorization. Could you clarify whether this requires: A standard MusicKit Media ID and Media Services key; An additional service configuration or managed capability request in the Apple Developer account; A separate OAuth client registration; Or approval through an Apple Music partner program? 3. Supported integration documentation If this integration is available, where can we obtain the documentation or SDK covering: The required client configuration, request parameters and permitted scopes; Creation of the authorization request and the QR code or activation link; The mechanism by which the TV checks for completion or receives the result; The resulting token type, its intended use, and its expiration or reauthorization requirements? In particular, we would appreciate clarification on whether the resulting authorization provides a Music User Token usable by the TV application, or another token that requires a documented exchange. 4. Apple Music access on the authorized TV Which Apple Music APIs or SDKs can consume the resulting authorization? We would like to confirm its supported use with Apple Music API and MusicKit for Android, including any separate requirements for playback on the TV. Our intended design is for authorization to be issued for the TV application, rather than transferring a Music User Token issued for the phone. If this access is handled outside the standard MusicKit developer workflow, could you please identify the applicable program and enrollment process, or who to route this request to the Apple Music team responsible for partner authorization and connected-device integrations? Thank you for helping us identify the supported path for this integration. Louis

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.

Sign in with Apple fails with "Sign-Up Not Completed" Team A884B34HZR The authorization sheet renders correctly with our app name and the user's Apple Account. After the user authorizes, it ends with "Sign-Up Not Completed" and no credential is returned to the app: our delegate receives no credential, and our server never receives a request. Bundle ID: com.dinogoal.ios (created in 2026) Feedback: FB24978334. Developer Support case: 102979104342 (closed without a resolution) Already tried, with no change: Removing the Sign In with Apple capability from the App ID, saving, re-adding it as a primary App ID and saving again. Regenerating the provisioning profile and shipping a new signed build. Several Apple Accounts, on Wi-Fi and cellular, on iOS 26 and iPadOS 27. Our submission has been rejected under Guideline 2.1(a) because of this. This looks like the same server-side registration failure reported in threads 789452 and 837986.

We are transferring an iOS app from Team A to Team B and following TN3159 to migrate Sign in with Apple users. Setup on Team A: The app’s bundle ID (com.example.app) is enabled for Sign in with Apple as its own primary App ID, not grouped. Our website uses a Services ID (com.example.web-service) whose primary App ID is a different App ID (com.example.web), not the app. Some users signed in only on the website and never used the app. Using a Sign in with Apple key associated with the app’s App ID and client_id=com.example.app, /auth/usermigrationinfo returns a transfer_sub for every user we tested, web-only users included. Questions: After the transfer, Team B will exchange these transfer_sub values with client_id=com.example.app and its own client secret. Will that work for users who only authorized the web Services ID? Or can it fail (for example invalid_request) because they never authorized the app’s App ID? If it can fail, can we change the Services ID’s primary App ID to the app’s App ID before the transfer, so the Services ID transfers with the app (as TN3159 describes)? Would that affect existing users, for example by changing their identifiers or asking for consent again? For users with a private relay email: since Team A has no other app those users use, does the old relay address stop forwarding after the transfer? Does the exchange return the new relay address for web-only users too? Thanks!

中国银联开发的APP（Nihao China，苹果应用市场链接为：https://apps.apple.com/cn/app/id1187814659）国际版APP通过苹果联登进行登录，银联后台这边是通过正向代理访问的苹果服务器，之前一直正常。但是从9月23日凌晨03：40分以后，访问均被苹果截断，请求中出现 CONNECT 104 RST问题报错。 银联侧后台日志如下： 2026/09/2410：38：30 [错误] 21363#21363： *17559374 recv（） 失败（104： 连接重置），代理和上游读取时，客户端：19.154.22.71，服务器：localhost，请求：“CONNECT appleid.apple.com:443 HTTP/1.1”，主机：“appleid.apple.com" 想确认，苹果是不是升级了网络访问的安全策略导致我们我们的访问连接被截断。以及我们如何处理该问题？ 附：银联侧正向代理后的出口IP地址如下： 电信地址 106.39.14.241 106.39.14.245 106.39.14.246 106.39.14.248 117.133.178.242 117.133.178.243 117.133.178.244 117.133.178.247 联通地址 106.39.14.242 106.39.14.243 106.39.14.244 106.39.14.247 117.133.178.241 117.133.178.245 117.133.178.246 117.133.178.248

Hello Apple engineers, We are investigating an unresolved native Sign in with Apple failure in Rankids. Feedback FB24763387 contains the private reproduction details and Accounts/AuthKit sysdiagnose. The native Apple sheet displays "Sign in not complete" after biometric authentication and before returning any authorization credential. Both Share My Email and Hide My Email fail. We reproduced it on an iPhone and an iPad, while the same account can use Sign in with Apple in unrelated apps. The diagnostic build is TestFlight 1.0.9 (5). Accounts/AuthKit diagnostics show successful biometric authentication followed by AKAuthenticationServerError -24000 / "Invalid client.". The app receives ASAuthorizationError 1001 after the failed sheet is manually dismissed; that cancellation is not the original failure. No identity token reaches our app, so no backend token exchange takes place. The App ID capability was checked as enabled/Primary. The diagnostic binary and installed-device logs show the expected app/team identifiers and the Default Sign in with Apple entitlement. The app uses Expo Apple Authentication; we have not yet reproduced this in a separate minimal native Xcode project and are not claiming a confirmed server-side root cause. Could an Apple engineer advise whether the existing private diagnostics are sufficient to investigate the client rejection, and what additional evidence would distinguish an app configuration issue from an Apple-side registration issue? The code-level request form requires a focused Xcode project; guidance on the appropriate route for investigating the affected app registration would be appreciated. The production app currently uses email/password sign-in while we investigate. Account identifiers and full diagnostic files will remain in the private support channels. Thank you.

I am trying to get my first app approved and keep getting denied. In my app, I allow for Sign in With Apple. This allows the user to use Hide my Email to give a temp/private email. That is fine and I accept it. One of the major features of my app requires that parent's confirm their real address in order to see information and communicate about their children. It's a sports/coaching app. Coaches create their roster and associate parents with players via email address. Those parents then login and see their list of players (children) and can chat with the team, get schedules, etc. Without the real email, I have no way to validate that parent should have access to that player's details. It has to be secure. And a parent won't know their Hide my Email address ahead of time in order to provide it to the coach. Apple keeps denying my app saying that I cannot ask for their real email. I have explained it and the reviewer never addresses my explanation. Just denies it with the same reason. What can I do?

Our app's Sign in with Apple never completes. Apple's create-account sheet renders fully (name + share/hide-my-email step), then the final server submit fails and shows the "Sign Up Not Completed" sheet. The authorization callback returns ASAuthorizationError.canceled (1001) with no userInfo — even though the user did not cancel. Reproduced on multiple physical devices and multiple Apple IDs (all with 2FA), on iOS 26.5.1, since our first build. Team ID: 24XS837728 App ID: C54N9Q226H (bundle com.sucsessmaperrs.careerAssessmentApp) Verified on our side: com.apple.developer.applesignin = [Default] present in the distribution build (codesign -d --entitlements); embedded profile is the explicit App Store profile for the App ID (not wildcard). App ID has Sign in with Apple enabled as a primary App ID; capability deleted + recreated via the App Store Connect API today, no change. Firebase consumes the identity token; the failure is in Apple's UI before our code runs. App Store Connect agreements are clean. Key isolating fact: the same Apple ID on the same device completes a first-time Sign in with Apple sign-up in other third-party apps — only ours fails. So the cause appears scoped to our App ID / team on Apple's side, not the device, the Apple ID, 2FA, or our client code. This matches the widespread server-side "Sign Up Not Completed" failure in thread 675756 — same signature: multiple devices/Apple IDs, no console error, the failure delegate surfacing only as "cancel", newly created apps affected, even Apple's own sample app failing — which Apple ultimately resolved server-side (with a recurrence reported June 2025). Note this is the native ASAuthorizationController flow, not the REST/web flow, so the query-parameter percent-encoding fix from thread 122458 does not apply here. Could an Apple engineer check the server-side Sign in with Apple / account-association state for App ID C54N9Q226H (Team 24XS837728)? Happy to provide a screen recording or sysdiagnose.

We are hitting the same Sign in with Apple failure described in thread 837986, with an identical log signature. Posting our team details in case it helps the ongoing investigation. Team ID: CDLWFYN589 Bundle IDs: br.com.cesto, br.com.cestoparceiros App IDs created: 2026-08-20 (both recreated on that date) Build: TestFlight, iOS 26, physical iPhone SUMMARY Every first-time Sign in with Apple authorization fails with "Sign Up Not Completed". The Apple sheet renders correctly, with the right app name and the user's account. The user authorizes. The failure happens AFTER consent, in the SRP exchange with the Apple ID server. Our backend is never reached - signInAsync never returns a credential, so no server-side code of ours participates in the failing step. DEVICE LOG (akd, 2026-09-05 17:21:06-13, UTC-3) Client has default access level in SiwA entitlement Fetching developer team for client with ID: Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 No applications were found with the provided Client ID: Application has no shared credentials Using personal credential state - 2, error - Error Domain=AKAuthenticationError Code=-7074 presenting authorization UI for request <- sheet appears Got a response from user <- user authorizes No password, but CK is available. Will ask for ck-based auth. Task <59764A72-...> received response, status 200 AppleIDAuthSupport: setError: 2:M2 missing (bad password) Invalid/missing value for key acname: (null) Invalid value for key ut: (null) Invalid value for key authType: (null) SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2 The server returns HTTP 200 with the server proof (M2) absent. The "bad password" string appears to be the generic label for error 2 rather than a diagnosis - there is no password in this exchange, as the preceding line shows (No password, but CK is available). WHAT WE HAVE ALREADY VERIFIED Capability APPLE_ID_AUTH present on both App IDs, with APPLE_ID_AUTH_APP_CONSENT: PRIMARY_APP_CONSENT (read back through the App Store Connect API). com.apple.developer.applesignin: [Default] present in the SHIPPED .ipa, verified with codesign -d --entitlements :- on the extracted payload rather than on the archive. Embedded profile is "iOS Team Store Provisioning Profile" and carries the entitlement (security cms -D -i embedded.mobileprovision). Bundle IDs match across the project config, Identifiers and App Store Connect. No other App ID in the team declares APPLE_ID_AUTH. Program License Agreement accepted on 2026-08-25; 2FA active on the account. Requesting only fullName, with no email scope, does not change the outcome. The log line "Client has default access level in SiwA entitlement" is what closes the client-side question for us: the entitlement is present and read correctly ON DEVICE, not merely present in our build output. QUESTION Given the confirmation earlier in thread 837986 for team GW7XA5CX69 - same build and same configuration starting to work with no changes on their side - this looks like the same server-side condition affecting recently created App IDs. Could our Team ID be included in that investigation? Happy to file a Feedback with the full log attached and post the number here if that is the preferred route.