Hi Community, We've implemented Sign In with Apple in our application. Our domains are properly registered in the developer console, but we're experiencing inconsistent email functionality with Apple's privacy email service. Some domains work correctly while others show delivery problems, even though all domains have identical configurations. Apple's console displays green verification status for all domains, yet testing reveals that emails to privacy-protected accounts don't arrive as expected. We're using SendGrid as our email service provider, and all domains have valid authentication records (SPF, DKIM, DMARC) in place. Has anyone encountered similar inconsistencies with Apple's privacy email service? Would appreciate any configuration tips or troubleshooting guidance. Thanks.

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

We implemented a feature to receive name and email address after Sign in with Apple, and it works perfectly in our testing. However, during the app review, they says it doesn't work, and the app is rejected. Why does it work differently?

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?

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

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)

As I had mentioned earlier, I was facing two issues after the initial update, but I’m happy to inform you that both of those issues have now been resolved. However, after updating to iOS 26.0 (23A5297m), I’ve started experiencing a new issue related to overheating. Since yesterday, my iPhone has been getting extremely hot while charging. It also became very hot after clicking just a few photos. The same heating issue occurred again today during charging. This problem only started after the latest update. Kindly look into this issue and advise on how to resolve it.

I have two applications, and I recently decided to add the Apple Sign In feature. Initially, I configured it for one of the apps as the Primary ID for this feature. Everything worked well, and I decided to add it to the second app. I made a mistake and used the First app as Primary ID using the "Group with an existing primary App ID" flag. Now, when I sign in using the second app, I don't see it in the list of apps in iPhone Settings for Apple Sign In; I only see the primary app. And with that, I no longer see a prompt for sharing/hiding email, and I am unable to revoke credentials correctly. I decided to change the Second app's Sign-in config and set it as the Primary ID for the feature. I was hoping to get two apps independent for the SignIn. However, it doesn't seem to make a difference. The second app behaves the same way, as long as the first app used SignIn, the second one always thinks that the user has already used that feature and never shows the correct prompt. Is there something I missed after changing the Configuration?

We have been sending emails through Sparkpost via Braze inc. to the Apple Private Relay users with "@privaterelay.appleid.com" starting from around June 20th or so. Upon August 9th 06:00 UTC, we have noticed a sudden increase of "Hard Bounce" for nearly 20,000 users using the Apple's private relay email address, rendering the email sending useless for these customers. We have been constantly been able to send them emails, including just before this timeframe (e.g. August 9th 03:00 UTC), so it was a very sudden purge of the user data that has been done without our consent. From a business perspective, this hurts a lot for the un-sendable users since we have no way of contacting them if not for the private address. We are desperate to know what has happened for these customers that has been "hard bounced". We are suspecting that it should be tied to the private email and the users primary email (or user data's) tie in the Apple server being gone, but not sure enough since there is no such documentation nor any way to acknowledge what has happened anywhere. We will provide any information possible for resolving. Thank you.

Migrating APP and users, obtaining the user's transfer_sub, an exception occurred: {"error":"invalid_request"} `POST /auth/usermigrationinfo HTTP/1.1 Host: appleid.apple.com Content-Type: application/x-www-form-urlencoded Authorization: Bearer {access_token} sub={sub}&target={recipient_team_id}&client_id={client_id}&client_secret={client_secret} The specific request is as follows: 15:56:20.858 AppleService - --> POST https://appleid.apple.com/auth/usermigrationinfo 15:56:20.858 AppleService - Content-Type: application/x-www-form-urlencoded 15:56:20.858 AppleService - Content-Length: 395 15:56:20.858 AppleService - Authorization: Bearer a56a8828048af48c0871e73b55d8910aa.0.rzvs.96uUcy1KBqo34Kj8qrPb4w 15:56:20.858 AppleService - 15:56:20.858 AppleService - sub=001315.1535dbadc15b472987acdf634719a06a.0600&target=WLN67KBBV8&client_id=com.hawatalk.live&client_secret=eyJraWQiOiIzODg5U1ZXNDM5IiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJRMzlUU1BHMjk3IiwiaWF0IjoxNzU1MDcxNzc5LCJleHAiOjE3NTUwNzUzNzksImF1ZCI6Imh0dHBzOi8vYXBwbGVpZC5hcHBsZS5jb20iLCJzdWIiOiJjb20uaGF3YXRhbGsubGl2ZSJ9.8i9RYIcepuIiEqOMu1OOAlmmjnB84AJueel21gNapiNa9pr3498Zkj8J5MUIzvvnvsvUJkKQjp_VvnsG_IIrTA 15:56:20.859 AppleService - --> END POST (395-byte body) 15:56:21.675 AppleService - <-- 400 Bad Request https://appleid.apple.com/auth/usermigrationinfo(816ms) 15:56:21.675 AppleService - Server: Apple 15:56:21.675 AppleService - Date: Wed, 13 Aug 2025 07:56:22 GMT 15:56:21.675 AppleService - Content-Type: application/json;charset=UTF-8 15:56:21.675 AppleService - Content-Length: 27 15:56:21.675 AppleService - Connection: keep-alive 15:56:21.675 AppleService - Pragma: no-cache 15:56:21.675 AppleService - Cache-Control: no-store 15:56:21.676 AppleService - 15:56:21.676 AppleService - {"error":"invalid_request"} 15:56:21.676 AppleService - <-- END HTTP (27-byte body) ` Current Team ID: Q39TSPG297 Recipient Team ID: WLN67KBBV8 CLIENT_ID: com.hawatalk.live

