Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Sign in with Apple" broke after update–losing data for a third of users (aso.dev)
38 points by gorniv 9 months ago | hide | past | favorite | 18 comments
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.

What exactly happened?

• 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.

Important context:

• 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.

Consequences:

• 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.

We’re openly sharing this story to:

• 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.



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.


yes, looks like they lost our account in the system and created new.


> We were fortunate because ASO.dev also supports an alternative sign-in method (email with a one-time login code).

How does that work if according to you the apple private relay emails bounce?

> 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).

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?

Overall, pretty serious incident. Please post updates regarding apples response.


It doesn’t work for Apple private relay users, but it does work for those who signed in with Apple without using “Hide My Email.”

The good news is that Apple’s private relay addresses are unique per user, so if someone contacts us, we can match and update their account to a regular email. We’ve added a banner to our site to help guide affected users through this.

One-time sign-in via email still works for everyone else, and we’re looking into ways to let users securely update their email via support if they can no longer log in.

We’re waiting on a response from Apple and will post updates as we get them. Thank you!


I think they're saying Users with alternative sign in methods are unaffected, but users without another sign in method are locked out.

Otherwise, how do you verify the user is requesting the one-time sign in and not a threat actor trying to associate the account to their own email?


Knowing the Apple private relay email is almost like knowing a password — not a perfect method, but it’s currently the best option we have for verifying identity when the original email is no longer reachable and Apple provides no fallback.

That said, any sensitive data in our service is either encrypted with a user-provided phrase or never sent to our servers at all. We’ve put a lot of effort into security, but we honestly didn’t expect this kind of curveball from Apple — where the login email they issued suddenly becomes invalid and breaks access.

We’re waiting for a response from Apple and exploring safe fallback options in the meantime.


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:

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.

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.


Can't help but wholeheartedly agree. You would think that the bit where you actually gave them money would be buttery smooth, but each one of those interfaces is riddled with bugs and yank. Every time I have the misfortune of needing to touch them, I know I'm in for a world of pain.


Is it still the case that offering Apple ID is mandatory on the iOS store?

Forcing users to use certain identity providers while uninformed as a sole point of failure is a challenge.

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.

If it was optional, and a convenience/preference that could be added, that would be a different thing.


It's mandatory if you allow or use other 3rd party auth (ie. Facebook or Google).


Appreciate this - I can't say it makes sense because some third auth might be specifically selected for user-type or industry alignment (LinkedIn, Github, Microsoft login, etc).

M365 login specifically can hook into quite a bit of organization information along with the user itself that can help configure apps, wouldn't be relevant for Apple in those kinds of B2B scenarios.

Apple ID is almost always a personal or individual one.

It can be convenient for sure, makes me think about how there's other things where Apple is/was the only choice for the most part like payments, although that's changed for the time being.


It was our mistake to allow Apple Sign In. We wanted to make things better for users, but didn’t expect Apple to suddenly break their own login emails without warning.


Apple logins are useful for sure, I still use it sparingly, not ideal to have so many identity providers and they're all trying to vy for it.

Most people are where they started, whether its Microsoft, Gmail, Apple, etc.


Oof… coincidentally my task for today is to implement Sign in with Apple.

If you were starting over what would you do differently?


Definitely save the email in your database — even if it’s a private relay address. Also, send a welcome email right after signup, so users can see which email was used and ideally encourage them to update it to a regular one or add an alternative login method (like passwordless email sign-in or OAuth).

If we were starting over, we’d make that update flow more prominent from day one. Apple’s “Hide My Email” sounds harmless until it silently breaks everything later.


Not OP, but customer identity is a component of my work. Ask users for a recovery email and/or phone number to bootstrap identity if sign in with goes sideways.


Nice! Another tally mark in my, “If you don’t control your own nominal technologies, the minor benefits will eventually majorly screw you,” log.

Seriously, just use Argon2id or scrypt.

Any “fallback” is just you doing what you should have to begin with.


We actually use 6-digit one-time codes sent to email as a second login method. If we detect brute-force attempts, we switch to using a GUID-based fallback instead of short codes.

So yeah, lesson learned — don’t outsource identity fully. We thought Apple Sign In would be convenient, but it backfired hard.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: