Skip to main content
Articles

How to Use AuthView in an Expo App: Native Authentication with Clerk

Author: Roy Anger
Published: (last updated )

This is the first part of a two-part series on building a native authentication flow in an Expo app with Clerk's AuthView component. In this part, you will learn why native authentication matters, set up a Clerk application, initialize an Expo project, and build the initial sign-in screen using AuthView. Part 2 will cover the full home screen, managing user profiles, and handling authentication state.

Mobile authentication is one of the most complex parts of app development. Traditional approaches force developers to either build custom sign-in flows from scratch — often requiring hundreds of lines of code — or rely on WebView-based components that break the native user experience. Clerk's AuthView component changes this by rendering a fully native authentication UI with roughly five lines of code.

In this tutorial, you will build a complete Expo app with native sign-in and sign-up powered by AuthView. The finished app includes a public home screen, a native authentication screen, and a user profile page with Clerk's UserButton and UserProfileView components. AuthView is currently in beta — the core API is stable, but check the Clerk changelog for the latest status.

By the end of this guide, you will understand how AuthView works under the hood, how it synchronizes native sessions with the JavaScript SDK, and why native authentication outperforms WebView-based approaches in both security and user experience.

What is AuthView?

AuthView is Clerk's native authentication component for Expo. Import it from @clerk/expo/native and it renders a complete sign-in and sign-up interface using SwiftUI on iOS and Jetpack Compose on Android. This is not a WebView wrapping a web page — it is a genuinely native UI built with each platform's own design framework.

AuthView automatically handles the full authentication lifecycle based on your Clerk Dashboard configuration. This includes email and password sign-in, email verification codes, OAuth providers like Google and Apple, passkeys, multi-factor authentication (MFA), and password recovery. When you enable a new authentication method in the Dashboard, AuthView picks it up automatically — no code changes or app updates needed.

AuthView was released in March 2026 with @clerk/expo 3.1 (changelog). It has intentionally minimal props:

  • mode — accepts "signIn", "signUp", or "signInOrUp" (default). Determines which authentication flows are shown.
  • isDismissible — a boolean (default true) that shows a dismiss button in the navigation bar. Set it to false to require the user to complete authentication before the view can close.
  • onDismiss — an optional callback that fires when the user dismisses the view, or when the native flow finishes and requests dismissal.
  • logo — an optional React Native element that replaces the logo configured in the Dashboard. It must define its own layout and accessibility behavior.
  • logoMaxHeight — the maximum logo height in density-independent pixels (default 44).

For the current list, see the AuthView reference.

This simplicity is by design. Authentication configuration belongs in the Clerk Dashboard, not scattered through your codebase. AuthView requires roughly five lines of code where a custom flow approach needs 25 or more lines per OAuth provider, plus manual state management, error handling, and token exchange logic.

Why native authentication matters for mobile apps

Native authentication UIs provide meaningful advantages over WebView-based approaches in security, user experience, and conversion rates.

Security

RFC 8252 — the IETF standard for OAuth 2.0 in native apps — explicitly states that native apps "MUST NOT use embedded user-agents" (Section 8.12) for authentication. Embedded WebViews expose credentials to the host app, enable phishing by hiding or spoofing the URL bar, and prevent users from verifying the identity of the authentication server.

Google enforces this standard: OAuth sign-in via embedded WebViews is prohibited, as announced in 2016, requiring developers to use Chrome Custom Tabs (Android) or ASWebAuthenticationSession (iOS) instead. An Android WebView AutoSpill vulnerability demonstrated the risk by leaking credentials from the top 10 password managers through WebView autofill behavior.

AuthView avoids these risks entirely. It never uses an embedded WebView: on Android, Google Sign-In runs through the native Credential Manager API; on iOS, Apple Sign-In uses the native Sign in with Apple API (ASAuthorization); and other providers open in a secure system browser (ASWebAuthenticationSession on iOS, Chrome Custom Tabs on Android) rather than an in-app WebView. This matches the security model that platform vendors require. Firebase Auth and Supabase Auth, by contrast, offer no pre-built native UI components for Expo — developers must build their own login screens in React Native and wire up the OAuth flows themselves.

