How RapidNative Handles Authentication Flows in AI-Generated Apps

Ask any large language model to "build me a fitness app with login," and the same problem shows up. The model will happily generate a signin screen — but it will also invent an auth library, hallucinate an import path, invent a hook name, and hard-code a made-up base URL. The screen looks fine in a static screenshot. The moment you tap the button, everything breaks.

The React Native authentication flow is the single most fragile thing an AI code generator touches. It sits at the intersection of navigation, secure storage, network calls, error handling, and platform-specific redirects. Get any one of those wrong and the app never gets past the launch screen. This post walks through how RapidNative — an AI mobile app builder that generates real React Native and Expo code — actually structures auth in the apps it produces, why we made those choices, and what you can borrow if you're building your own React Native auth flow.

A generated login screen is the easy part — the hard part is what happens after the button press.

Why authentication is the hardest thing to auto-generate

For most React Native features, the AI can safely pick a library, write the code, and trust that if it breaks, the error is localized. Authentication is different for three reasons.

Auth is stateful across every screen. Every screen has to know whether the user is signed in. That means the AI can't just generate a Login.tsx in isolation — it has to plumb an auth state through the root layout, into a context provider, into every protected screen. Miss one and you get race conditions where the app renders the home screen for a split second before redirecting to login.

Auth is coupled to the backend. A generated login form is worthless without something to log into. But the "right" backend depends on the user: some want Supabase, some want Firebase, some want a custom Node API, some just want a fake login for a hackathon demo. Baking the backend into the generated code creates lock-in that the user often didn't ask for.

Auth is coupled to secure storage. Tokens have to persist across app restarts. On iOS that means the Keychain via expo-secure-store. On Android it's the Keystore. On web it's localStorage. The AI has to pick a strategy that works on every target platform without leaking tokens to logs, redux devtools, or crash reports.

Together, these three constraints mean that "generate an auth flow" is really "generate a state-management pattern, a storage strategy, a backend contract, and four coordinated screens — all at once." That's more coordination than we're willing to trust an LLM with, so we don't.

Two templates, one auth story

RapidNative generates every new project from one of two internal templates: NativeWind themed (UI-only with mock data) and Fullstack (real database, storage, auth). The decision happens inside our routing layer before the LLM ever sees the prompt. If the user asks for something that clearly needs auth ("build a habit tracker where users can save streaks across devices"), we route to the Fullstack template. If they ask for a design-focused prototype ("a sleek weather app UI"), we route to the UI-only template.

The system prompt for the UI-only template is explicit about this split. If a user asks for auth in that template, the AI is told to build the UI with mock data and drop a note: "This project uses the classic UI-only template with mock data. Newer projects on RapidNative come with the Fullstack template — which includes a real database, storage, authentication, and more." The AI does not silently pretend to implement auth. It tells the user the truth.

This is a deliberate design choice. It's the same reason we split full-stack generation into a separate pipeline — features that touch backend contracts have to be predictable, and predictability comes from templates, not from freestyle generation.

UI-only projects get mock auth; Fullstack projects get real auth — and the AI knows the difference before it starts writing.

The auth screens are template-generated, not LLM-generated

When a Fullstack project is created and the AI detects that auth is required (via a needsAuth flag on the project), the signin and signup screens are written by a deterministic tool — not by the language model. The tool lives in our project-templates/fullstack/ai/tools/auth.ts module and it writes four files:

• app/(auth)/_layout.tsx — a Stack navigator that groups signin and signup
• app/(auth)/signin.tsx — a full sign-in screen with email, password, error handling, and a link to signup
• app/(auth)/signup.tsx — the sign-up mirror with password confirmation
• app/_layout.tsx — the root layout, patched to include the auth guard

Why deterministic? Because we've seen every possible way an LLM can subtly break an auth flow. It forgets to handle the loading state. It puts the onSuccess navigation in the wrong closure. It calls signIn from a useEffect instead of an onPress. Auth screens follow a well-known pattern, and once you've written a good one, there is exactly zero reason to have an LLM redraw it every time.

The generated signin screen uses TanStack Query mutations — not a raw fetch and not a plain useState promise. The signIn.mutate call takes onSuccess and onError handlers directly, which keeps navigation and error paths in one readable block:

const handleSignIn = () => {
  setError(null);
  signIn.mutate(
    { email, password },
    {
      onSuccess: () => router.replace('/'),
      onError: (err) => setError(err.message),
    }
  );
};

