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