User experience and conversion

Authentication friction directly impacts conversion. Each additional authentication step reduces conversion by 10–15%, and 46% of US consumers report failing to complete transactions due to authentication problems.

Native authentication UIs avoid embedded WebViews entirely, render instantly without WebView startup time, and provide platform-consistent design that users trust. They also cut down on browser hand-offs — password, passkey, and MFA flows never leave the app, and Google Sign-In on Android runs through Credential Manager — though some OAuth providers still complete in a secure system browser session. They also integrate with biometric authentication natively — 81% of smartphones had biometrics enabled as of 2022 (per Cisco Duo's Trusted Access Report), and Amazon reported 6x faster sign-in after deploying passkeys to 175 million users.

What you'll build

The finished app uses Expo Router's file-based routing with a public home screen at the root and two route groups: one for authentication screens and one for protected content.

src/app/
├── _layout.tsx          ← ClerkProvider setup
├── index.tsx            ← Public home screen with conditional content
├── (auth)/
│   ├── _layout.tsx      ← Redirects signed-in users to home
│   └── sign-in.tsx      ← AuthView component
└── (protected)/
    ├── _layout.tsx      ← Redirects signed-out users to sign-in
    └── profile.tsx      ← UserButton + UserProfileView

Each screen serves a distinct purpose:

  • _layout.tsx (root) — wraps the entire app with ClerkProvider for authentication state management
  • index.tsx — the public home screen. It shows different content based on authentication state using the Show component, so it renders for signed-out visitors as well as signed-in users.
  • (auth)/sign-in.tsx — renders AuthView for native sign-in and sign-up
  • (protected)/profile.tsx — displays the user's profile with UserButton (avatar with native modal) and UserProfileView (inline profile management). The (protected) layout guards everything in this group, so only signed-in users reach it.

Prerequisites

Tools and accounts needed

Before starting, confirm you have the following:

  • Node.js — LTS version (20.x or later). Download from nodejs.org.
  • A Clerk account — create one at clerk.com and set up an application in the Clerk Dashboard.
  • Xcode (for iOS) or Android Studio (for Android) — at least one is required to run a development build.
  • Basic familiarity with React and TypeScript — you do not need to be an expert. This tutorial explains each code snippet line by line.

Why a development build is required

AuthView uses native modules — SwiftUI on iOS and Jetpack Compose on Android — that are compiled into the app binary. These modules are not available in Expo Go, which only includes a fixed set of pre-bundled libraries.

A development build is a debug version of your app that includes expo-dev-client and any custom native modules your project needs. Create one by running npx expo run:ios or npx expo run:android instead of npx expo start.

Important

Expo Go cannot run AuthView or any other Clerk native component. You must use a development build for this entire tutorial. If you see "Native module not available" errors, you are likely running in Expo Go.

The development build is a one-time setup cost. Once built, JavaScript changes still hot-reload instantly — you only need to rebuild when adding or removing native dependencies.

Checkpoint: You should now have Node.js installed, a Clerk account created, and either Xcode or Android Studio set up.

Setting up the Clerk application

Create a Clerk application

  1. Sign in to the Clerk Dashboard
  2. Select Create application (or use an existing one)
  3. Choose the authentication methods you want to support — email, password, Google, Apple, or any combination
  4. Copy your Publishable Key from the API keys section — you will need this in a later step

Enable the Native API

AuthView communicates with Clerk's backend through native SDK endpoints that must be explicitly enabled.

  1. In the Clerk Dashboard, navigate to the Native applications page
  2. Toggle Native API to enabled

This setting exposes the endpoints that AuthView needs for native sign-in, sign-up, and session management. Without it, native components will fail to authenticate.

Configure social connections (optional)

If you want Google Sign-In or Apple Sign-In, configure them in the Clerk Dashboard under SSO connections → Social. AuthView handles these flows automatically once they are enabled — you do not need to install additional packages or write custom hooks.

  • Google Sign-In uses the native Credential Manager API (Sign in with Google) on Android and a secure system browser (ASWebAuthenticationSession) on iOS — never an embedded WebView
  • Apple Sign-In uses the native Sign in with Apple API (ASAuthorization) on iOS; on Android, where Apple provides no native SDK, it runs in a secure system browser (Chrome Custom Tabs)

For detailed setup instructions, see the Clerk guides for Sign in with Google and Sign in with Apple.

Tip

This tutorial works without any social connections configured. Email and password authentication is sufficient to follow along. You can add social providers later — AuthView picks them up without app-code changes, but native Google and Apple Sign-In still require the one-time platform setup in the guides above (OAuth credentials, native application registration, and a rebuild).

Checkpoint: You should now have a Clerk application with authentication methods configured, Native API enabled, and your Publishable Key copied.

Creating the Expo project

Initialize a new Expo app

Create a new project using create-expo-app with the SDK 55 template:

npx create-expo-app@latest clerk-expo-authview --template default@sdk-55

The --template default@sdk-55 flag pins the project to Expo SDK 55. Without it, @latest may pull a different SDK version during transition periods, causing the template structure to differ from this tutorial.

Navigate into the project directory:

cd clerk-expo-authview

Note

As of SDK 55, the default template uses a src/app/ directory structure. All file paths in this tutorial are under src/app/. If you are using SDK 54 or earlier, routes are under app/ instead — adjust paths accordingly. The older template also includes app/(tabs)/, app/modal.tsx, and app/+not-found.tsx instead of the files listed below.

Remove default template files

The default template includes starter routes you do not need. src/app/explore.tsx is unused, and the template's src/app/index.tsx pulls in demo components and animation dependencies you are about to uninstall — you will write your own index.tsx further down. Remove them both:

rm -f src/app/index.tsx src/app/explore.tsx

Uninstall react-native-reanimated and react-native-worklets to avoid Android build issues:

npx expo uninstall react-native-reanimated react-native-worklets

Open src/app/_layout.tsx and remove the react-native-reanimated import line if present. You will replace the full contents of this file in the ClerkProvider setup step.

Install dependencies

Install the required packages:

npx expo install @clerk/expo expo-secure-store expo-dev-client

Each package serves a specific purpose:

  • @clerk/expo — Clerk's Expo SDK with native component support. Includes AuthView, UserButton, UserProfileView, and all authentication hooks.
  • expo-secure-store — encrypted token storage using iOS Keychain and Android Keystore. Clerk uses this to persist session tokens securely across app restarts.
  • expo-dev-client — enables development builds with custom native modules. Required because AuthView uses SwiftUI and Jetpack Compose code that Expo Go cannot run.

Note

Some Clerk tutorials also install expo-auth-session and expo-web-browser. These are optional peer dependencies only needed for browser-based OAuth flows using the useSSO or useOAuth hooks. AuthView handles OAuth entirely through native platform APIs, so these packages are not required for this tutorial.

Set environment variables

Create a .env file in the project root:

EXPO_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_your-key-here

Replace pk_test_your-key-here with the Publishable Key from your Clerk Dashboard.

The EXPO_PUBLIC_ prefix makes the variable accessible to client-side code. Metro (Expo's bundler) inlines environment variables with this prefix at build time.

Important

If Metro bundler was running before you installed the native modules, stop it now. After installing native dependencies, restart with npx expo start -c (the -c flag clears the bundler cache) or run npx expo run:ios / npx expo run:android for a fresh development build. This prevents "native module not available" errors from stale cache.

Configure app.json plugins

Open app.json and add the required plugins to the expo.plugins array:

{
  "expo": {
    "plugins": ["expo-router", "expo-secure-store", "@clerk/expo"]
  }
}

The @clerk/expo plugin integrates the native Clerk SDKs (clerk-ios and clerk-android) during the build process. It defaults to enabling the Apple Sign-In entitlement (appleSignIn: true). If you do not need Apple Sign-In, disable it explicitly:

{
  "expo": {
    "plugins": ["expo-router", "expo-secure-store", ["@clerk/expo", { "appleSignIn": false }]]
  }
}

Run your first development build to verify everything compiles:

npx expo run:ios

Or for Android:

npx expo run:android

Checkpoint: You should now have a configured Expo project with all dependencies installed and a successful development build.

Setting up ClerkProvider

Replace the contents of src/app/_layout.tsx with the following:

import { ClerkProvider } from '@clerk/expo'
import { tokenCache } from '@clerk/expo/token-cache'
import { Slot } from 'expo-router'

const publishableKey = process.env.EXPO_PUBLIC_CLERK_PUBLISHABLE_KEY!

if (!publishableKey) {
  throw new Error('Add EXPO_PUBLIC_CLERK_PUBLISHABLE_KEY to your .env file')
}

export default function RootLayout() {
  return (
    <ClerkProvider publishableKey={publishableKey} tokenCache={tokenCache}>
      <Slot />
    </ClerkProvider>
  )
}

Here is what each part does:

  • publishableKey — reads the EXPO_PUBLIC_CLERK_PUBLISHABLE_KEY value from the .env file you created earlier. The process.env.EXPO_PUBLIC_CLERK_PUBLISHABLE_KEY reference works because Metro inlines environment variables with this prefix at build time. This is required in Core 3 — the @clerk/expo SDK does not auto-detect environment variables.
  • tokenCache — imported from @clerk/expo/token-cache, this uses expo-secure-store under the hood. On iOS, tokens are stored in the Keychain (encrypted by Secure Enclave). On Android, tokens are stored in SharedPreferences encrypted with the Android Keystore. Sessions persist across app restarts.
  • Slot — an Expo Router component that renders the current route's content. This is the standard pattern for layout files.

Session tokens have a 60-second lifetime and are proactively refreshed every 50 seconds, so the user's authentication state stays current without any manual token management.

Checkpoint: ClerkProvider wraps the entire app. The app should still compile and run without errors.

Adding a starter home screen

You deleted the template's index.tsx, so the app has no route at / yet — Expo Router would show its "unmatched route" screen on launch. Create a minimal src/app/index.tsx to serve as the app's entry point:

import { Link } from 'expo-router'
import { View, Text, StyleSheet } from 'react-native'

export default function HomeScreen() {
  return (
    <View style={styles.container}>
      <Text style={styles.title}>Welcome to Clerk + Expo</Text>
      <Link href="/(auth)/sign-in" style={styles.link}>
        <Text style={styles.linkText}>Sign In</Text>
      </Link>
    </View>
  )
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    padding: 20,
  },
  title: {
    fontSize: 24,
    fontWeight: 'bold',
    marginBottom: 20,
  },
  link: {
    padding: 12,
  },
  linkText: {
    fontSize: 16,
    color: '#6C47FF',
    fontWeight: '600',
  },
})

