a I am submitting this appeal because we believe our app was misunderstood and the review outcome and follow-up communication have been unfair and mechanically handled. 1) What happened / Outcome we disagree with Our submission was rejected under Guideline 4.8 – Design – Login Services, with the reviewer stating that our app uses a third-party login service but does not provide an equivalent login option that meets Apple’s requirements (limited data collection, private email option, no advertising tracking without consent). However, our game does not require or force any third-party login. The feature being treated as “login” is not a login service at all—it is Mainland China real-name / anti-addiction compliance verification. 2) Why we believe we comply with the App Review Guidelines A. The feature in question is compliance verification, not login Players do not need to create or log into any in-game account to play. The flow exists solely to satisfy Mainland China real-name/anti-addiction compliance requirements. Verification can be completed by either: Using TapTap only as a real-name verification authorization option, or Manually entering a Chinese ID number + legal name to pass verification and play. Because this is verification, not an account login, Guideline 4.8 “Login Services” should not apply in the way the rejection message assumes. B. There is no “playable account” to provide After we clarified the above, we continued to receive repeated, template-like requests to provide a “playable account.” This request does not match our product design: there is no account system required for gameplay, so there is no “review account” to provide. We have already provided the information needed to complete the verification path (ID + name for the compliance flow), yet the responses remained repetitive and did not reflect that the reviewer checked our explanation. 3) Why we believe the handling was unfair Even after clearly explaining that this is not a login system, the review communication continued with mechanical responses that did not address the clarification. This caused significant delays to our release timeline and appears to be unfair treatment compared with many existing App Store apps that use similar compliance verification flows. 4) What we are requesting from the Appeals Team Please investigate and correct the misclassification of our real-name compliance verification as a “login service” under Guideline 4.8. If the team still believes Guideline 4.8 applies, please provide: The specific guideline rationale, and The exact screen/step in our app that is being interpreted as “login.” Please advise what specific materials you need to proceed efficiently (e.g., screen recording of the verification flow, step-by-step review instructions, configuration notes). We are ready to provide them immediately.

Could you tell me about account security and passkeys? Our service is considering implementing passkeys, and these questions are to understand how Apple protects accounts from third parties. ① Apple website states that two-factor authentication is mandatory for newly created Apple Accounts. When did this requirement come into effect? What are the conditions for users who do not have two-factor authentication enabled? ② Apple website mentions that a verification code may be required when signing into an Apple Account from a new device or browser. Is my understanding of the situations where a verification code is requested accurate, as listed below? Are there any other situations? Completely signing out of the Apple Account on that device. Erasing the device. Needing to change the password for security reasons. ③ If a user is already using a passkey on an Apple device, and then upgrades to a new device, will additional authentication, such as entering a PIN code, be required to use the passkey on the new device?

hello, I'm writing to seek clarification on Apple account security, particularly regarding potential risks of compromise, implemented safeguards, and residual risks with corresponding mitigation strategies. We would appreciate your insights on the following specific points: iCloud Keychain Access: Is an Apple ID login strictly required to access iCloud Keychain? We understand that a compromise of iCloud Keychain is unlikely unless a malicious actor successfully takes over the legitimate user's Apple ID. Is this understanding correct? Passkey Theft Methods and Protections: What are the conceivable methods a malicious actor might employ to steal a legitimate user's passkey, and how are these attempts protected against? Impact of Apple ID Compromise on Passkeys: If a malicious actor successfully compromises a legitimate user's Apple ID, is it accurate to assume that the legitimate user's passkeys would then synchronize to the attacker's device, potentially allowing them to log in using their own biometrics? Authorization Flow on Legitimate User's Device: Could you please detail the authorization flow that occurs on the legitimate user's device? We are particularly interested in the types of authentication involved and the conditions under which they are triggered. Detection and Additional Authentication for Unauthorized Login: How are attempts to log in to an Apple ID from an unrecognized device or browser detected, and what additional authentication steps are implemented in such scenarios? Thank you for your time and assistance in addressing these important security questions.

I am getting the following errors. The app used to work and now does not, even without any code changes. Any thoughts on resolving this issue? Authorization failed: Error Domain=AKAuthenticationError Code=-7026 "(null)" Us erInfo={AKClientBundleID=<bundleid>} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" Us erInfo={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" Us erInfo={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)"

