Apple’s developer news page now carries a notice, dated 24 August 2026, that is easy to miss and easy to get wrong: later this year, new Sign in with Apple private relay addresses will use the domain private.icloud.com instead of privaterelay.appleid.com. Apple has not given an exact date in the notice.
What stays the same
- Existing relay addresses keep working. Nobody’s current login breaks.
- iCloud+ Hide My Email addresses remain on
icloud.com.
What can break
The risk is not in the Apple button. It is in the systems behind your app that treat the email address as data:
- Sign-up forms or APIs that reject unfamiliar domains.
- Allowlists or blocklists of “known” relay domains, often used for fraud checks or to route marketing consent.
- Email delivery settings that only authorise mail to the old relay domain.
- Analytics or CRM rules that tag relay users by domain.
Apple’s guidance is to update account systems, email validation logic and allowlists to accept both domains. Any user who signs up after the change will arrive with an address your code has never seen.
Why founders should care
This is a classic silent failure. Nothing crashes. New users on iPhone simply fail to register, or never receive a receipt or password-related email, and the first sign is a dip in conversion that nobody connects to a domain name. Because Sign in with Apple is required for many iOS apps that offer other social logins, a lot of live apps depend on it.
So what
Ask whoever maintains your app one question this week: does anything in our sign-up or email pipeline treat privaterelay.appleid.com as special? If yes, it needs a second entry now, not after launch of the change. If you do not have someone who can answer, that is a sign the app needs a maintenance owner. Our iOS and Android services include ongoing support for live apps, or you can start a project to have an audit done.