Hi Apple Developer Community, We have carefully reviewed the documentation on App Transfer and User Migration, but we still have a few unresolved questions regarding Apple Sign-In token behavior and testing strategies. Would appreciate any guidance! Token Behavior for Pre-Transfer App Versions After the app transfer: If a user logs in via an existing pre-transfer version of the app (published under Team A before transfer), will the Apple Sign-In token’s sub (or private email) switch to new value tie to Team B, or unchanged? This is critical for our user migration plan. Preserving sub Across Transfers (Internal Team Transfer) Since our app-transfer is an internal transfer (no change in app ownership outside our organization), is there a way to retain the original sub value（or private email） for users after the transfer? We are concerned that Apple Sign-In errors during the app transfer process may negatively impact user experience. Testing the Transfer Process Safely We’d like to simulate the app transfer and user migration process in a sandbox/test environment before executing it in production. Is there a way to test app transfers without affecting live users? (e.g., a staging mode for transfers) Thank you for your expertise! Any insights would be invaluable.

Question detail Dear Apple Developer Technical Support, We are currently following the official Apple documentation “TN3159: Migrating Sign in with Apple users for an app transfer” to carry out a Sign in with Apple user migration after successfully transferring several apps to a new developer account. Here is a summary of our situation: Under the original Apple developer account, we had five apps using Sign in with Apple, grouped under a shared primary app using App Grouping. Recently, we transferred three of these apps to our new Apple developer account via App Store Connect. After the transfer, these three apps are no longer associated with the original primary App ID. We reconfigured individual Services IDs for each app in the new account and enabled Sign in with Apple for each. More than 24 hours have passed since the app transfer was completed. Now we are attempting to follow the migration process to restore user access via the user.migration flow. Specifically, we are using the following script to request an Apple access token: url = "https://appleid.apple.com/auth/token" headers = {"Content-Type": "application/x-www-form-urlencoded"} data = { "grant_type": "client_credentials", "scope": "user.migration", "client_id": "com.game.friends.ios.xxxx", # New Primary ID in the new account "client_secret": "<JWT signed with new p8 key>" } response = requests.post(url, headers=headers, data=data) However, the API response consistently returns: { "error": "invalid_client" } We have verified that the following configurations are correct: The client_secret is generated using the p8 key from the new account, signed with ES256 and correct key_id, team_id, and client_id. The client_id corresponds to the Services ID created in the new account and properly associated with the migrated app. The scope is set to user.migration. The JWT payload contains correct iss, sub, and aud values as per Apple documentation. The app has been fully transferred and reconfigured more than 24 hours ago. Problem Summary & Request for Support: According to Apple’s official documentation: “After an app is transferred, Apple updates the Sign in with Apple configuration in the background. This can take up to 24 hours. During this time, attempts to authenticate users or validate tokens may fail.” However, we are still consistently receiving invalid_client errors after the 24-hour waiting period. We suspect one of the following issues: The transferred apps may still be partially associated with the original App Grouping or primary App ID. Some Sign in with Apple configuration in Apple’s backend may not have been fully updated after the transfer. Or the Services ID is not yet fully operational for the transferred apps in the new account. We kindly request your assistance to: Verify whether the transferred apps have been completely detached from the original App Grouping and primary App ID. Confirm whether the new Services IDs under the new account are fully functional and eligible for Sign in with Apple with user.migration scope. Help identify any remaining configuration or migration issues that may cause the invalid_client error. If necessary, assist in manually ungrouping or clearing any residual App Grouping relationships affecting the new environment. We have also generated and retained the original transfer_sub identifiers and are fully prepared to complete the sub mapping once the user.migration flow becomes functional. Thank you very much for your time and support!

Hello, I’m experiencing an issue with email deliverability when sending messages through Apple’s private email relay service. Our app uses “Sign in with Apple” and sends communication emails to users through relay addresses . Messages are successfully delivered but are consistently being placed in users’ spam or junk folders. Configuration summary: Domain: myapp.example Mail server: OVH SMTP SPF and DKIM: Active and validated Domain and sender registered under “Sign in with Apple for Email Communication” Messages pass SPF and DKIM checks successfully, but emails relayed by Apple’s private service are still being marked as spam. Could anyone confirm if there are additional steps or configurations required to improve deliverability (e.g., DMARC alignment or specific header requirements)? Thank you for your help!

Private relay emails are not being delivered, even though we've followed the guidance here, https://developer.apple.com/help/account/capabilities/configure-private-email-relay-service/ iCloud, gmail etc. get delivered fine but as soon as its a private relay email address they get bounced as unauthorized sender. We've tried a couple of domains but here I'll document test.x.domain.com We have registered domains (test.x.domain.com), also the sender communication emails just to be safe (noreply at test.x.domain.com). Passed SPF Authentication, DKIM Authentication. ESP account shows as all green checks in mailgun. Is there any way to track down what the actual rejection reason is? { "@timestamp": "2025-08-20T14:30:59.801Z", "account": { "id": "6425b45fb2fd1e28f4e0110a" }, "delivery-status": { "attempt-no": 1, "bounce-type": "soft", "certificate-verified": true, "code": 550, "enhanced-code": "5.1.1", "first-delivery-attempt-seconds": 0.014, "message": "5.1.1 <bounce+b53c9e.27949-6qj4xaisn4k=privaterelay.appleid.com@test.x.domain.com>: unauthorized sender", "mx-host": "smtp3.privaterelay.appleid.com", "session-seconds": 1.7229999999999999, "tls": true }, "domain": { "name": "test.x.domain.com" }, "envelope": { "sender": "noreply@test.x.domain.com", "sending-ip": "111.22.101.215", "targets": "6qj4xaisn4k@privaterelay.appleid.com", "transport": "smtp" }, "event": "failed", "flags": { "is-authenticated": true, "is-delayed-bounce": false, "is-routed": false, "is-system-test": false, "is-test-mode": false }, "id": "1gtVBeZYQ0yO1SzipVP99Q", "log-level": "error", "message": { "headers": { "from": "\"Test Mail\" <noreply@test.x.domain.com>", "message-id": "20250820143058.7cac292cf03993f2@test.x.domain.com", "subject": "Test Mail", "to": "6qj4xaisn4k@privaterelay.appleid.com" }, "size": 22854 }, "primary-dkim": "s1._domainkey.test.x.domain.com", "reason": "generic", "recipient": "6qj4xaisn4k@privaterelay.appleid.com", "recipient-domain": "privaterelay.appleid.com", "recipient-provider": "Apple", "severity": "permanent", "storage": { "env": "production", "key": "BAABAgFDX5nmZ7fqxxxxxxZNzEVxPmZ8_YQ", "region": "europe-west1", "url": [ "https://storage-europe-west1.api.mailgun.net/v3/domains/test.x.domain.com/messages/BAABAgFDXxxxxxxxxxxxxxNzEVxPmZ8_YQ" ] }, "user-variables": {} }

Hello. Some of my users are signing in using "Sign in with Apple" and choosing the "Hide My Email" option. As expected, Apple generates a private relay email address. However, emails that we send to these addresses are not being delivered — the users report that they are not receiving anything. We’ve configured our email sending domains in the Apple Developer portal, and all domains have been successfully verified with SPF records marked as OK. Our system is sending the emails as usual, and we're not receiving any bounce-back or error messages. Everything looks fine on our end. Is there something specific we need to configure to ensure emails sent to privaterelay.appleid.com addresses are delivered correctly? Are there any known limitations or additional requirements for using Apple's private relay service? Thank you!

Our app (app1) was recently transferred from Team A to Team B. While reviewing the Apple login implementation, we discovered that "Sign in with Apple" had been incorrectly set up to use the Service ID and App ID of another app (app2) — specifically, it was using app2.service as the Service ID and app2 as the App ID. In other words, app1’s users were authenticated through app2’s credentials due to a misconfiguration on our part. Now that app1 has been transferred to Team B, we’re trying to preserve those users. However, app2 is still in Team A, and we cannot maintain Team A anymore — meaning app2 must also be transferred to Team B if we want to retain access to the user data. One idea we considered is submitting app2 for App Review (even though it's non-functional) just to fulfill the transfer requirements, and then transferring it to Team B solely to retain the Apple login setup. Is this approach acceptable? Are there any recommended ways to handle this kind of misconfiguration while preserving existing Sign in with Apple users?

My existing iOS app has a legacy App ID prefix which does not match my Team ID. I am planning on migrating it to my Team ID. I am aware of the potential issues with keychain access groups, however I wanted to double check that there are no issues related to "Sign in with Apple". My app is currently the "Primary App ID" in the "Sign in with Apple" settings. The full App ID is listed there, including the prefix. Can someone from the relevant team at Apple confirm that changing the App ID prefix to Team ID has no effect related to "Sign in with Apple"?

Hi everyone, I have followed all the Apple procedures, read the forums, and looked at various experiences of other users who had my problem, but I haven’t found a solution. On my site, I have added login with all the “big” providers, and Apple is the only one missing. I’ve tried everything, but when the user logs in and is authenticated, I get an error. In order, here’s what I receive: Received Apple code: cfbf091dd6... JWT generated correctly HTTP Error (400): {"error":"invalid_client"} I’ve read all sorts of things, including that you have to wait up to 48 hours for the Key to be enabled. Any ideas? I’ve read that this is a common problem, but I haven’t found a valid solution. Thanks in advance to anyone who can help me.

Hi everyone, We just completed an App Store Connect app transfer between two developer teams and ran into what seems like an inconsistency with TN3159 (Migrating Sign in with Apple users for an app transfer). According to the technote, both the source and destination teams should be able to call /auth/usermigrationinfo for 60 days after the transfer, even if the migration wasn’t run beforehand. However, right after the transfer completed, the source team (Team A) started receiving: {"error":"invalid_client"} on all /auth/usermigrationinfo requests, even though /auth/token with scope=user.migration still works fine. What we verified before transfer: Team A’s Sign in with Apple key (ES256) was linked to the app and Services ID. OAuth flow for com.org.appname.web returned valid tokens, and the decoded ID token showed aud=com.org.appname.web with a valid private relay email, confirming the key was trusted. What happens after transfer: The key now shows “Enabled Services: —” and the App/Services IDs are no longer selectable in the Developer portal. /auth/usermigrationinfo immediately returns invalid_client for Team A, even within the same day of the transfer. This effectively makes Team A unable to generate transfer_sub values, blocking the migration flow TN3159 describes. Questions: Is Team A supposed to retain authorization to call /auth/usermigrationinfo for 60 days post-transfer? If yes, is there any known workaround to re-authorize the key or temporarily re-bind it to the transferred identifiers? If not, does this mean transfer_sub must be generated before transfer acceptance, contrary to how TN3159 reads? Would really appreciate any confirmation or guidance from Apple or anyone who’s gone through this recently. Thanks,

I understand from the recent Apple Developer News that Korean developers are now required to register a URL to receive notifications from the Apple server when creating or modifying a Sign in With Apple Service ID. However, it is not clear whether simply registering the URL is sufficient, or if it is also mandatory to implement the real-time processing of those notifications. I am inquiring whether the processing part is also a mandatory requirement.

Hello, I'm trying to renew my Appstore Connect subscription but unfortunately I'm facing problems. Our Account Holder ID is locked and when he tries to log in an error message keeps showing up saying "This Apple ID has been Locked. Contact your Administrator or Manager to reset your password and unlock your account." whose the admin or manager in this case? I contacted the support multiple times and they referred me to this link. https://support.apple.com/en-us/HT201487 We tried these steps but sadly no luck. whenever he tries to change the password an error message keep popping up saying "Need to reset your password? Contact your organization’s Administrator or Manager and ask them to reset the password for your Managed Apple ID"

Hello everybody, in my React Native-Expo-Firebase app, I am trying to integrate Sign in with Apple, along with the related token revocation at user deletion. I did succeed in integrating the login, and the app correctly appears in the Apple Id list (the list of apps currently logged with Apple ID). The problem is that, if I select the app and press "Interrupt Apple login usage for this app", the app simply stays there, nothing happens. If I do the same with another app, this works fine. Either if I do this via my iPhone's settings, or via https://account.apple.com/account/manage -> Sign in with Apple, I get the same result, the app cannot be removed. I hope I managed to explain my situation clearly, I'd be happy to provide more info if necessary. Thank you in advance.

I received Apple’s recent notice about the new requirement to provide a server-to-server notification endpoint when registering or updating a Services ID that uses Sign in with Apple. (Official notice: https://developer.apple.com/news/?id=j9zukcr6 ) We already use Sign in with Apple on our website and app, but only as a login method for pre-registered users, not as a way to create new accounts. That means users already exist in our system, and Apple login is used only for authentication convenience (similar to linking a social account). I have some questions about how to properly implement the required server-to-server notifications in this case: 1. email-enabled / email-disabled: We don’t use or store the email address provided by Apple. Are we still required to handle these events, or can we safely ignore them if the email is not used in our system? 2. consent-revoked: We don’t store Apple access or refresh tokens, we use them only during login and discard them immediately. In this case, do we still need to handle token revocation, or can we simply unlink the Apple login from the user account when receiving this notification? 3. account-delete: If a user deletes their Apple account, we can unlink the Apple login and remove related Apple data, but we cannot delete the user’s primary account in our system (since the account exists independently). Is this acceptable under Apple’s requirements as well? We want to make sure our implementation aligns with Apple’s policy and privacy requirements, while maintaining consistency with our existing account management system. If anyone from Apple or other developers who implemented similar logic could provide guidance or share examples, it would be greatly appreciated. Thank you!

I want to implement "sign in with apple" feature for my webapp. Currently it's in developing phase so can i integrate it without paying to Apple Developer Program membership. As google auth platform provide it for free, so does apple?

Hello I have a problem with provisionprofile file. I have created Identifier with Sign in with Apple capability turned on, created Profile with Developer ID selected and now I try to export archive with generated Developer ID provision file but it says "Profile doesn't support Sign in with Apple" Also interesting thing that default provisions like macOS App Development Mac App Store Connect don't show such error when I try to export archive Maybe this problem is only related to Developer ID provision and Direct Distribution doesn't support Sign in with Apple, but I havent found proves about this idea

I'm experiencing an issue with Sign In with Apple integration in my React Native Expo app (Bundle ID: com.anonymous.TuZjemyApp). Problem Description: When users attempt to sign in using Sign In with Apple, they successfully complete Face ID/password authentication, but then receive a "Sign-Up not completed" error message. The authentication flow appears to stop at this point and doesn't return the identity token to my app. Technical Details: Frontend Implementation: Using expo-apple-authentication. Requesting scopes: FULL_NAME and EMAIL App is properly configured in app.json with: usesAppleSignIn: true Entitlement: com.apple.developer.applesignin Backend Implementation: Endpoint: POST /api/auth/apple Using apple-signin-auth package for token verification Verifying tokens with audience: com.anonymous.TuZjemyApp Backend creates/updates user accounts based on Apple ID Question: I'm not sure why the authentication flow stops with "Sign-Up not completed" after successful Face ID verification. The identity token never reaches my app. Could you please help me understand: What might cause this specific error message? Are there any additional Apple Developer Portal configurations required? Could this be related to app capabilities or entitlements? Is there a specific setup needed for the app to properly receive identity tokens? I set up provisioning profiles, and added Sign in with Apple as a capability and still it doesn't work.

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

Hi, I run a midsize business. Apple recommends for company owned devices and for other reasons to use Apple Business managed Apple IDs for the employees. After that, you have to use a MDM System for e.g. deploying apps and licenses. Testflight is an app that can be deployed too. But....Testflight can not more than to say "Hello" on a managed device. The use of Testflight and to test our developed apps is not possible with a managed ID. Can anyone explain to me this thinking or what is recommended than. Setting up a private Apple ID for that purpose...which on the other hand, Apple do not want or does not recommend.

I've just implemented Sign-In-With-Apple and everything is working perfectly, but my app seems to be in some strange state where users are unable to remove it from the Sign-In-With-Apple section of their settings. Things I've tried: -- Deleting from Mac. (It just stays in the list) -- Deleting from the iPhone (It stays in the list) -- Deleting from account.apple.com (same issue) -- I've noticed in the browser inspector tools I receive a 200 on the DELETE request, but the app remains. -- Multiple users Also have tried: -- Revoking the token through the REST API -- I get an email saying the token has been revoked, but it's still working -- Same code, different app id (works fine!) It seems like maybe my app is in some sort of weird state? Has anyone come across this before?

We are working on a PoC iOS App to use "Sign in with Apple" on iOS. The app needs to authenticate the current user on MDM managed corporate iPads (with Shared iPad enabled) and each user having a Managed Apple ID (created in Apple Business Manager). We have started with Apple's example app: https://developer.apple.com/documentation/authenticationservices/implementing-user-authentication-with-sign-in-with-apple When we run it on a normal iPad (without MDM supervision) it works fine. When we run the same code on a managed iPad with Shared iPad enabled and Managed Apple ID's the app errors out when a user taps the "Sign in with Apple" button. A User-facing error message is displayed: “Your Apple Account cannot be used to create accounts for other apps.” And when we run the app from Xcode we see the following logs: Authorization failed: Error Domain=AKAuthenticationError Code=-7027 "(null)" UserInfo={AKClientBundleID=com.sampleapp.test2} 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=1000 "(null)" Could not authenticate: The operation couldn’t be completed. (com.apple.AuthenticationServices.AuthorizationError error 1000.) We have confirmed that in ABM "Sign in with Apple" feature is enabled with "Allowed apps": "All apps". We have also confirmed that the Managed AppleIDs created in ABM have no field to provide the birthday of the user and therefore ruling out age restrictions for "Sign in with Apple". Is "Sign in with Apple" supported in MDM managed iPADs with Shared iPad enabled and managed AppleIDs? If it is supported, do we know what other configurations we need to get it to work? Do we know why "Sign in with Apple" would error out with Authorization failed: Error Domain=AKAuthenticationError Code=-7027 "(null)" UserInfo={AKClientBundleID=com.sampleapp.test2} 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, Environment: • iPadOS version: IPadOS Version 18.7 • Xcode version: Version 26.0 (17A324) • Device type: iPad Air 11-inch (M3) in Shared iPad mode • Account type: Managed Apple ID created in ABM enrolled with Intune MDM) Thank you