This gives you a public landing screen and a way to reach the sign-in route you build next. In Part 2 you will replace it with a version that renders different content for signed-in and signed-out users.

Building the authentication screen with AuthView

Create the auth route group

Expo Router uses route groups — directories wrapped in parentheses like (auth) — to organize routes without affecting the URL structure. Create the auth layout at src/app/(auth)/_layout.tsx:

import { useAuth } from '@clerk/expo'
import { Redirect, Slot } from 'expo-router'

export default function AuthLayout() {
  const { isSignedIn, isLoaded } = useAuth()

  if (!isLoaded) {
    return null
  }

  if (isSignedIn) {
    return <Redirect href="/" />
  }

  return <Slot />
}

This layout checks the user's authentication state before rendering any auth screens:

  • isLoaded — prevents premature redirects while Clerk's auth state initializes. Without this check, the layout might redirect before knowing whether the user is signed in.
  • isSignedIn — if the user is already authenticated, the <Redirect> component navigates them to the home screen. This prevents signed-in users from seeing the sign-in screen.
  • <Slot /> — renders child routes (in this case, sign-in.tsx) when the user is not signed in.

Note

This tutorial uses the <Redirect> component from expo-router rather than imperative router.replace() inside render. <Redirect> integrates correctly with the navigation stack and avoids flash or back-stack issues. Clerk's minimal quickstart uses a simpler single-screen approach without route groups, but route groups scale better for production apps with multiple screens.