The AI is still in charge of everything after login — the home screen, the profile page, the actual product surface. But the auth entry-point itself is a fixed asset. It's the same reason airlines use checklists for takeoff: some parts of the system have to work every single time.

The useAuth hook: a backend-agnostic auth layer

The most consequential architectural choice in RapidNative's auth generation is that the generated code never imports Firebase or Supabase directly. Everything goes through a hook:

import { useAuth } from '../../src/hooks';

const { user, session, isAuthenticated, signIn, signUp, signOut } = useAuth();

Under the hood, useAuth wraps a client.auth interface that follows Supabase's method signatures (signInWithPassword, signUp, signOut, getSession) — but the concrete implementation is swapped at runtime. In development, the app boots against a mock backend seeded with demo@example.com / password123. In production, the same code runs against the real Vibecode DB layer, which itself can point at PocketBase or Supabase. The AI-generated screens don't care which one is behind the interface.

This matters for three reasons.

Users can swap backends without regenerating. If someone starts on the free tier with the mock backend and later connects Supabase, none of the generated auth screens have to change. The same signIn.mutate({ email, password }) call works against whichever adapter is loaded.

The AI never sees credentials or SDK versions. Because auth calls go through a generic hook, we don't have to keep a table of "what's the current Firebase v11 API" or "did Supabase rename signInWithOAuth last month." The interface is stable; the adapter changes underneath it.

Errors are typed. The hook throws a custom AuthError class with a reason field ("invalid_credentials", "user_not_found", "network_error"). Generated UI can pattern-match on that reason to show the right message without parsing string messages from a third-party SDK. That's the sort of detail you'd never expect an LLM to get right on its own.

Every generated auth call goes through one hook — the AI writes UI, not SDK integration code.

Expo Router auth groups: routing that protects itself

Auth screens live under app/(auth)/ — an Expo Router route group. Groups in Expo Router are folders in parentheses that don't add a URL segment. So app/(auth)/signin.tsx becomes /signin, not /auth/signin. That gives us a clean way to bundle auth-only screens under a shared layout without polluting the URL scheme.

The _layout.tsx inside the group defines a Stack navigator with two screens (signin, signup) and hides the header. The root _layout.tsx — one level up — is where the guard lives:

useEffect(() => {
  if (isLoading || isDesigner) return;
  if (!isAuthenticated && !inAuthGroup) {
    router.replace('/(auth)/signin');
  } else if (isAuthenticated && inAuthGroup) {
    router.replace('/');
  }
}, [isAuthenticated, segments, isLoading]);

Two things to note. First, the guard runs at the root, not inside individual screens. Second, it checks segments[0] === '(auth)' before redirecting — otherwise you'd bounce a signed-in user off the signin screen before they saw the redirect, which is jarring.

This is closer to what RapidNative's navigation and routing generator produces for every project: a small number of hard rules that the generated screens can't accidentally violate.

Preview vs production: how auth behaves in the studio

Here's a problem specific to AI app builders: the studio has to show the user their app while they're still building it. If we naively ran the auth guard in the preview iframe, every user would see the signin screen — of their own app — before they could see what they built. Worse, they'd have no credentials because they haven't set up a backend yet.

Our fix is a EXPO_PUBLIC_ENV environment variable. When the preview runs inside the RapidNative studio, we set EXPO_PUBLIC_ENV=designer and the auth guard skips itself:

const isDesigner = process.env.EXPO_PUBLIC_ENV === 'designer';

useEffect(() => {
  if (isLoading || isDesigner) return;
  // ... auth guard logic
}, [/* deps */]);

When the same app is exported as a real Expo project and run on a device, EXPO_PUBLIC_ENV is unset (or set to production) and the guard behaves normally. This is the same trick that our real-device preview pipeline uses — the preview is the app, minus one env variable's worth of behavior.

There's a second preview mode too. When the project is deployed as a shareable web preview (EXPO_PUBLIC_ENV=pwa), the auth guard does run, but the signin screen renders a small badge under the form:

{process.env.EXPO_PUBLIC_ENV === 'pwa' && (
  <View className="px-4 py-3 rounded-xl border border-primary/20">
    <Text className="text-xs text-center">
      demo@example.com · password123
    </Text>
  </View>
)}

That badge only shows in the shareable demo — never in the real app store build. It's a small quality-of-life detail, but it's the difference between "here's a demo you can play with in 10 seconds" and "here's an app you have to email me credentials for."

