We would like to implement Platform SSO with the new web authentication. Where is the protocol documented? I have the documentation from prior versions of PSSO but would like to see the updated documentation.

In the WWDC 2021 session Mitigate fraud with App Attest and DeviceCheck it is said that: App Attest is supported on devices that have a Secure Enclave, but there are cases, such as app extensions, where isSupported will still return false. The documentation shows that the following Macs have a Secure Enclave: MacBook Pro computers with Touch Bar (2016 and 2017) that contain the Apple T1 Chip Intel-based Mac computers that contain the Apple T2 Security Chip Mac computers with Apple silicon I'm using a 2018 15" MacBook Pro containing a T2 Security Chip for testing, however, DCAppAttestService.shared.isSupported always returns false in native macOS or Catalyst apps. DCDevice.current.isSupported also returns false. The documentation for DCAppAttestService shows availability on "macOS 11.0+" and "Mac Catalyst 14.0+". It appears to have been added in the macOS 11.3 SDK included in Xcode 12.5. DCDevice shows availability on "macOS 10.15+" and "Mac Catalyst 13.0+". Although both APIs are available on the listed OSes, I only ever see isSupported == false. Are App Attest or DeviceCheck functional on any Macs? If so: Are there more specific Macs that support the feature (e.g., Apple Silicon Macs only)? Are there any additional steps that need to be taken to use them (e.g., changes to entitlements, provisioning profiles or distribution through the Mac App Store)? In native macOS apps, it doesn't actually appear to be possible to add the App Attest capability in Xcode under "Signing & Capabilities". If not, I think it would be good to update the documentation with this limitation since I'd expect them to work based on the availability being "macOS 10.15+" or "macOS 11.0+" for DeviceCheck and App Attest, respectively. I imagine most others would make the same assumptions.

Hi, it's very urgency! https://developer.apple.com/forums/thread/818346 After long time preparation, We finally execute this transfer operation today. Works fine at preliminary stage, lots of users had been transferred successfully. However, about 25% users transferred failed at the end, 'invalid_request' response from https://appleid.apple.com/auth/usermigrationinfo. No matter how many times we retry, it does work. Please help! 700,000 users are waiting us!

Hello Everyone I'm encountering a problem with the Apple Mail Private. I created a website with the possibility to log in with apple account and apple gives the possibility to privatize the mail address with xxxxx@privaterelay. appleid.com but also blocked the mail come from my server. In the log I get the error: relay=smtp3.privaterelay. appleid.com[17.56.9.14]:25, delay=2.4, delays=0.11/0/1.8/0.48, dsn=5.1.1, status=bounced (host smtp3.privaterelay. appleid.com[17.56.9.14] said: 550 5.1.1 mymail@mail. com: unauthorized sender (in reply to RCPT TO command)) How can I fix it ?

