fix(expo): Pass through user name on native Apple sign-in#9214
Conversation
useSignInWithApple and useSignInWithGoogle called signIn.create() first
and only fell back to signUp.create({ transfer: true }) for new users,
so the name Apple/Google hand back on the credential was never read and
never recorded. Restructure both hooks to sign-up-first (passing
firstName/lastName from the native credential), falling back to
signIn.create({ transfer: true }) only when the account already exists,
matching clerk-ios's signUpWithIdToken + handleTransferFlow pattern.
Public hook signatures and return types are unchanged.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0158VB1fS18rJ8AGoqBR3ZrB
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: 607b5e0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@clerk/astro
@clerk/backend
@clerk/chrome-extension
@clerk/clerk-js
@clerk/electron
@clerk/electron-passkeys
@clerk/eslint-plugin
@clerk/expo
@clerk/expo-google-signin
@clerk/expo-passkeys
@clerk/express
@clerk/fastify
@clerk/hono
@clerk/localizations
@clerk/nextjs
@clerk/nuxt
@clerk/react
@clerk/react-router
@clerk/shared
@clerk/tanstack-react-start
@clerk/testing
@clerk/ui
@clerk/upgrade
@clerk/vue
commit: |
API Changes Report
Summary
No API Changes DetectedAll packages have stable APIs with no detected changes. Report generated by Break Check Last ran on |
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c17526809f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…omments Address Codex review feedback on PR #9214: keep the changeset focused on user-facing behavior only, and condense the multi-line rationale comments in useSignInWithApple.ios.ts and useSignInWithGoogle.shared.ts to single terse lines per the repo's comment convention.
wobsoriano
changed the title
wobsoriano
changed the title
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep it up! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
3 participants
Original investigation requested by Mike Pitre via Slack thread. Scope revised after verifying the behavior against FAPI source.
Description
Before:
useSignInWithApplecalledsignIn.create()first with only the Apple ID token and never readcredential.fullNameoff the native credential. Apple only provides the user's name in the native credential on first authorization, never inside the identity token, so a brand-new user's name was structurally dropped. Reported by a customer whose App Store submission was rejected over the Sign in with Apple name requirement.After:
useSignInWithApplesigns up first, passingfirstName/lastNamefrom the Apple credential. If the account already exists, FAPI returns the sign-up with atransferableexternal account verification and the hook completes authentication viasignIn.create({ transfer: true }). On instances with restricted or waitlist sign-up mode, FAPI rejects the sign-up create before checking whether the account exists (sign_up_mode_restricted/sign_up_restricted_waitlist), so the hook catches those and falls back to a direct token sign-in. Existing users keep working and new users stay blocked, preserving current behavior on those instances.useSignInWithGoogleis intentionally unchanged. Verified against FAPI source: Google names are populated server-side from the One Tap ID token'sgiven_name/family_nameclaims, so the name bug cannot occur for Google. Additionally, thegoogle_one_tapstrategy never returns atransferablestatus (an existing account throwsexternal_account_existsbefore any account transfer is created), so a sign-up-first restructure would add a guaranteed failed request for every existing user while fixing nothing. clerk-android's Google flow is sign-in-first for the same reason.No public API changes.
Checklist
pnpm --filter @clerk/expo testruns as expected (108 passed)pnpm turbo build --filter=@clerk/exporuns as expectedpnpm turbo lint --filter=@clerk/exporuns as expectedType of change
Testing note
Apple returns
fullNameonly on the first authorization of the app for a given Apple ID, afterwards it is alwaysnull. To verify the fix as a "new user", deleting the Clerk user from the dashboard is not enough. Also revoke the app's authorization on the device (Settings > Apple Account > Sign in with Apple > select the app > Stop Using Apple ID), then sign in again. Retesting without revoking will still produce a nameless sign-up by design, that case is covered by the "credential without a name" unit test.