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.

Hi, We are operating a service that uses Sign in with Apple for user registration and login. As part of our security incident response and periodic security improvements, we are planning to rotate the private key used to generate the client secret (JWT) for Sign in with Apple. I have read the Human Interface Guidelines and the AuthenticationServices documentation, but I could not find a clear description of the behavior and user impact when rotating this private key. I would like to ask the following questions: Background: We issue a Sign in with Apple private key (with a Key ID) in our Apple Developer account. Our server uses this private key to generate the client secret (JWT). This is used for Sign in with Apple login on our web / mobile app. We are planning to invalidate the existing private key and switch to a newly issued one. Questions: Impact on existing logged-in sessions Will rotating the private key force already logged-in users (who previously signed in with Apple) to be logged out from our service? Can the user identifier (such as the "sub" claim) for existing Sign in with Apple users change due to key rotation? Recommended frequency and best practices Does Apple recommend rotating this private key only when it is compromised, or on a regular basis? If there are any official documents or examples that describe how to safely perform key rotation in production, we would appreciate a pointer. Impact on marketing / analytics We are using user IDs (linked via Sign in with Apple) for analytics and marketing attribution. Is there any expected impact on such use cases caused by rotating the private key? For example, is there any possibility that user identifiers change as a result of key rotation, or anything we should be careful about from a data linkage perspective? Our goal is to rotate the private key in a secure way without causing service downtime, mass logouts, or loss of account linkage. If there is already an official document that covers this, please let me know the URL. Thank you in advance.

Hello. When a user revokes Apple Login authorization, I am expecting a webhook to be delivered to our configured endpoint, but I currently not receiving any at all. So I have some questions: Should the revoke event webhook be delivered in real-time? If it is not real-time, when is the webhook supposed to be sent? If my server fails to respond to the webhook request, does Apple retry the delivery? (Actually I couldn't find how to response in this scenario, but if I can) Thanks in advance.

I want to add the "Sign In with Apple" feature to my iPadOS application. I've already done the following: Include com.apple.developer.applesignin in mobileprovision Include com.apple.developer.applesignin in entitlements However, I'm getting the following errors: `Authorization failed: Error Domain=AKAuthenticationError Code=-7026 "(null)" UserInfo={AKClientBundleID=xxxx} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={_LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler, _LSFile=LSDReadService.mm, NSDebugDescription=process may not map database} 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={_LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler, _LSFile=LSDReadService.mm, NSDebugDescription=process may not map database} 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)" ` What is this problem? How can I solve it? Hoping someone can help, thank you!

https://developer.apple.com/news/?id=j9zukcr6 starting from Jan 2026 there is change in requirements for account notifications for Sign in with Apple. Does this apply only to developers based in South Korea or all apps which are avai via the korean App Store?

"I am attempting to read and write data to an Office Group Container, and I am consistently prompted with the "App would like to access data from other apps" alert. How can I configure the application or environment to suppress this repeated permission prompt?"

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!

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.

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.

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, I'm trying to implement web-browser SignIn with Apple with my new app. I'm trying to "Associate your website to your app" like described in this doc: https://developer.apple.com/help/account/capabilities/configure-sign-in-with-apple-for-the-web So I created a Service ID for this specific login. I want this login page to display my app icon and name when presented to users. My issue: When I associate my new app the the service, the link is somehow not working. The login page show the "service" login (with a generic apple logo and the Service ID's name) instead of the actual App name. I'v been able to link my new service to older apps succesfully !!! (the login page correctly shows the old apps icons and names) Why is my new app not associated with the service ? I am missing something here ? is there an additionnal step that I need to take in order to link the service to my newest app ? Thanks !

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 everyone! We are from Russia, and we no longer have an official Apple store. All phones are imported through parallel imports. Yesterday, my wife logged out of her Apple ID and logged in to someone else's account, and as a result, her phone was in lost and locked mode. We have a sales receipt confirming the purchase, but it is from a Russian store. Can you please tell me if there is a way to unlock the phone or if it is already a brick? Scammers are asking for money to unlock the phone. Thank you in advance for your reply!

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

Hi, we are having Sign in with Apple issues. For a large % of new users on our app which select this option, the first name and last name values are not being passed to us. This is the case in both scenarios - where the user shares their email address or hides it, and happens on iPhone when the user selects the default iCloud account. We're unclear why this is occurring.

Recently I am trying to implement apple oauth in expo web version, I created the service id and other related info, i have issue @PostMapping("/callback") public ResponseEntity handleAppleCallback(@RequestParam Map<String, String> body) { String code = body.get("code"); String idToken = body.get("id_token"); if (code == null) { return ResponseEntity.badRequest().build(); } // Redirect to your Expo Web app with the code in query String frontendUrl = "https://mobile-dot-dev-epicportal.uc.r.appspot.com/apple-callback?code=" + code; return ResponseEntity.status(HttpStatus.FOUND) .header("Location", frontendUrl) .build(); } when i pass the code recived from apple to this route i am getting invalid_grant i am not sure what is wrong here

I no longer have an app on the store. I do have an apple books account on the same login but there's no need for me to have the appstore connect account or whatever you call it and keep getting notifications when I don't have an app, don't want an app, will never do another app.

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.

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!