Hello, We are preparing to transfer an App Store app from one Apple Developer account/team to another. Our iOS app uses Sign in with Apple. However, in our legacy implementation, we did not store the Apple user subject identifier (sub) for many existing Apple login users. Our service primarily matched users by email. After reviewing Apple’s app transfer and Sign in with Apple migration documentation, we understood that we should generate a transfer identifier for each Sign in with Apple user before transferring the app. We have now started collecting and storing the sub value, but many legacy Apple login users still do not have their original sub value stored in our database. We are concerned about two main cases: Legacy users whose original Apple sub value was never stored For these users, we may not be able to generate the required transfer identifier before the app transfer. If the user uses Private Relay, we are also concerned that the email address we receive after the transfer may not match the email address we previously stored. In that case, our backend may not be able to match the post-transfer Sign in with Apple login to the user’s existing account, and the user may be treated as a new account. Users whose sub value is stored, but who do not sign in during the migration period For some users, we do have the Apple sub value and may be able to generate the transfer identifier before the app transfer. However, we are not sure what happens if those users do not sign in during the available Sign in with Apple migration period after the app transfer. If they sign in only after that period has ended, will the post-transfer Sign in with Apple user still be reliably mapped to the original pre-transfer user? The scenario we are worried about is: A user originally signed in with Apple before the app transfer. The app is transferred to another Apple Developer account/team. The user does not sign in during the Sign in with Apple migration period. After the migration period has ended, the same user signs in with Apple again. Our backend receives a new Apple user identifier and/or a different Private Relay email address. Our backend cannot correlate that login with the user’s original service account. The user may be treated as a new user and may lose access to their existing profile, activity history, chats, purchases, or other account data. Could someone confirm the expected behavior? Questions: If we have a legacy sub value and generate the transfer identifier before the app transfer, can the user still be mapped to the original account if they do not sign in during the Sign in with Apple migration period? After the migration period has ended, does Apple provide any identifier, token claim, API response, or other mechanism that allows us to correlate the post-transfer Sign in with Apple user with the pre-transfer user? For legacy users whose original sub value was never stored, is there any Apple-provided way to recover or map those users after the app transfer? Can a Private Relay email address change as part of or after an App Store app transfer? Should we avoid using email as a stable identifier for this migration? Should we delay the app transfer until we implement our own account recovery and account re-linking flow for all Sign in with Apple users? Environment: Platform: iOS Development environment: Xcode Runtime: iOS Framework: AuthenticationServices Feature: Sign in with Apple Context: App Store Connect app transfer between Apple Developer teams/accounts This issue does not appear to be specific to a particular iOS or Xcode version. We expect the development and runtime environments to be using the latest available versions of Xcode, macOS, and iOS at the time of submission. Any guidance on the correct migration behavior and the recommended implementation approach would be greatly appreciated.

Hello everyone, We are currently preparing for an App Transfer to a new Apple Developer account due to a corporate merger. We are trying to figure out the best way to handle Apple Sign-In user migration and would love to get some advice on our proposed fallback plan. 📌 Current Situation We need to transfer our app's ownership to a new corporate entity. The app heavily relies on Apple Sign-In. The Issue: We did not collect the transfer_sub values during our initial development phase. Although we started collecting them recently, we will not have them for all existing users by the time the transfer happens. 🚨 The Risk (The 60-Day Rule) Based on Apple's documentation, even if we provide the transfer_sub, users must log into the app within 60 days of the transfer to successfully migrate their accounts. This means that users who log in after 60 days, or those whose transfer_sub is missing, will fail the Apple migration process. They will be treated as "new users" and will lose access to their existing account data. 💡 Our Proposed Custom Recovery Flow Since we cannot rely entirely on Apple's automated migration, we are planning to build a custom internal account recovery process to prevent user drop-off: A user (who failed the migration or logged in after 60 days) attempts to use Apple Sign-In on the transferred app. Since the existing account isn't linked, Apple generates a new identifier (sub), and the user enters the new sign-up flow. During the sign-up process, we enforce a mandatory identity verification step (e.g., SMS phone number verification). We query our existing user database using this verified information. If a matching existing user is found: We interrupt the sign-up process and display a prompt: "An existing account was found. We will link your account." We then update our database by mapping the new Apple sub value to their existing account record, allowing them to log in seamlessly. ❓ My Questions App Review Risk: Could this manual mapping approach—overwriting the Apple sub on an existing account based on internal identity verification—violate any Apple guidelines or result in an App Store rejection? Shared Experiences: Has anyone dealt with missing transfer_sub values or the 60-day migration limit during an App Transfer? How did you mitigate user loss? Best Practices: Are there any alternative, safer, or more recommended workarounds for this scenario?

Hello everyone, I’m trying to better understand the expected behavior of Sign in with Apple after an app is transferred to another Apple Developer Team. Specifically, my question is about users who do not open or sign in to the app during the 60-day migration period after the app transfer. Here is the scenario we are concerned about: An existing user created an account using Sign in with Apple. The user is using a private relay email address. The app is transferred to another Apple Developer Team. The user does not sign in during the 60-day migration period. The user signs in again only after the 60-day period has ended. In this situation, is there any possibility that Apple may provide different user-related values compared to the values before the app transfer? For example, I am referring to values such as: sub private relay email address ID token claims any other API response value that may be used to identify the user The reason I’m asking is that if any of these values change after the transfer, our backend may not be able to match the user to the existing account in our database. In that case, the user could incorrectly be treated as a new user. My understanding is that the purpose of the Sign in with Apple migration process after an app transfer is to associate the user identifier from the original Team with the user identifier for the new Team. However, I would like to confirm what happens if the user was not processed during the 60-day migration period and signs in later. Do the values provided by Apple remain consistent in this case, or can they change after the migration period ends? If they can change, should we prepare our own account recovery or re-linking flow to handle these users? I would appreciate any clarification on Apple’s expected behavior and the recommended approach for this case. Thank you.

