Hi everyone, I am currently implementing Server-to-Server Notifications for Sign in with Apple. I’ve encountered a discrepancy between the official documentation and the actual payload I received, and I would like to clarify which one is correct. The Situation: I triggered an account deletion event via privacy.apple.com to test the notification flow. When my server received the notification, the type field in the JSON payload was account-deleted (past tense). The Issue: According to the official Apple documentation, the event type is listed as account-delete (present tense). Here is the discrepancy I am observing: Documentation: account-delete Actual Payload: account-deleted My Question: Is the documentation outdated, or is this a known inconsistency? Should I handle both strings (account-delete and account-deleted) in my backend logic to be safe, or is account-deleted the new standard? Any insights or confirmation from those who have implemented this would be greatly appreciated. Thanks!

I read online that there is no way to extract the call log from an iPhone. I want to develop an app to help people remember to call their mom, and if they did, the "nagging" would disappear automatically. I'm looking for any workaround to know when a user called someone, without having them log it manually.

We're experiencing crashes in our production iOS app related to Apple's DeviceCheck framework. The crash occurs in DCAnalytics internal performance tracking, affecting some specific versions of iOS 18 (18.4.1, 18.5.0). Crash Signature CoreFoundation: -[__NSDictionaryM setObject:forKeyedSubscript:] + 460 DeviceCheck: -[DCAnalytics sendPerformanceForCategory:eventType:] + 236 Observed Patterns Scenario 1 - Token Generation: Crashed: com.appQueue EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000010 DeviceCheck: -[DCDevice generateTokenWithCompletionHandler:] Thread: Background dispatch queue Scenario 2 - Support Check: Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000008 DeviceCheck: -[DCDevice _isSupportedReturningError:] DeviceCheck: -[DCDevice isSupported] Thread: Main thread Root Cause Analysis The DCAnalytics component within DeviceCheck attempts to insert a nil value into an NSMutableDictionary when recording performance metrics, indicating missing nil validation before dictionary operations. Reproduction Context Crashes occur during standard DeviceCheck API usage: Calling DCDevice.isSupported property Calling DCDevice.generateToken(completionHandler:) (triggered by Firebase App Check SDK) Both operations invoke internal analytics that fail with nil insertion attempts. Concurrency Considerations We've implemented sequential access guards around DeviceCheck token generation to prevent race conditions, yet crashes persist. This suggests the issue likely originates within the DeviceCheck framework's internal implementation rather than concurrent access from our application code. Note: Scenario 2 occurs through Firebase SDK's App Check integration, which internally uses DeviceCheck for attestation. Request Can Apple engineering confirm if this is a known issue with DeviceCheck's analytics subsystem? Is there a recommended workaround to disable DCAnalytics or ensure thread-safe DeviceCheck API usage? Any guidance on preventing these crashes would be appreciated.