What we deliberately don't generate

There are three things RapidNative does not put in generated auth screens, and each is a design decision.

No OAuth providers by default. Google, Apple, and Facebook sign-in each require app-store-level configuration (bundle IDs, callback URLs, provider consoles) that the AI can't do for the user. We generate email/password as the safe starting point and leave the OAuth wiring for a later step, when the user has already exported and is ready to configure a real backend. This is the same reason we're careful about what integrations we scaffold — hallucinating a Google Sign-In config file is worse than not generating one at all.

No JWT decoding in the generated code. The session object returned by useAuth is opaque to the UI. Screens read session.user.id or session.expires_at; they never crack open a raw JWT. That keeps the app portable across backends that use JWTs, session cookies, or opaque tokens.

No "remember me" or biometric unlock. These are great features, but they belong in a "post-launch polish" pass, not in the first thing the AI generates. Adding them by default would create surface area where the AI could get subtle behaviors wrong — like storing a token in the wrong keystore on Android, which is exactly the kind of security bug you don't want an AI shipping.

The philosophy is the same across all of our generation logic: do a small number of things predictably well, and leave the rest as an obvious next step.

Adapting this pattern in your own React Native app

If you're building your own React Native authentication flow — with or without an AI generator — here's what's worth stealing.

1. Put the auth guard in the root layout, not per-screen. One check, one redirect, one place to reason about. Every screen inside the tree assumes the user is signed in.
2. Wrap your backend behind a hook, not a direct SDK import. Even if you only ever use Supabase, the useAuth hook lets you fake auth in tests, swap adapters in Storybook, and change SDK versions in one place.
3. Use route groups ((auth)) instead of separate stacks. Fewer navigators, cleaner URLs, and the auth screens still get their own layout when they need it.
4. Type your auth errors. Give every failure a machine-readable reason alongside the human message. Your UI code will be dramatically more readable.
5. Design for a "preview" mode from day one. Even in a hand-written app, having an IS_DEMO env variable that bypasses auth for demos and reviews is worth its weight in gold when you're pitching investors or onboarding new engineers.

None of these ideas are new. But the reason we ended up with all five is that generating auth automatically forces you to make every implicit assumption explicit — and once you've done that, the pattern gets clearer than any tutorial can show you.

Design for preview mode from day one — it pays off in demos, tests, and code reviews.

People also ask

Does RapidNative support social login (Google, Apple) in generated apps? Not by default. Email/password is generated on project creation. Social providers require app-store credentials and callback URLs that the AI can't configure for you, so they're a post-export step where you connect real provider keys in your own account. The generated useAuth hook is designed so social sign-in can be added without changing any existing screen.

Which backend does RapidNative use for auth in generated apps? The generated code is backend-agnostic — it calls a generic client.auth interface that mirrors Supabase's method names. In the preview, that interface is backed by a mock adapter with a demo user. When you export the project, you can point it at Supabase, PocketBase, or your own API by swapping the adapter — no auth-screen changes required.

How does RapidNative handle secure token storage in generated apps? The useAuth hook delegates token storage to the underlying adapter. On device, the Vibecode DB adapter uses expo-secure-store (Keychain on iOS, Keystore on Android). On web previews, it falls back to localStorage. Generated UI code never touches tokens directly.

Where this fits in the bigger picture

Authentication is one slice of a bigger story. We use the same "template for the fragile parts, LLM for the creative parts" pattern for state management, navigation, and asset pipelines. The result is that a project generated by RapidNative isn't a disposable prototype — it's a real Expo app you can hand off to a developer, publish to the App Store, or extend indefinitely.

If you want to see it work end to end, describe an app on RapidNative — anything from "a habit tracker with cross-device sync" to "a private social feed for a book club" — and watch it generate the signin flow, wire up the auth guard, and drop you into a preview you can log into with demo credentials. Then export the code and read the app/(auth)/ folder. Every file in there is one we discussed above.

Compared with wiring up Firebase Auth , Supabase Auth , or Clerk from scratch, the win isn't that we generate a login screen — anyone can generate a login screen. The win is that the screen is wired to a hook, the hook is wired to an adapter, the adapter is wired to a mockable backend, and the whole thing behaves correctly in preview, in exports, and in production without anyone having to think about it.

That's the difference between an AI-generated app and an AI-generated demo.