During PSSO User Registration, we use ASWebAuthenticationSession for OIDC. If the user's default browser isn't Safari (e.g., Chrome), the browser window stays stuck on top of the PSSO UI after authentication. This confuses users because they can't see the final PSSO registration screen. Are there any native macOS window-management APIs we can call inside the session's completion handler to force the PSSO window back to the foreground?

I saw the "Authenticated Guest Mode on iPad" in macOS 27. Is this related to PSSO Authenticated Guest Mode on macOS? Does it require cloud binding for a machine account like on macOS? How is it related to Shared iPad? Shared iPad requires supervised mode. Is there a new profile and keys? Where is this documented? Can you share information about how it works and how it can be tested?

There wasn't any update on the tap to login. Has the spec on tap to login been finalized? Can wallet passes now be issued to authenticate to macOS using tap to login?

Are there current plans to implement Microsoft 365 groups with Platform SSO to control administrator access in macOS 27? If so, would you be able to provide a rough estimate of when we can expect changes to be implemented by identity providers?

When a host app hasn't implemented ATT at all — which is still common in enterprise apps — what's the expected behavior for third-party SDKs that rely on tracking authorization? Should the SDK default to notDetermined handling indefinitely, or is there a recommended fallback experience?

For a third-party ads SDK embedded in host apps: the ATT authorization status is determined at the app level, but our SDK initializes before the host app necessarily calls ATTrackingManager.requestTrackingAuthorization(). What's Apple's recommended pattern for: SDK initialization that's ATT-status-agnostic at launch Receiving a callback or notification when ATT status changes post-initialization, without polling Is there a system notification or delegate pattern for ATT status changes that SDKs should be using in iOS 27? — Divya Ravi, Senior iOS Engineer

Are there any mechanisms to troubleshoot or test SiwA server-to-server notifications? I am not seeing any traffic from Apple for user account changes (e.g., revoking authorization for an app), but the URL that I have configured in my account matches my endpoint, it is available from the public internet, and other SiwA functions are working correctly. Any guidance will be appreciated.

Throughout the years I've done a few integrations at my company with an iOS Application and an identity provider. I've implemented samples with UIWebView, WKWebview, Certificate based authentication through custom URLSession implementations and lastly through ASWebAuthentication. Also I gave the SSO Extension a try, but got stuck at some point (also Apple Forum didn't give me some solution -> https://developer.apple.com/forums/thread/117747) I'm having troubles digging through the Apple resources to find the best approach for big enterprises. We make use of a MDM solution, so I was hoping to find means to 'exploit it' and don't implement any custom authenticationframework anymore. Also, granting SSO between Apps and websites is what my ideal goal would be. Could you point me to some resources that can help me or give me some guidance on which of the frameworks/SDKs to use?

Future of Behavioral Authentication on Apple PlatformsWith the rapid advancement of on-device AI and Apple Intelligence, does Apple see a future where user identity can be continuously verified through behavioral patterns and contextual signals rather than relying solely on discrete authentication events such as Face ID, Touch ID, or passcodes? If so, what privacy and security challenges would need to be solved before such an approach could become practical on Apple platforms?

do you see a future where devices continuously verify a user’s identity through behavioral signals rather than discrete login events?

with the advancement of on-device ai, do you see a future where devices continuously verify a user’s identity through behavioral patterns rather than discrete authentication events such as Face ID or password entry?

With the rapid advancement of on-device AI and Apple Intelligence, does Apple see a future where user identity can be continuously verified through behavioral patterns and contextual signals rather than relying solely on discrete authentication events such as Face ID, Touch ID, or passcodes? If so, what privacy, security, and battery-efficiency challenges would need to be solved before such an approach could become practical on Apple platforms?

Are there any Kerberos feature or behavior changes in macOS 27?