Add the sign-in screen with AuthView

Create src/app/(auth)/sign-in.tsx — this is the core of the tutorial:

import { useAuth } from '@clerk/expo'
import { AuthView } from '@clerk/expo/native'
import { useRouter } from 'expo-router'
import { useEffect } from 'react'
import { View, StyleSheet } from 'react-native'

export default function SignInScreen() {
  const { isSignedIn } = useAuth({ treatPendingAsSignedOut: false })
  const router = useRouter()

  useEffect(() => {
    if (isSignedIn) {
      router.replace('/')
    }
  }, [isSignedIn])

  return (
    <View style={styles.container}>
      <AuthView />
    </View>
  )
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
  },
})

Here is a line-by-line breakdown:

  • AuthView is imported from @clerk/expo/native — this is the native component entry point, separate from web components at @clerk/expo/web.
  • useAuth with pending state disabled — passing { treatPendingAsSignedOut: false } is critical. When a user authenticates through AuthView, the native SDK creates a session before the JavaScript SDK knows about it. There is a brief "pending" period during synchronization. With the default { treatPendingAsSignedOut: true }, isSignedIn flashes false during this sync, causing redirect loops. Setting it to false treats the pending state as signed-in, allowing the sync to complete.
  • useEffect watches isSignedIn and redirects to the home screen when authentication completes.
  • <AuthView /> fills its parent container. The flex: 1 style ensures it takes up the full screen.

