Repository navigation
fix(ui_oauth_apple): upgrade anonymous users by linking the Apple credential - #730
Merged
Merged
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the mobileSignIn method in AppleProvider to link the provider when shouldUpgradeAnonymous is true. A review comment highlights that if auth.currentUser is null, the operation will silently fail and leave the UI in an infinite loading state, and suggests explicitly handling this error state.
Mastersam07
marked this pull request as draft
October 20, 2026 11:55
… nothing to link AuthAction.link with no signed in user null-shorted, and a null credential from linkWithProvider was force unwrapped inside .then. Both left the flow stuck loading. Report them through the listener, matching TwitterProvider, and cover anonymous upgrade and the no-user case in tests.
Mastersam07
marked this pull request as ready for review
October 20, 2026 13:07
This was referenced Oct 21, 2026
demolaf
approved these changes
Oct 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
AppleProvider.mobileSignInonly linked onAuthAction.link, ignoringshouldUpgradeAnonymous. An anonymous user signing in with Apple got a fresh account instead of being upgraded, losing their uid and data. It now links when upgrading, matchingOAuthProvider.onCredentialReceivedand the Twitter provider.Following review, the link path also matches
TwitterProvider's guards:AuthAction.linkwith no signed in user reports ano-current-usererror instead of null-shorting and leaving the button loading forever._onLinkedreports amissing-credentialerror instead of force unwrapping a null credential.Split out of #288 (original commit by @yoman07, authorship preserved). The Facebook half of #288 already landed in #553.
Tests
Two new cases in
tests/integration_test/firebase_ui_oauth_apple/apple_sign_in_test.dart: an anonymous user links instead of signing in, and linking with no user reportsAuthFailed. Both fail without the fix. All 8 Apple tests pass locally on macOS.Known limitation
Apple now behaves like Google already does in one flow: a returning Apple user who is signed in anonymously on a new device gets
credential-already-in-use, because the Apple account already belongs to another user. Previously Apple skipped linking, so that user was signed in but the anonymous user's data was silently dropped. Surfacing this as an upgrade conflict the app can resolve (as Android and iOS do) is tracked in #734, since it belongs in the shared auth flow for every provider.Related Issues
Part of #253. It fixes the Apple half; #253 stays open until #734 handles upgrade conflicts.
Breaking Change