I’m trying to update the Domains and Redirects section for my Services ID configuration in Apple Developer (for Sign in with Apple). When I add new domains and click Save, nothing happens. In the browser console, I see a network request that fails with: PATCH not supported What I’ve tried so far: Logging out/in and refreshing the page Clearing browser cache and cookies Trying in Safari, Chrome, and incognito mode Verifying domain formatting (HTTPS, no trailing slash, domain is live) The issue persists in all browsers I’ve tested. Request: Is this a known issue with the Developer portal, or is there an alternative method to update my Services ID domains? Any guidance would be appreciated. Thanks,

Hello, I’m trying to remove the “Sign in with Apple” for my app via the iOS settings (also tried on a Mac, and on the web via account.apple.com). When I tap “Stop Using”, nothing happens, the dialog disappear but the app remains listed. Someone said on a forum that the issue is linked with the ServiceId that doesn't exist anymore. But how to recover it ? And anyway this behavior is unintended and creates a gap in the process. Has anyone experienced this before? Is there a known fix, or should I contact Apple Support directly for server-side revocation? Thank you!

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?

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.

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!

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)

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?

Our app uses Sign in with Apple. In recent weeks (or months), we've noticed that emails sent to @privaterelay.appleid.com addresses are not being delivered. We're not receiving any bouncebacks or error messages from the mail server, but the emails never reach the user's mailbox. We've also checked spam folders, with no luck. We have verified that our Email Sources are configured correctly in Apple Developer settings. Is there any way to debug or trace what might be happening with these messages? Thanks in advance!

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.

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?

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

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

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?

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.

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!

Hi Apple Developer Support, We are implementing Sign in with Apple for our web application hosted on example.com. In the Service ID settings, we have configured the following: Service ID (client_id): com.example.service.local Web Domain: example.com Return URL: https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple We also tested login via the following URL from our web application: https://appleid.apple.com/auth/authorize?response_mode=form_post&response_type=code&client_id=com.example.service.local&scope=name%20email&state=2f9gMY1rTe12-O7Wbnb7KWe504HQ0KWBSHTKHbg9ZEY=&redirect_uri=https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple However, we’re receiving an invalid_client error after submission. Our questions: Is it valid to use an ngrok URL like https://2db2-121-160-153-88.ngrok-free.app/... as the Return URL for development and testing? Does the Web Domain need to match the ngrok domain, or is it enough to register the production domain (e.g., example.com)? Is there any propagation delay or approval process after updating the Return URL in the Service ID? Is the client_id strictly required to match the Service ID exactly? We would greatly appreciate any insights or best practices to help us resolve this issue. Thank you in advance!

On Wednesday, June 18, 2025, Sign in with Apple was impacted by a configuration issue which affected some developer accounts that created new app or Services ID configurations, or edited existing configurations, resulting in the following errors: invalid_client response error returned by the authentication, token validation/revocation, and user migration requests "Sign Up Not Completed" (or equivalent) error presented from the Authentication Services framework. On Monday, June 23, 2025, this issue was resolved. Please retry the Sign in with Apple flows in your Sign in with Apple enabled apps and websites to confirm your developer account configuration has been fixed. Please let us know if you can still reproduce this issue with your developer account. If so, follow the steps outlined in the post below: Gathering required information for troubleshooting Sign in with Apple authorization and token requests https://developer.apple.com/forums/thread/762831 Finally, reply (not comment) with your Feedback ID on either of the posts below: https://developer.apple.com/forums/thread/789011 https://developer.apple.com/forums/thread/789132 Cheers, Paris X Pinkney |  WWDR | DTS Engineer

On Thursday, June 12, 2025, Sign in with Apple was impacted by an incorrect subdomain defined in its /.well-known/openid-configuration file. The JSON returned incorrectly provided https://account.apple.com instead of the expected https://appleid.apple.com. For Sign in with Apple, the value for the issuer (iss) claim in the user's identity token is https://appleid.apple.com. Additionally, if your clients use the Sign in with Apple REST API, the following endpoints should be used for each request: https://appleid.apple.com/auth/authorize https://appleid.apple.com/auth/token https://appleid.apple.com/auth/revoke https://appleid.apple.com/auth/keys This issue with the /.well-known/openid-configuration file was resolved the same day. Use the URL below to confirm the expected subdomain is provided, as needed: https://appleid.apple.com/.well-known/openid-configuration Cheers, Paris X Pinkney |  WWDR | DTS Engineer

I've been fighting this issue for 3 days now. After several failures, I created a new app id and service id yesterday. I checked and entered domain, callback, and login usage clearly, but it keeps returning an error. Can you help me figure out what's wrong? https://appleid.apple.com/auth/authorize?response_type=code&client_id=com.smoothmail.signin&redirect_uri=https%3A%2F%2Fsmoothmail.store%2Fapple-auth&state=4157daa763&scope=name+email&response_mode=form_post