Hello, I am implementing "Sign in with Apple" on my backend and validating the Identity Token (JWT) received from the client. I noticed that for some users who choose the "Hide My Email" option, the is_private_email claim is missing from the ID Token payload, even though the email address clearly belongs to the private relay domain (@privaterelay.appleid.com). Here is an example of the decoded payload I received: { "iss": "https://appleid.apple.com", "aud": "com.platform.elderberry.new.signinwithapple", "exp": 1764402438, "iat": 1764316038, "sub": "000851.86193ef81ad247feb673746c19424f28.0747", "c_hash": "3FAJNf4TILzUgo_YFe4E0Q", "email": "x8sqp2dgvv@privaterelay.appleid.com", "email_verified": true, "auth_time": 1764316038, "nonce_supported": true // "is_private_email": true <-- This field is missing } My Questions: Is the is_private_email claim considered optional in the ID Token? Is it safe and recommended to rely solely on the email domain suffix (@privaterelay.appleid.com) to identify if a user is using a private email? Any insights or official references would be appreciated. Thanks.

Hello, I am implementing "Sign in with Apple" on my backend and validating the Identity Token (JWT) received from the client. I noticed that for some users who choose the "Hide My Email" option, the is_private_email claim is missing from the ID Token payload, even though the email address clearly belongs to the private relay domain (@privaterelay.appleid.com). Here is an example of the decoded payload I received: { "iss": "https://appleid.apple.com", "aud": "xxx", "exp": 1764402438, "iat": 1764316038, "sub": "xxxxxxxx", "c_hash": "3FAJNf4TILzUgo_YFe4E0Q", "email": "xxx@privaterelay.appleid.com", "email_verified": true, "auth_time": 1764316038, "nonce_supported": true // "is_private_email": true <-- This field is missing } My Questions: Is the is_private_email claim considered optional in the ID Token? Is it safe and recommended to rely solely on the email domain suffix (@privaterelay.appleid.com) to identify if a user is using a private email? Any insights or official references would be appreciated. Thanks.

Our background monitoring application uses a Unix executable that requests Screen Recording permission via CGRequestScreenCaptureAccess(). This worked correctly in macOS Tahoe 26.0.1, but broke in 26.1. Issue: After calling CGRequestScreenCaptureAccess() in macOS Tahoe 26.1: System dialog appears and opens System Settings Our executable does NOT appear in the Screen Recording list Manually adding via "+" button grants permission internally, but the executable still doesn't show in the UI Users cannot verify or revoke permissions Background: Unix executable runs as a background process (not from Terminal) Uses Accessibility APIs to retrieve window titles Same issue occurs with Full Disk Access permissions Environment: macOS Tahoe 26.1 (worked in 26.0.1) Background process (not launched from Terminal) Questions: Is this a bug or intentional design change in 26.1? What's the recommended approach for background executables to properly register with TCC? Are there specific requirements (Info.plist, etc.) needed? This significantly impacts user experience as they cannot manage permissions through the UI. Any guidance would be greatly appreciated. Thank you

I’m using Sign in with Apple in my iOS app. When a user chooses “Hide My Email”, I receive the @privaterelay.appleid.com relay address. For marketing reasons, I would prefer to have the user’s real email address instead of the relay email. I want to stay compliant with App Store Review and the Sign in with Apple design/UX requirements. My questions are: Is it allowed to force the user (as part of the registration process) to provide their real email address, even if they chose “Hide My Email” during Sign in with Apple? Are there any specific App Store Review guidelines that forbid: Blocking sign up or access to features if the user keeps the relay email, or Showing a strong prompt like “We can’t log you in unless you share your real email”? What is the recommended, compliant pattern for collecting a “real” email when using Sign in with Apple + Private Relay? I’d appreciate any official clarification or examples of what App Review considers acceptable vs. reject-worthy here.

Hi, I’ve added attestation to my app, and everything worked as expected during setup. However, after deployment, I noticed some unknownSystemFailure entries in the production logs on New Relic. Could you help me understand what typically causes this error? The documentation suggests issues such as failing to generate a token. What scenarios could lead to that?

I have reached out to support and they simply tell me they are unable to help me, first redirecting me to generic Apple support, after following up they provided the explanation that they only handle administrative tasks and to post on the forums. I am unable to change my App Tracking Transparency it provides no real error, though network traffic shows a 409 HTTP response from the backend API when trying to save. Here is a screenshot of the result when trying to save. Does anyone have any suggestions on how to get this resolved? I've commented back to the reviewers and they simply provided help documentation. I have a technical issue and am unable to get anyone to help resolve this.

Hello I am trying to release an application using EXPO ROUTER + EXPO RN WEB. I am trying to implement Apple Login using Firebase. I have already put necessary info in both App Store Connect and Firebas console. Now I am so confused what I have to do next. What are some resource I could use or tips you could possibly give me when making apple login available using firebase. Pleas all helps are welcomed and needed

Hi Apple, Currently we want to have enhancement for SMS OTP that we want to implement OTP Autofill, But after do some research we're stuck with option that the OTP only show in keyboard suggestion, is there any way for making OTP is automatically filled without user have to click the keyboard suggestion when receiving the SMS. Thanks Best Regards, Admiral Sultano Harly.

Hi. I enter a password using the security command at the command line. It appears in the keychain access app, but not in the passwords app. I don't understand why. rickhedin@Ricks-MacBook-Pro zalando % security add-generic-password -U -s "birds" -a "cats" -w "dogs" rickhedin@Ricks-MacBook-Pro zalando % rickhedin@Ricks-MacBook-Pro zalando % security find-generic-password -s "birds" -wa "cats" dogs rickhedin@Ricks-MacBook-Pro zalando % I'm told the two apps are two views of the same data, so I guess some filter must be being applied?

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!

Goal I want to reply to feedback from customers who signed up using a private.relay account. Problem I am getting this error when sending an email: Reporting-MTA: dns; mailfout.stl.internal X-Postfix-Queue-ID: B87481D0015B X-Postfix-Sender: rfc822; hello@mydomain.com Arrival-Date: Fri, 7 Nov 2025 03:37:29 -0500 (EST) Final-Recipient: rfc822; xxxx@privaterelay.appleid.com Original-Recipient: rfc822;xxxx@privaterelay.appleid.com Action: failed Status: 5.1.1 Remote-MTA: dns; smtp3.privaterelay.appleid.com Diagnostic-Code: smtp; 550 5.1.1 <hello@mydomain.com>: unauthorized sender What have I done? I have configured mydomain.com in the Email Configuration Service inside of apple, as well as the email hello@mydomain.com. Using https://www.mail-tester.com/, I could confirm that the - [SPF] Your server 202.12.124.158 is authorized to use hello@mydomain.com - Your DKIM signature is valid - Your message passed the DMARC test My hunch This app was transferred and the previous owner did not have the email configuration set up. The emails I am writing messages to signed up at that time. Questions: If I rescue the old account and set up the email configuration, would it work? Is there any other tip I could try to apply?

If a user triggers account revoke on their Apple ID—but does not perform an in-app account deletion—will Apple send a server-to-server notification to inform us of this revoke event? Additionally, in this scenario, if the user later wants to restore access to their existing game account data (for example, by re-binding Sign in with Apple or switching to another login method), are developers expected to restore all previously linked game data, or should the revoke event be treated as a permanent loss of authorization?

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

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. 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!