We run ASO.dev, a tool helping developers manage their App Store metadata and visibility. 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.<p>What exactly happened?<p>• 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.<p>Important context:<p>• 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.<p>Consequences:<p>• 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.<p>⸻<p>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.<p>⸻<p>We’re openly sharing this story to:<p>• 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.<p>Never rely solely on Apple ID authentication.
Always implement a fallback method, as even major ecosystems can fail unpredictably.
Not familiar with apple ID but I've worked lots with CAS/SAML2/OAUTH sounds like userIdentifier was a pairwise ID and apple touched something with the integrating service causing the pair to change. the sub claim in OAUTH would act similarly.
> We were fortunate because ASO.dev also supports an alternative sign-in method (email with a one-time login code).<p>How does that work if according to you the apple private relay emails bounce?<p>> 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).<p>You could temporarily let these emails let a one time sign in link get sent to another email account, so they can update their settings, no?<p>Overall, pretty serious incident. Please post updates regarding apples response.
I'm not surprised. Apple ID seems completely broken to me, even when I just tried to set up a new MacBook 4 weeks ago:<p>Create an account via the settings page? Had to contact support because my phone number + email got stuck in some "halfway activated but can't log in" state.<p>Sign into the App Store + downloading some software? Got stuck in some broken form that wouldn't let me enter payment information. Had to crawl through reddit threads about how to work around this mess, just to be able to use the App Store.
Is it still the case that offering Apple ID is mandatory on the iOS store?<p>Forcing users to use certain identity providers while uninformed as a sole point of failure is a challenge.<p>Apple (or other providers) already have the user with an ID, having the app do the bidding of propagating it's use further is a different issue.<p>If it was optional, and a convenience/preference that could be added, that would be a different thing.
Nice! Another tally mark in my, “If you don’t control your own nominal technologies, the minor benefits will eventually majorly screw you,” log.<p>Seriously, just use Argon2id or scrypt.<p>Any “fallback” is just you doing what you should have to begin with.