The session synchronization flow works as follows:

  1. The user interacts with the native AuthView UI
  2. The native SDK (clerk-ios or clerk-android) creates a session
  3. @clerk/expo syncs the native session to the JavaScript SDK
  4. React hooks (useAuth, useUser) update automatically
  5. The useEffect detects isSignedIn === true and triggers navigation

Understanding AuthView props

AuthView's prop list stays short — mode, isDismissible, onDismiss, logo, and logoMaxHeight — because authentication methods are configured in the Clerk Dashboard, not in code.

The mode prop controls which flows are displayed:

<AuthView />

This is equivalent to setting mode="signInOrUp".

To restrict to sign-in only:

<AuthView mode="signIn" />

To restrict to sign-up only:

<AuthView mode="signUp" />

The isDismissible prop controls whether the user can dismiss the authentication screen. It defaults to true, which shows a dismiss button in the navigation bar. Set it to false when authentication is required and the user must complete it before continuing:

<AuthView isDismissible={false} />

Pair isDismissible with the onDismiss callback to run navigation or cleanup logic when the user closes a dismissible view.

Checkpoint: Run the app, tap Sign In on the home screen, and you should see the native sign-in/sign-up interface. Create a test account to verify authentication completes — you land back on the home screen, which confirms the redirect fired.

Conclusion

You have successfully set up your Clerk application, configured your Expo project with the necessary native dependencies, and built a native authentication screen using AuthView. The app is now capable of handling sign-in and sign-up flows securely using platform-native UI. In Part 2, you will turn the starter home screen into a state-aware one, add a protected profile route with user profile management, and learn how to handle authentication state and navigation across your app.

Frequently asked questions

In this series

  1. How to Use AuthView in an Expo App: Native Authentication with Clerk (you are here)
  2. How to Use AuthView in an Expo App: Native Authentication with Clerk - Part 2