We are implementing authentication login in our iOS mobile application, and during the sign-in/sign-out process, a native system popup appears with the following message: "This allows the app and website to share information about you." This popup interrupts the user experience, and we are concerned it may cause confusion for end users and negatively impact the adoption of our login flow. We would like clarification on the following points: What triggers this popup during the authentication process? Are there any recommended configurations or approaches to suppress or avoid this dialog? If the popup cannot be avoided, what best practices are suggested to ensure a clear and seamless user experience? Our objective is to provide a smooth, user-friendly authentication flow without unexpected system interruptions.

Confirmation on "Sign in with Apple JS" Web Implementation Compatibility Hello Developers We are trying to implement "Sign in with Apple JS" on our e-commerce website, which is built on a SaaS platform called Ticimax in Turkey. Our platform provider (Ticimax) claims that a web-based implementation of "Sign in with Apple" is not currently possible. They state this is due to "Apple's browser security policies" that prevent consistent and secure support across all major browsers, particularly Safari with its privacy features. Could you please confirm if there are any fundamental security policies or technical restrictions imposed by Apple that would prevent a standard, secure implementation of "Sign in with Apple JS" on a typical e-commerce website? We know many global websites use this feature successfully. We need to know if our provider's claim has a technical basis from Apple's perspective, or if this is a standard implementation challenge that developers are expected to handle (e.g., using pop-ups instead of redirects to comply with ITP). Any official clarification or documentation you can provide on this matter would be greatly appreciated. Thank you.

I set up "Sign in with Apple" via REST API according to the documentation. I can log in on my website and everything looks fine for the user. But I receive an email, that my "Sign in with Apple" account has been rejected by my own website. It states, I will have to re-submit my name and email address the next time I log in to this website. I don't see any error messages, no log entries, no HTTP errors anywhere. I also can't find anything in the docs, the emails seem to not be mentioned there, searching for anything with "rejected" in the forum did not yield any helpful result, because they are always about App entries being rejected etc. Did someone experience something similar yet? What's the reason, I'm getting these emails? I get them every time I go through the "Sign in with Apple" flow on my website again.

Hey folks, I'm seeing an issue where my iOS app is getting an "unknown" error when US users try to sign in with Apple. It works fine for users in other countries like the UK, Singapore, and Taiwan. Could it be related to my developer account not being based in the US? Or have I missed something in my settings? 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": {} }

Hi, I followed step by step documentation to implement SignIn with Apple in iOS/Android application. I created an AppId com.nhp.queenergy, a related ServiceId com.nhp.queenergy.apple, and a KeyId. Authorization request is correctly performed by using ServiceId as client_id and my backend redirect_uri I receive code on my backend Token request is performed by using ServiceId as client_id, same redirect_uri, the code I have just received and the client_secret as JWT signed with my .p8 certificate with the following decoded structure Header { "kid": , "typ": "JWT", "alg": "ES256" } Payload { "iss": , "sub": "com.nhp.queenergy.apple", "aud": "https://appleid.apple.com", "exp": 1756113744, "iat": 1756111944 } I always receive "invalid_grant" error without any further error description. Moreover the error is always the same even though I use any fake string as client secret. If the code expires, as expected the error changes by adding "The code has expired or has been revoked." I really don't know how to solve this issue Best regards

Hello everyone, I'm encountering a persistent 503 Server Temporarily Not Available error when trying to implement "Sign in with Apple" for my web application. I've already performed a full review of my configuration and I'm confident it's set up correctly, which makes this server-side error particularly confusing. Problem Description: Our web application uses Firebase Authentication to handle the "Sign in with Apple" flow. When a user clicks the sign-in button, they are correctly redirected to the appleid.apple.com authorization page. However, instead of seeing the login prompt, the page immediately displays a 503 Server Temporarily Not Available error. This is the redirect URL being generated (with the state parameter truncated for security): https://appleid.apple.com/auth/authorize?response_type=code&client_id=XXXXXX&redirect_uri=https%3A%2F%2FXXXXXX.firebaseapp.com%2F__%2Fauth%2Fhandler&state=AMbdmDk...&scope=email%20name&response_mode=form_post Troubleshooting Steps Performed: Initially, I was receiving an invalid_client error, which prompted me to meticulously verify every part of my setup. I have confirmed the following: App ID Configuration: The "Sign in with Apple" capability is enabled for our primary App ID. Services ID Configuration: We have a Services ID configured specifically for this. The "Sign in with Apple" feature is enabled on this Services ID. The domain is registered and verified under "Domains and Subdomains". Firebase Settings Match Apple Settings: The Services ID from Apple is used as the Client ID in our Firebase configuration. The Team ID is correct. We have generated a private key, and both the Key ID and the .p8 file have been correctly uploaded to Firebase. The key is not revoked in the Apple Developer portal. Since the redirect to Apple is happening with the correct client_id and redirect_uri, and the error is a 5xx server error (not a 4xx client error like invalid_client), I believe our configuration is correct and the issue might be on Apple's end. This has been happening consistently for some time. My Questions: What could be causing a persistent 503 Server Temporarily Not Available error on the /auth/authorize endpoint when all client-side configurations appear to be correct? What is the formal process for opening a technical support ticket (TSI) directly with Apple Developer Support for an issue like this? Thank you for any insights or help you can provide.

Hello Developers, I have ran into a problem while sending mail to apple private relay email. We have built a mobile application where user can sign up through apple and they can sign up using hide-my-email feature. Which provides private relay address for us. Now we want to communicate with them using private relay mail address. The technology we are using to send emails are amazon SES, have done SPF, DMIK, DMARC and added domains in apple identity services for mail communication, passed an SPF check as well. But still mail is not getting delivered what am i doing wrong or apple doesn't support third party apps for sending emails to private relay? Is there any other way to achieve this please let me know Using the same body as attached in image is working fine for rest emails.