Sign In with Apple Private Relay Issue: Solved

Apple has removed all private relay emails associated with our service for users who signed in using Apple ID (this is an issue on Apple’s side that we cannot fix). As a result, we are currently unable to send you any emails, including informational messages and login code emails.

This issue began during Apple’s scheduled maintenance on May 3, 2025.

On May 3, 2025, we faced a critical issue: “Sign in with Apple” stopped working properly for all users, resulting in the complete loss of access for one-third of our users-specifically, those using Apple’s private relay emails.

• Apple began returning a completely new userIdentifier for existing Apple IDs, without users initiating any changes.
  This effectively made user authentication impossible, as we can no longer match users to their existing data.
• The email field now always returns null. Although this behavior is typical for subsequent sign-ins, it’s irrelevant in this case because the userIdentifier itself changed, leaving no way to identify existing accounts.
• Previously issued relay emails (@privaterelay.appleid.com) no longer accept emails-we verified this with bounce tests.
• Users also report that our app has disappeared from their Apple ID’s authorized apps list.

• We migrated our Apple Developer account from Individual to Organization about a year ago.
• Everything worked perfectly until the May 3, 2025 update.
• The incident occurred precisely on the day Apple released updates to the Developer Console (Accounts, Profiles, etc.). We strongly believe these internal changes at Apple triggered the issue.

• Every user received a new userIdentifier, meaning our system sees returning users as entirely new, breaking the link to their historical data.
• One-third of our users, who registered via Apple’s private relay email, are now completely unreachable:
• We can’t contact them (emails bounce).
• We can’t restore their access (new IDs don’t match old accounts).
• We have sent three support requests to Apple via email-no reply or acknowledgment yet, with no escalation path or live chat available.

🧠 We were fortunate because ASO.dev also supports an alternative sign-in method (email with a one-time login code). Without this alternative, we would’ve permanently lost access for every user who originally signed in with Apple.

• Warn developers who rely solely on Apple Sign-In and relay email addresses.
• Connect with others who’ve faced similar issues-let’s share experiences.
• Draw Apple’s attention to this critical problem-currently, there is no documented solution and no available support.

Never rely solely on Apple ID authentication.
Always implement a fallback method, as even major ecosystems can fail unpredictably.

August 08, 2025 (3 months later)

It’s been three long months since the May 3 incident.
We’ve followed up with Apple multiple times, but never received any acknowledgment or explanation - not even a “we’re looking into it.”

And then… last week, without warning, everything just started working again.

• The original userIdentifier values are back.
• Previously unreachable users with Apple’s private relay email can now sign in normally.
• Emails to old relay addresses no longer bounce.
• Our app reappeared in the “Sign in with Apple” authorized apps list for affected users.

No notice. No release notes. No communication. Just poof, fixed.

August 28, 2025 (+20 days)

It’s been almost four months since the May 3 incident.
We still haven’t received any response from Apple.
While preparing a newsletter for our user base, we discovered that some users are again unable to sign in with Apple ID using private relay emails or receive emails for accounts created before the May 3, 2025 incident.

If you depend on Apple Sign-In, always offer an alternative login method Systems - even from the biggest platforms - can fail in ways you can’t predict, with zero visibility or ETA for resolution.

We’re keeping our fallback sign-in option permanently.

On May 3rd, 2025, Sign in with Apple suddenly broke.
Roughly 30% of users could no longer log in: their userIdentifier silently changed, and the email field started returning null.
Some accounts even came back to life temporarily - then disappeared again. It didn’t look like a normal migration or integration issue.

We filed a detailed bug report and a DTS case (FB17664946 / Case 13610776) describing the issue:
same bundle ID, no code changes, stable build since April 30 - and the problem appeared out of nowhere.

It took five months for Apple to reply.
And the final message from Developer Technical Support was essentially:

“Your app was once transferred between teams.
Please read TN3159: Migrating Sign in with Apple users for an app transfer.”

That’s all.
No explanation for why the issue appeared almost a year after the app transfer.
No clarification on why some users briefly recovered.
No insight into why userIdentifier was changed in the first place.

userIdentifier isn’t a token, alias, or email.
It’s supposed to be a stable internal ID, the only consistent way for an app to link user accounts to stored data.

Changing it is like replacing every user’s primary key in a production database just because the app was moved to another Apple Developer team.
Rotating email addresses or JWTs can be justified for privacy.
But rotating the core user ID - the identifier that’s meant to be permanent - is an architectural design flaw.

This design forces developers to “migrate” Apple user IDs manually, which for many apps is either impossible or extremely risky.
Most systems simply aren’t built to handle a changing primary identity key - nor should they be.

If such resets can happen, App Store Connect should:

• automatically migrate identifiers during app transfers, or
• at least display a clear warning like:
  “Users signed in with Apple may lose access after transferring this app.”

Instead, the only documentation mentioning this behavior - Technote TN3159 - is buried deep in Apple’s developer site, with no visibility or guidance until it’s too late.

Yes - Apple did reply.
But it took five months just to tell us to “read the doc,” without addressing:

• why this behavior exists,
• why it triggered a year late,
• and why anyone thought changing a persistent user ID was an acceptable design choice.

Until Apple reconsiders how Sign in with Apple handles identity, this mechanism remains fundamentally unreliable for developers who care about user continuity and data integrity.