Hello, We are working on integrating app integrity verification into our service application, following Apple's App Attest and DeviceCheck guide. Our server issues a challenge to the client, which then sends the challenge, attestation, and keyId in CBOR format to Apple's App Attest server for verification. However, we are unable to reach both https://attest.apple.com and https://attest.development.apple.com due to network issues. These attempts have been made from both our internal corporate network and mobile hotspot environments. Despite adjusting DNS settings and other configurations, the issue persists. Are there alternative methods or solutions to address this problem? Any recommended network configurations or guidelines to successfully connect to Apple's App Attest servers would be greatly appreciated. Thank you.

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.

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.toptop.sea", # New Services 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!

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!

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"?

I keep getting invalid_client, here is a test login: https://www.bella-booking.ch/_get_incl/test_apple_login.cfm Any help appreciated. NOTE: Everey other error, like wrong reroute or wrong client id, a different error will be sent frpm apple, after I checked all and crosschecked with jwt.io, it keep getting invalid_client. Any clue? If the response is correct, the token should be displayed on the page. Thx

Hi! I'm trying to add Sign in with Apple to my macOS app. I enabled this capability from the developer portal and created the corresponding certificate & provisioning profile (both of type Developer ID Application.) However, Xcode keeps prompting me that the profile doesn't support Sign in with Apple. If I enable Automatically manage signing from Xcode, I can build and run the app but not distribute. If I turn it off and use the profile I got, it just keeps showing the errors below and doesn't even let me build.

Our organization operates a web platform that hosts numerous newspaper properties. We recently acquired a new newspaper and are in the process of integrating it into our platform. As part of this transition, we’ve successfully transferred the App and App ID for the acquired newspaper into our Apple Developer portal. However, no Service ID associated with Sign in with Apple was included in the transfer. Our current implementation uses a single, unified Service ID for all existing newspaper properties. This Service ID facilitates OAuth via a centralized Identity Server. The organization we acquired provided a CSV file containing a list of transport_ids, and based on our understanding, we’re expected to use the Apple endpoint: https://appleid.apple.com/auth/usermigrationinfo to initiate a registration process by submitting our Service ID (client_id) along with each transport ID. This step is required before users can sign in, and it should return the existing relay email address. We have a few key concerns: Service ID Compatibility It appears that users cannot be transferred between Service IDs. In our case, there are now two: a.) Our existing Service ID (used across all current newspaper properties) b.) A separate Service ID previously associated with the acquired newspaper 3.) Due to architectural constraints, our platform cannot dynamically toggle between multiple Apple Service IDs. All properties authenticate through our unified Identity Server bound to our existing Service ID. 4.) Is it possible to call /usermigrationinfo using our existing Service ID rather than the one originally used by the acquired property? 5.) Relay Email and Apple ID Consistency 6.) We’re seeing conflicting information about whether the Apple relay email address (@privaterelay.appleid.com) and the Apple user ID are preserved during this migration. Some sources suggest that the relay email and Apple ID are tightly coupled to both the Service ID and Team ID. 7.) If we call /usermigrationinfo with our existing Service ID, will the same relay email be returned, or will Apple issue a new one?

Please provide a descriptive title for your feedback: Downloading Developer ID provisioning profiles - missing new entitlements Which area are you seeing an issue with? App Store Connect What type of feedback are you reporting? Incorrect/Unexpected Behavior Please provide the App name/App ID if possible: com.onexengineering.themedeck.macos Please describe the issue and what steps we can take to reproduce it bug in App Store Connect where downloading Developer ID provisioning profiles are missing the new entitlements regenerated from scratch -- App Store Connect says entitlements are good, but actual file confirms entitlements are missing App Store provisioning profiles seem to be unaffected (ignore my incorrect naming of files)

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!

Dear Sir or Madam, Thank you for your continued support. My name is Sato from atmos. We are currently working with a vendor to implement Apple Sign In as a login method for our app, but we are encountering some issues and would like to contact you about them. The Apple Sign In functionality itself is almost complete, but during verification, email relay is not permitted by Apple when Apple Sign In is used with a non-public email address, making it impossible to complete email relay verification for users. We have reviewed the settings in “/account/resources/services/configure,” checked your FAQ, and explored all other possible solutions within our scope, but the situation remains unchanged. Would it be possible for your team to confirm the cause of the email relay not being permitted? Thank you for your assistance. atmos Sato Translated with DeepL.com (free version)

