gorniv

On May 3rd, 2025, Sign in with Apple suddenly broke.

Around 30% of users couldn’t log in anymore: their userIdentifier silently changed, and the email field started returning null. Some accounts even “came back to life” for a short time - 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) explaining everything: same bundle, no code changes, stable since April 30, and the issue started suddenly.

It took five months for Apple to reply. And the reply, in full, was basically:

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

That’s it. No explanation of why the problem appeared almost a year after the transfer. No answer to why some users temporarily recovered, or why the userIdentifier changed in the first place.

⸻

The real question: why change userIdentifier at all?

userIdentifier is not a token, not an email alias, not a JWT claim. It’s supposed to be a stable, internal ID - the only reliable way to match a user to their data.

Changing it is like deciding to replace every user’s primary key in a production database just because the app moved to another developer account. Sure, rotating emails or tokens makes sense for privacy. But rotating the internal ID of a user? That’s an architectural nightmare.

Apple’s approach essentially offloads a manual “ID migration” problem to developers - something most apps can’t safely implement, because it means rewriting their identity model. And the official documentation that describes this risk? Hidden deep in a technote (TN3159) no one ever sees until it’s too late.

⸻

Five months later

So yes - technically, Apple did reply. But it took five months just to tell us to “read the doc,” without explaining why this behavior even exists, why it triggered a year late, or why anyone thought changing a persistent user ID was acceptable in the first place.

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.

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.

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.

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

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.

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!

As an indie dev, I’ve always been frustrated by the high cost of ASO tools, most of which are built for big companies with massive budgets. Paying $100 to $500 a month just isn’t practical when you’re bootstrapping a project solo.

That’s why I created ASO.dev—a powerful and affordable ASO tool made specifically for indie developers. It offers everything you need, like keyword research, competitor tracking, and more, but at a price that works for us indie devs.

If you’re fed up with overpriced ASO solutions and want something built with indies in mind, give ASO.dev a try. I’d love to hear your feedback!

P.S. We also have the best App Store Connect client, available for both iOS and Windows. You can even deploy your iOS app from your favorite beer pub

Very interesting game =)

So beautiful images