# How to use SwiftUI components in a React Expo and Clerk app Clerk's [`@clerk/expo`](https://github.com/clerk/javascript/tree/main/packages/expo) package ships a `/native` subpath that exports three React components, `AuthView`, `UserButton`, and `UserProfileView`, which render as real SwiftUI views on iOS. On the JavaScript side you write one React Native component tree; on the device, `UIHostingController` embeds the native SwiftUI view inside React Native's Fabric hierarchy. Apple Sign-In uses the OS-level `ASAuthorizationController` credential sheet. Google Sign-In on iOS uses `ASWebAuthenticationSession`, the same RFC 8252 compliant Safari sheet that Google's own iOS SDK uses internally, because iOS does not expose a system-level Google credential picker. On Android, the same `` renders as Jetpack Compose, and Google Sign-In goes through the true native Credential Manager bottom sheet. One TypeScript file builds both platforms. This tutorial focuses on iOS and SwiftUI because that's where the bridging work is most visible; Android-specific setup is called out inline where it applies. > Clerk's Expo native components are in public beta as of 2026-04-16. The API surface is stable enough to build with, but expect minor breaking changes before general availability. Pin `@clerk/expo@^3.2.0` if you want a reproducible build. ## What you'll build By the end of this tutorial you'll have an Expo app that: - Renders `` as a SwiftUI view with native Google Sign-In and native Apple Sign-In on iOS. - Displays a `` in the Expo Router header that opens the native profile modal on tap. - Uses `` for a dedicated profile screen (personal info, email, [MFA](https://clerk.com/docs/guides/development/custom-flows/authentication/multi-factor-authentication.md), [passkeys](https://clerk.com/docs/guides/configure/auth-strategies/sign-up-sign-in-options.md#passkeys), connected accounts, active sessions, sign-out). - Gates the home stack behind `Stack.Protected` so only signed-in users can reach it. - Runs the same code on Android as Jetpack Compose, with Google Sign-In routed through the Android Credential Manager bottom sheet. Testing the Google Sign-In flow works on the iOS Simulator. Testing Apple Sign-In reliably requires a physical iPhone. A full end-to-end iOS build takes about 30 minutes from a clean machine. ## Why native authentication beats WebView OAuth Native credential pickers close a specific attack surface that embedded WebView browsers cannot. Beyond the UX benefits over WebView-based [authentication](https://clerk.com/docs/guides/how-clerk-works/overview.md), that's the security reason standards bodies, Apple, and Google all moved away from WebView OAuth. ### The WebView OAuth problem Google announced the embedded-WebView OAuth block in August 2016 ([Google Developers Blog, Aug 2016](https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html)). New OAuth clients were blocked starting 2016-10-20; existing clients started receiving the `disallowed_useragent` error for WebView traffic on 2017-04-20. The reason is simple: a WebView is part of the host app's process, so the app can inject JavaScript, read the DOM, and capture keystrokes during the OAuth flow. RFC 8252 (BCP 212) codified this in October 2017: "this best current practice requires that native apps MUST NOT use embedded user-agents to perform authorization requests" ([RFC 8252 Section 8.12](https://datatracker.ietf.org/doc/html/rfc8252#section-8.12)). The 2025 OAuth 2.0 Security Best Current Practice (RFC 9700) reaffirmed the external-agent requirement ([RFC 9700, Jan 2025](https://datatracker.ietf.org/doc/rfc9700/)). Real-world evidence backs this up. Felix Krause demonstrated in August 2022 that Instagram and Facebook's in-app browsers inject tracking JavaScript into every third-party page, including sign-in forms ([Krause, Aug 2022](https://krausefx.com/blog/ios-privacy-instagram-and-facebook-can-track-anything-you-do-on-any-website-in-their-in-app-browser)). That's ambient surveillance; a hostile host app could just as easily capture passwords. ### The compliant-browser alternative `ASWebAuthenticationSession` on iOS and Chrome Custom Tabs on Android are the standards-compliant alternatives. They run outside the host app's process, share cookies with Safari or Chrome (so users already signed into Google can continue with one tap), and prevent the app from observing keystrokes. This is the baseline every modern [OAuth](https://clerk.com/docs/guides/configure/auth-strategies/social-connections/overview.md) provider hits on iOS. These sheets still show browser chrome and context-switch the user out of your app's visual flow. That's the UX trade-off: they're secure, but they're not borderless. ### True native credential pickers and where they exist An OS-level credential sheet, no browser, no URL bar, biometric confirmation, is the best experience available today. But they only exist for specific providers on specific platforms: - **Apple Sign-In on iOS:** `ASAuthorizationController` / `ASAuthorizationAppleIDProvider` (iOS 13+). No browser. - **Google Sign-In on Android:** Jetpack Credential Manager (`androidx.credentials.CredentialManager`). A system bottom sheet that surfaces signed-in Google accounts and passkeys. - **[Passkeys](https://clerk.com/docs/guides/configure/auth-strategies/sign-up-sign-in-options.md#passkeys) on iOS and Android:** `ASAuthorizationPlatformPublicKeyCredential*` APIs on iOS and Credential Manager on Android. There is one important asymmetry: iOS has no OS-level Google credential picker. Clerk's `` on iOS routes Google Sign-In through `ASWebAuthenticationSession`, the same path Google's own `GIDSignIn` iOS SDK uses under the hood. The Safari sheet opens, the user taps "Continue with Google," and cookies are shared so most sign-ins are a single tap. But it is still a browser sheet, not a browserless OS picker. On Android, the same `` invokes Credential Manager and users see the real native bottom sheet. The Android path is the closest modern experience to Apple's on-device credential sheet. ### App Store Guideline 4.8 Apple's App Store Review Guidelines require apps that offer any third-party [social login](https://clerk.com/docs/guides/configure/auth-strategies/social-connections/overview.md) to also offer an equivalent privacy-preserving option (Sign in with Apple qualifies) ([Apple Developer, updated 2026-02-06](https://developer.apple.com/app-store/review/guidelines/#login-services)). Enforcement began on 2020-06-30 ([Apple Developer, 2020](https://developer.apple.com/news/upcoming-requirements/?id=06302020a)). Practically, this means if you ship Google Sign-In, you also ship Apple Sign-In, and the path of least friction is the native `ASAuthorizationAppleIDButton` and credential sheet. A related requirement, Guideline 5.1.1(v), mandates in-app account deletion since 2022-06-30 ([Apple Developer, 2022](https://developer.apple.com/support/offering-account-deletion-in-your-app/)). Clerk's `` surfaces account deletion as part of the native profile flow, so this ships for free. ### The numbers Measurable conversion gains for native and passkey flows are well-documented: - **Pinterest:** 126% Android sign-up increase with Google One Tap ([Google Identity, Pinterest case study](https://developers.google.com/identity/sign-in/case-studies/pinterest)). - **FIDO Passkey Index (Oct 2025):** 93% sign-in success with passkeys vs 63% with other authentication methods (social login, MFA, OTPs) ([FIDO Alliance, Oct 2025](https://fidoalliance.org/wp-content/uploads/2025/10/FIDO-Passkey-Index-October-2025.pdf)). - **Dashlane:** 92% conversion rate on passkey sign-in opportunities vs 54% on automatic password opportunities, a 70% conversion lift ([Google Developers Blog, Dashlane](https://developers.googleblog.com/password-manager-dashlane-sees-70-increase-in-conversion-rate-for-signing-in-with-passkeys-compared-to-passwords/)). - **Microsoft:** \~98% success for passkeys vs \~32% for passwords; phishing attacks using adversary-in-the-middle techniques up 146% year-over-year ([Microsoft Security, Dec 2024](https://www.microsoft.com/en-us/security/blog/2024/12/12/convincing-a-billion-users-to-love-passkeys-ux-design-insights-from-microsoft-to-boost-adoption-and-security/)). The pattern is consistent: when sign-in drops below a browser hop and uses on-device credentials, success rates climb and friction collapses. ## How Clerk's native components render SwiftUI `@clerk/expo/native` exports three React components. Each one is backed by a real SwiftUI view on iOS, hosted inside React Native's Fabric hierarchy via `UIHostingController` ([Apple Developer](https://developer.apple.com/documentation/swiftui/uihostingcontroller)). Props flow React → C++ Shadow Node → SwiftUI view; events flow back through Fabric's `EventEmitter`. The TypeScript surface hides every bit of that plumbing. The end-to-end bridge looks like this: ```text React / TypeScript │ ▼ Fabric C++ Shadow Node (props down, events up) │ ┌──────────┴──────────┐ ▼ ▼ iOS Android UIHostingController ComposeView │ │ ▼ ▼ SwiftUI view Jetpack Compose view (clerk-ios) (clerk-android) │ │ ▼ ▼ ASAuthorizationController, Credential Manager, ASWebAuthenticationSession Chrome Custom Tabs │ │ └──────────┬──────────┘ ▼ native Clerk session │ ▼ JS Clerk instance → useAuth(), useUser(), useSession() ``` The actual UI lives in the [`clerk-ios`](https://github.com/clerk/clerk-ios) native SDK, which ships as a native dependency of `@clerk/expo`. When a user signs in via the SwiftUI `AuthView`, the native SDK creates a [session](https://clerk.com/docs/guides/sessions/session-tokens.md) and hands it back through the Fabric event emitter. Since `@clerk/expo` 3.1.6, the JavaScript `Clerk` instance syncs bidirectionally with this native session, so `useAuth()`, `useUser()`, and `useSession()` reflect the new state without a page reload ([@clerk/expo CHANGELOG](https://github.com/clerk/javascript/blob/main/packages/expo/CHANGELOG.md)). Compare that to rolling your own SwiftUI integration. Callstack's "Exposing SwiftUI views to React Native" guide ([Callstack, 2024](https://www.callstack.com/blog/exposing-swiftui-views-to-react-native-an-integration-guide)) lays out the three-layer architecture you'd own: a SwiftUI view, an Objective-C++ wrapper inheriting from `RCTViewComponentView`, and an `ObservableObject` for prop passing. Add a Codegen spec, a `Podspec` for the native dependency, and lifecycle handling for the hosting controller. Cross-platform parity to Jetpack Compose is a second, separate effort. ### Android parity The same React API renders as Jetpack Compose on Android via Clerk's [`clerk-android`](https://github.com/clerk/clerk-android) SDK. You write one `` import and get SwiftUI on iOS and Compose on Android, with per-platform Google, Apple, and passkey flows. The rest of this tutorial concentrates on iOS; Android-specific bits (Google SHA-1 fingerprint, Credential Manager behaviour) are flagged inline when they apply. ## Comparing native React Native authentication approaches Four broad options exist when you want real native auth on React Native: 1. **Build your own bridge.** Obj-C++ wrapper around `RCTViewComponentView`, `UIHostingController` hosting a SwiftUI view, repeat for Compose on Android. High effort, high maintenance ([Callstack integration guide](https://www.callstack.com/blog/exposing-swiftui-views-to-react-native-an-integration-guide)). 2. **Redirect-based OAuth libraries.** `react-native-app-auth`, Auth0 React Native, Amplify social login, the Supabase default path, Okta. All route through `ASWebAuthenticationSession` on iOS and Chrome Custom Tabs on Android. Compliant with RFC 8252 and fine for security; still shows browser chrome. 3. **Native credential-picker wrappers.** `expo-apple-authentication`, `@react-native-google-signin/google-signin`, `invertase/react-native-apple-authentication`, and similar packages. They expose the native picker, but you still design every pixel of your sign-in, sign-up, and profile screens. 4. **Pre-built native RN UI.** Clerk's `@clerk/expo/native` is currently the only option that gives you the full set of auth screens, social + email + MFA + profile, as drop-in React components. | Provider | Pre-built RN UI | Native Google picker | Native Apple picker | Profile UI | Official RN SDK | | ------------- | :-------------: | :------------------: | :-----------------: | :--------: | :-------------: | | Clerk | Yes | Yes | Yes | Yes | Yes | | Firebase Auth | No | 3rd party | 3rd party | No | Yes | | Auth0 | No | No | No | No | Yes | | Supabase Auth | No | 3rd party | 3rd party | No | JS SDK | | AWS Amplify | Authenticator | No | No | No | Yes | | Stytch | StytchUI | No | No | No | Yes | | Descope | FlowView | via option | via option | No | Yes | | WorkOS | No | No | No | No | No | A few notes the table flattens: - **Firebase** does not ship pre-built React Native UI. Its documented path is to combine `@react-native-firebase/auth` with `@react-native-google-signin/google-signin` and `invertase/react-native-apple-authentication`, wiring the tokens back into Firebase ([rnfirebase.io, Social Auth](https://rnfirebase.io/auth/social-auth)). - **Auth0** relies on Universal Login, an `ASWebAuthenticationSession` redirect. There is no native-form option ([Auth0 React Native Quickstart](https://auth0.com/docs/quickstart/native/react-native/interactive)). - **Supabase** does not expose native React Native UI. Their Apple Sign-In guide walks you through `expo-apple-authentication`, and their Google Sign-In guide uses `@react-native-google-signin/google-signin` ([Supabase Apple](https://supabase.com/docs/guides/auth/social-login/auth-apple); [Supabase Google](https://supabase.com/docs/guides/auth/social-login/auth-google)). - **Amplify Authenticator** exists for React Native but routes social providers through a browser-based flow ([Amplify Authenticator](https://ui.docs.amplify.aws/react-native/connected-components/authenticator); [Amplify social providers](https://docs.amplify.aws/gen1/react-native/build-a-backend/auth/add-social-provider/)). - **Stytch** ships a React Native UI configuration that renders a form, but their native social pickers are wrapper-level rather than system-level ([Stytch React Native UI](https://stytch.com/docs/mobile-sdks/react-native-sdk/ui-configuration)). - **Descope** offers a native-vs-browser toggle per flow; it's flexible, but there is no drop-in profile UI ([Descope native vs browser flows](https://docs.descope.com/mobile-sdk/native-vs-browser-flows)). - **WorkOS** does not publish a React Native SDK ([WorkOS SDKs list](https://workos.com/docs/sdks)). If you need full native UI with the least custom code, Clerk is the shortest path today. The rest of this tutorial walks through the implementation. ## Prerequisites Before you start, make sure you have: - **Node.js 20.9.0+** (`@clerk/expo` minimum per [its README](https://github.com/clerk/javascript/blob/main/packages/expo/README.md)). React Native 0.81 raises that floor in practice to 20.19.4+, so install the latest LTS Node if you're on an older machine. - **Expo SDK 54+** (SDK 55 also works). This tutorial pins 54 to match Clerk's [NativeComponentQuickstart](https://github.com/clerk/clerk-expo-quickstart/tree/main/NativeComponentQuickstart) repo. - **Xcode 16.1+** ([required by React Native 0.81 which ships with SDK 54](https://reactnative.dev/blog/2025/08/12/react-native-0.81)). - **A Clerk account.** The free Hobby tier includes 50,000 [monthly retained users](https://clerk.com/pricing) (MRUs: users who visit your app on a day after sign-up). - **Google Cloud Console access** for creating OAuth 2.0 client IDs. Free. - **iOS device and Apple ID setup (read carefully):** - A physical iPhone is strongly recommended for the Apple Sign-In section. The iOS Simulator can complete the initial Sign in with Apple authorization flow when a real Apple ID is signed into Settings, but `getCredentialStateAsync` always throws on the Simulator, so any app logic that checks credential state on subsequent launches won't work there ([expo-apple-authentication docs](https://docs.expo.dev/versions/latest/sdk/apple-authentication/)). Google Sign-In via `` works reliably on the Simulator. - A free Apple ID builds to the Simulator. Deploying to a physical device and enabling the Sign in with Apple capability for App Store distribution both require an Apple Developer Program membership ($99/year) ([Apple Developer Program](https://developer.apple.com/programs/whats-included/)). - **Android parity (optional):** Android Studio + Android SDK 24+ if you also want `npx expo run:android`. The Jetpack `androidx.credentials` Credential Manager library supports Android 6.0 (API 23) and higher ([Android Credential Manager](https://developer.android.com/identity/sign-in/credential-manager)). A quick version check: ```bash node --version # v20.9.0 or newer xcodebuild -version # Xcode 16.1 or newer ``` If either is too old, upgrade before proceeding. ## Why development builds, not Expo Go Expo Go bundles a fixed set of native modules. `@clerk/expo/native` ships custom native code (the SwiftUI `ClerkAuthView`, the Jetpack Compose equivalent, and the `clerk-ios` / `clerk-android` native SDK dependencies). Expo Go can't load custom native modules, so it can't render these components ([Expo development builds introduction](https://docs.expo.dev/develop/development-builds/introduction/)). `expo-dev-client` replaces Expo Go. It's the same Debug build of your app, with the Expo Dev Menu and fast refresh wired in ([expo-dev-client](https://docs.expo.dev/versions/latest/sdk/dev-client/)). You install the package once; each `npx expo run:ios` compiles a fresh dev build for your device or simulator. Two paths to a dev build: 1. **Local.** `npx expo run:ios` / `npx expo run:android`. Zero cloud setup, requires Xcode or Android Studio locally. 2. **EAS.** `eas build --profile development`. Cloud builder, no local Xcode needed. Requires an Expo account and, for iOS device builds, a paid Apple Developer Program membership ([EAS development build](https://docs.expo.dev/develop/development-builds/create-a-build/)). This tutorial uses local builds for zero-setup reproducibility. EAS is a drop-in swap if that fits your team better. ## Step 1: Create the Expo project Scaffold a fresh project: ```bash npx create-expo-app@latest clerk-native-app --template default cd clerk-native-app ``` Then install Clerk and the two required Expo packages: ```bash npx expo install @clerk/expo expo-secure-store expo-dev-client ``` Three notes: - `@clerk/expo` is the Clerk SDK. The native components live under the `@clerk/expo/native` subpath. - `expo-secure-store` is how the Clerk token cache persists the session JWT securely on device ([Expo SecureStore](https://docs.expo.dev/versions/latest/sdk/securestore/)). - `expo-dev-client` turns your build into a dev client (replacing Expo Go). Do **not** install `expo-apple-authentication` or `expo-crypto` yet. `` handles Apple Sign-In internally without them. You'll only need those packages if you later swap to the custom-UI path with `useSignInWithApple()`, covered in Step 6. This matches the [NativeComponentQuickstart `package.json`](https://github.com/clerk/clerk-expo-quickstart/blob/main/NativeComponentQuickstart/package.json). ## Step 2: Configure Clerk There are four pieces of configuration: the Dashboard application, the Native API, environment variables, and the Clerk plugin in `app.json`. ### Create a Clerk application [Sign up for a Clerk account](https://dashboard.clerk.com/sign-up) and create a new application. Pick a name, leave the defaults, and copy the [Publishable Key](https://clerk.com/docs/guides/development/clerk-environment-variables.md) from the API keys page. ### Enable the Native API In the Dashboard, navigate to **Native applications** and click **Enable**. Register your iOS and Android apps ([Clerk iOS production docs](https://clerk.com/docs/ios/reference/native-mobile/production.md); [Clerk Android production docs](https://clerk.com/docs/android/reference/native-mobile/production.md)): - **iOS:** Apple Team ID + Bundle ID. Team ID is on the [Apple Developer account membership page](https://developer.apple.com/account/#/membership/). Bundle ID matches the `ios.bundleIdentifier` value in your `app.json`, for example `com.yourname.clerknativeapp`. - **Android:** Package name + SHA-256 debug fingerprint. Get the fingerprint with: ```bash cd android && ./gradlew signingReport ``` Use the `SHA-256` line under `Variant: debug`. Production apps need the release-signing SHA-256 registered separately. ### Configure environment variables Create a `.env.local` file at the project root: ```bash EXPO_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_... ``` The `EXPO_PUBLIC_` prefix is required for Expo to inline the value into the client bundle. ### Configure the Clerk plugin in `app.json` Add the `@clerk/expo` plugin alongside `expo-router` and `expo-secure-store`: ```json { "expo": { "name": "clerk-native-app", "slug": "clerk-native-app", "ios": { "bundleIdentifier": "com.yourname.clerknativeapp" }, "android": { "package": "com.yourname.clerknativeapp" }, "plugins": ["expo-router", "expo-secure-store", ["@clerk/expo", {}]] } } ``` The plugin accepts two options, verified against `withClerkExpo.ts` in `@clerk/expo` 3.2.0 ([plugin source](https://github.com/clerk/javascript/blob/main/packages/expo/src/plugin/withClerkExpo.ts)): - `appleSignIn: true` (default). The plugin writes the `com.apple.developer.applesignin` entitlement at prebuild time so Sign in with Apple works out of the box. Set it to `false` only if you're certain you don't need Apple Sign-In. - `theme: './clerk-theme.json'` (see the Theming section later). The plugin also reads `EXPO_PUBLIC_CLERK_GOOGLE_IOS_URL_SCHEME` from the environment if you opt into the native `GIDSignIn` path via `useSignInWithGoogle()`. That's a more advanced use case; `` doesn't need it. > The published plugin source does not expose a `keychainService` / App Group option. Keychain sharing between app and extensions lives on the clerk-ios Clerk.Options API and requires a custom config plugin from Expo. See the FAQ for details. ### Wrap the app with `` Open `app/_layout.tsx` and wrap the root `` with [``](https://clerk.com/docs/expo/reference/components/clerk-provider.md). Use the `tokenCache` export from `@clerk/expo/token-cache` so sessions persist across restarts: ```tsx import { ClerkProvider } from '@clerk/expo' import { tokenCache } from '@clerk/expo/token-cache' import { Stack } from 'expo-router' const publishableKey = process.env.EXPO_PUBLIC_CLERK_PUBLISHABLE_KEY! export default function RootLayout() { return ( ) } ``` The token cache stores the Clerk session [JWT](https://clerk.com/docs/guides/sessions/jwt-templates.md) in `expo-secure-store`, which maps to iOS Keychain and Android EncryptedSharedPreferences ([`tokenCache` source](https://github.com/clerk/javascript/blob/main/packages/expo/src/token-cache/index.ts)). Restart the app and the previous session rehydrates. ## Step 3: Create the development build From the project root: ```bash npx expo run:ios ``` The first build compiles React Native and takes several minutes. Subsequent builds cache and finish in tens of seconds. Expo launches the iOS Simulator and runs your app once the build completes. Add `--device` to deploy to a connected iPhone: ```bash npx expo run:ios --device ``` Success criteria: the app launches with the default Expo welcome screen and no red or yellow boxes. If you see "Native module cannot be null" or similar, you're running in Expo Go or against a stale dev build. Re-run `npx expo run:ios`. For Android parity, start an emulator and run: ```bash npx expo run:android ``` See the [Expo iOS development build tutorial](https://docs.expo.dev/tutorial/eas/ios-development-build-for-devices/) if you run into device provisioning issues. ## Step 4: Add Google Sign-In with `` Google Sign-In needs two places to know about each other: Google Cloud Console (which issues the client IDs) and the Clerk Dashboard (which uses them). ### Google Cloud Console setup (iOS primary) In the [Google Cloud Console](https://console.cloud.google.com/apis/credentials): 1. Create an OAuth consent screen (External, fill the minimum fields). This is mandatory before you can create OAuth client IDs. 2. Create the OAuth 2.0 client IDs you need: - **iOS client ID** (required): use the Bundle ID from your `app.json`. - **Web client ID** (required): Clerk uses this for server-side token verification. - **Android client ID** (only if building Android): package name plus the SHA-1 debug fingerprint from `./gradlew signingReport`. Production builds need a separate client ID registered with the release SHA-1. Google's native-apps guide has the canonical walkthrough ([Google Identity, OAuth for Native Apps](https://developers.google.com/identity/protocols/oauth2/native-app)). ### Paste credentials into Clerk Dashboard In the Dashboard, go to **Social Connections → Google** and paste: - iOS Client ID. - Web Client ID. - Web Client Secret. - Android Client ID (if applicable). That's it for configuration. Clerk's config plugin handles the iOS URL scheme; you do not edit `Info.plist` by hand. ### Render `` Create `app/sign-in.tsx`: ```tsx import { AuthView } from '@clerk/expo/native' export default function SignIn() { return } ``` The `mode` prop accepts three values, verified in [AuthView.types.ts](https://github.com/clerk/javascript/blob/main/packages/expo/src/native/AuthView.types.ts): - `'signIn'`: sign-in only. - `'signUp'`: sign-up only. - `'signInOrUp'` (default): combined flow. The native UI decides based on whether the identifier exists. The only other prop is `isDismissible: boolean` (default `false`) for presentations where you want the user to be able to close the sheet. There is no `style` or `appearance` prop; theming lives in `clerk-theme.json` (see the Theming section). ### React to auth state changes Pair `` with `useAuth()` to navigate after sign-in completes. On a fresh native sign-in, there's a short window while the native session syncs into the JavaScript `Clerk` instance; during that window the JS layer sees a `pending` state. Tell `useAuth` to treat `pending` as signed-in so your `useEffect` doesn't misfire: ```tsx import { AuthView } from '@clerk/expo/native' import { useAuth } from '@clerk/expo' import { useRouter } from 'expo-router' import { useEffect } from 'react' export default function SignIn() { const { isSignedIn } = useAuth({ treatPendingAsSignedOut: false }) const router = useRouter() useEffect(() => { if (isSignedIn) router.replace('/') }, [isSignedIn, router]) return } ``` The `treatPendingAsSignedOut: false` flag deserves a proper explanation. Since [`@clerk/clerk-react` 5.26.0 (April 2025, PR #5507)](https://github.com/clerk/javascript/pull/5507), which `@clerk/expo` depends on, `useAuth()` defaults `treatPendingAsSignedOut` to `true`. "Pending" is Clerk's generic state for "a session exists but requires an additional step" (for example, [MFA](https://clerk.com/docs/guides/development/custom-flows/authentication/multi-factor-authentication.md) not yet completed). In the native-components case, pending shows up during the native-session → JS-Clerk sync window: `clerk-ios` has already created a session, and `@clerk/expo` is still syncing it into the React tree. A `useEffect` watching `isSignedIn` with the default `true` would briefly see signed-out and fire, causing a redirect flicker. Setting `treatPendingAsSignedOut: false` bridges the gap for screens that react to native authentication. ### Test the flow Run the dev build and tap the Google button inside ``: ```bash npx expo run:ios ``` iOS has no OS-level Google credential picker. `` opens an `ASWebAuthenticationSession` Safari sheet, the same sheet Google's own `GIDSignIn` iOS SDK uses. The user sees a system-managed Safari interface asking permission to sign in; cookies shared with Safari mean most users continue with one tap. This is the RFC 8252 compliant flow, with browser chrome visible rather than a browserless OS picker. On Android, the same `` opens the Credential Manager bottom sheet ([Android Credential Manager for Sign in with Google](https://developer.android.com/identity/sign-in/credential-manager-siwg)), the fully native experience. The contrast is deliberate: iOS doesn't expose an equivalent OS API. You can cross-reference the full sample code in Clerk's [NativeComponentQuickstart `app/index.tsx`](https://github.com/clerk/clerk-expo-quickstart/blob/main/NativeComponentQuickstart/app/index.tsx). ## Step 5: User management with `` and `useUserProfileModal()` Post-auth UX usually needs two things: a visible affordance for the user to manage their account, and a place to do it. `` is the affordance; `` is the place. ### Place `` in the header `UserButton` has no props. Size is controlled by the parent `` using `width`, `height`, `borderRadius`, and `overflow: 'hidden'` ([UserButton.tsx source](https://github.com/clerk/javascript/blob/main/packages/expo/src/native/UserButton.tsx)). Put it in the Expo Router header's `headerRight`: ```tsx import { UserButton } from '@clerk/expo/native' import { Stack } from 'expo-router' import { View } from 'react-native' export default function HomeLayout() { return ( ( ), }} > ) } ``` Tapping the button opens the native profile modal, a real SwiftUI sheet on iOS, not a React Native ``. ### Use `useUserProfileModal()` to open the profile imperatively If you want a button in another screen (say, a settings row) to open the profile, use the `useUserProfileModal()` hook ([`useUserProfileModal.ts`](https://github.com/clerk/javascript/blob/main/packages/expo/src/hooks/useUserProfileModal.ts)): ```tsx import { useUserProfileModal } from '@clerk/expo' import { Button } from 'react-native' export function AccountRow() { const { presentUserProfile, isAvailable } = useUserProfileModal() if (!isAvailable) return null return