Hello, We’ve resumed the migration process after a break. Since my colleague is no longer with us, I had to go through the steps again myself. As before, we’re trying to migrate "Sign In with Apple" users from tenant TENANT_A with client_id=CLIENT_ID_A to tenant TENANT_B with client_id=CLIENT_ID_B I followed the procedure described here: [Apple Developer Documentation](https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer – Migrating Sign In with Apple Users, essentially repeating what my coworker previously attempted in coordination with your employee Stephanie. Here’s a summary of the steps and the issue we’re facing: STEP 1 - get authcode for TEAM A curl --location 'https://appleid.apple.com/auth/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=client_credentials' --data-urlencode 'scope=user.migration' --data-urlencode 'client_id=pl.CLIEND_ID_A' --data-urlencode 'client_secret=<TEAM_A_SECRET>' I receive response: { "access_token": "<ACCESS_TOKEN_TEAM_A>", "token_type": "Bearer", "expires_in": 3600 } STEP 2 - get authcode for TEAB B curl --location 'https://appleid.apple.com/auth/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=client_credentials' --data-urlencode 'scope=user.migration' --data-urlencode 'client_id=CLIENT_ID_B' --data-urlencode 'client_secret=<TEAB_B_SECRET>' I receive response: { "access_token":"<ACCESS_TOKEN_TEAB_B>", "token_type": "Bearer", "expires_in": 3600 } STEP 3 - get transfer_sub from TEAM A curl --location 'https://appleid.apple.com/auth/usermigrationinfo' --header 'Authorization: Bearer <ACCESS_TOKEN_TEAM_A>' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'client_id=CLIENT_ID_A' --data-urlencode 'client_secret=<TEAM_A_SECRET>' --data-urlencode 'sub=USER_SUB_FROM_TEAM_A' --data-urlencode 'target=TENANT_B' I receive response: { "transfer_sub": "USER_SUB_FROM_TEAM_B" } STEP 4 - Team B exchanges transfer identifers curl --location 'https://appleid.apple.com/auth/usermigrationinfo' --header 'Authorization: Bearer <ACCESS_TOKEN_TEAM_B' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'client_id=CLIENT_ID_B' --data-urlencode 'client_secret=<TEAM_B_SECRET>' I receive response: { "error": "invalid_request" } We’ve created a new client_id under tenant B and want to migrate users there. However, we skipped the step described in Step 3 of the documentation(https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer#3-Team-A-initiates-app-transfer-to-Team-B), which involves initiating an app transfer. The reason is that this client_id is used solely for web authentication, not for a mobile app, so we don’t have an app to transfer. Based on our analysis and your documentation, it seems this flow only works if the client_id matches across both tenants, which can only be achieved through an app transfer, something we cannot proceed with. Apple previously insisted that we migrate these users, but as shown above, we’re stuck. Is there any alternative flow available, or can you assist us in completing this migration?

Hello, I’m trying to set up Sign In with Apple for my Firebase Authentication integration. Steps I followed: Created a Service ID in Apple Developer, e.g. com.example.myapp.signin. Tried to enable Sign In with Apple and configure the Web Authentication Configuration. Web Domain: myapp.firebaseapp.com Return URL: https://myapp.firebaseapp.com/__/auth/handler When I click Save, I get the following error in the browser console and a blank response page: Unsupported Request PATCH to http://developer.apple.com/services-account/v1/bundleIds/XXXXXXXX not supported. Reference #... What I have verified so far: My Apple Developer Program membership is active (paid). My App ID (e.g. com.example.myapp) exists in Identifiers. The App ID has Sign In with Apple capability checked. I need to link the Service ID with this App ID for Firebase web-based auth. Goal: Complete setup of Apple as a sign-in provider in Firebase Authentication. To do this, Apple requires me to add the Firebase return URL above, but the Developer Portal prevents saving with the 501 error. Has anyone else run into this, and is there a workaround (e.g. enabling via Xcode, App Store Connect, or other methods)? Is this a known bug with the Apple Developer Portal? Here is the screenshot of the error: And Response part: Thanks in advance!

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": {} }

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.