Inside Every RapidNative-Generated App: The 2026 Scaffold

The fastest way to make an AI write good React Native code is to give it less to write.

That is the bet behind every RapidNative-generated app. When a prompt lands and a mobile screen streams back into the preview, the model is not conjuring an app from raw imports. It is landing code inside a react native starter template that already contains an eight-layer provider stack, a full set of semantic design tokens, an auto-refreshing auth hook, an offline manager, a persisted query cache, root-level keyboard handling, and a curated dependency lockfile. All of that is wired before the AI writes a single line.

Most people talking about AI code generation talk about the model. The interesting story is what surrounds the model. This post opens up the fullstack-supabase scaffold — the foundation for every new RapidNative app in 2026 — and walks through what ships, why it ships, and what deliberately does not.

A generated app inherits a working foundation before the first prompt runs — Photo by Christopher Gower on Unsplash

The paradigm shift: primitives + providers, not a component library

Ask ten developers what a "component library" is and you get ten answers that look roughly the same: a package of pre-built Button, Card, Modal, and Input components with a design system baked in. Shadcn, NativeBase, Tamagui, React Native Paper, Gluestack — the whole shelf.

RapidNative ships none of that.

Every generated app has exactly one components file to start with — components/index.ts — and it exports exactly one thing: ThemeToggle. That is not an oversight. It is the design.

The reasoning is uncomfortable but empirically obvious once you have watched a few hundred AI generations run: the more surface area you hand a model, the more surface area it hallucinates against. A component library with 60 primitives, 8 variants per primitive, and a proprietary prop API is a giant undocumented-for-the-model attack surface. The model picks the wrong prop name, imports a component that doesn't exist, mixes v1 and v2 syntax, and the app red-screens in preview.

The react native starter template RapidNative ships instead gives the model a vocabulary it already knows cold: View, Text, Pressable, TextInput, FlatList, ScrollView, Image, and SafeAreaView — plus NativeWind 4 for styling. That is React Native primitives with className support. No abstraction, no wrapper, no proprietary API. If the model has ever seen React Native code, it has seen this.

Everything else — buttons, cards, inputs, sheets, tabs — is composed from primitives on the fly, styled with semantic tokens (more on those below). Every generated app owns its own components, in its own repo, with zero library lock-in. Rip out RapidNative tomorrow and every screen still works, because there is nothing proprietary to rip out.

The eight-layer provider stack — wired once, forgotten forever

Open mobile/app/_layout.tsx in any generated project and you see the same tree:

SafeAreaProvider
 └─ ThemeProvider
     └─ QueryProvider  (persisted outside preview)
         └─ AppProvider
             └─ KeyboardAvoidingView
                 └─ StatusBar
                     └─ Stack (Expo Router)

With useOffline() running as a sidecar hook that pipes NetInfo into TanStack Query's onlineManager.

That is eight things the AI never has to think about. Each one solves a category of bug that used to eat a full afternoon:

1. SafeAreaProvider (from react-native-safe-area-context 5.7) — resolves the notch, dynamic island, home indicator, and status bar inset on every screen automatically. Without it, half of iPhone users see content clipped by hardware.

2. ThemeProvider — reads NativeWind's useColorScheme(), picks lightTheme or darkTheme from theme.ts, and injects the resolved CSS variables into documentElement on web (so React Native Modal, which portals outside the tree on web, still gets the theme). On native, the same variables ride on a wrapping View. Dark mode works everywhere by default.

3. QueryProvider — a QueryClient from @tanstack/react-query 5.90 with different config in preview vs production. In the editor (EXPO_PUBLIC_RAPIDNATIVE_MODE === 'designer') caching is off — you see fresh data on every mount. In an exported app, caching is on with staleTime: 5 min, gcTime: 24 hours, networkMode: 'offlineFirst', and the whole cache is persisted to AsyncStorage through @tanstack/query-async-storage-persister. Your users get instant reloads and offline reads out of the box.

4. AppProvider — wraps the Supabase client in React context, exposed as useApp().client. One canonical entry point for data. No global handles, no ad-hoc imports. The generated code always reaches the database the same way.

5. KeyboardAvoidingView — mounted at the root with behavior={Platform.OS === 'ios' ? 'padding' : 'height'} so form inputs never disappear behind the keyboard on iOS. The single most common bug in hand-written React Native, solved once at the layout level.

6. StatusBar — style="auto" follows the current theme. Light text on dark screens, dark text on light. No developer configuration.

7. Stack (Expo Router 57) — file-based routing over app/(app)/*.tsx (protected) and app/(auth)/*.tsx (public). Add a .tsx file, get a route. No route configuration file to keep in sync.

8. useOffline() — subscribes to @react-native-community/netinfo and calls onlineManager.setOnline() so TanStack Query knows when to pause and resume fetches. Loss of connectivity is handled globally, not per-hook.

Eight providers wired once so screen code stays about the screen — Photo by Ilya Pavlov on Unsplash

Every one of these is a decision that would eat a paragraph in a hand-written app's README. In a RapidNative-generated app, they are inherited automatically. The AI's prompt token budget does not go to reinventing them.

The semantic token system: 25+ CSS variables that make dark mode free

The theme.ts file in every generated app defines a set of CSS variables via NativeWind's vars() helper — for both light and dark modes:

export const lightTheme = vars({
  "--background": "255 255 255",
  "--foreground": "23 23 23",
  "--card": "255 255 255",
  "--card-foreground": "23 23 23",
  "--primary": "24 24 27",
  "--primary-foreground": "250 250 250",
  "--secondary": "244 244 245",
  "--muted": "244 244 245",
  "--muted-foreground": "113 113 122",
  "--accent": "244 244 245",
  "--destructive": "220 38 38",
  "--border": "228 228 231",
  "--input": "228 228 231",
  "--ring": "161 161 170",
  "--chart-1": "231 111 81",
  // ...through chart-5, sidebar, sidebar-primary, etc.
});

There are 25+ tokens across five categories: core surface (background, foreground, card, popover), semantic intent (primary, secondary, accent, muted, destructive), form and focus (border, input, ring), data viz (chart-1 through chart-5), and sidebar/nav (a full second palette for sidebars).

The AI never writes hex colors. It writes className="bg-background text-foreground border-border". Dark mode works because both lightTheme and darkTheme define the same variable names with different values, and NativeWind swaps them based on useColorScheme().

The knock-on effect: every generated screen is theme-aware by default. Users get dark mode for free — not because RapidNative wrote a theming layer for that specific screen, but because the semantic-token contract makes the alternative harder to write. bg-black requires typing more characters than bg-background and produces a worse result.

Each new project rewrites the placeholder palette to fit the app's personality — a fitness tracker gets vibrant greens, a finance app gets muted blues, an audio app gets deep purples — but the token names and structure stay identical. Every screen keeps working through the palette change with zero edits.

The dependency lockfile: the 2026 stack, pinned

A RapidNative-generated app's package.json is a working, tested stack pinned to versions that the AI has been rehearsed against. As of late 2026:

Nothing is latest. Every dependency is pinned to a version that is compatible with Expo SDK 57 and has been through the model's training loop. The AI is allowed to add dependencies but never remove or change existing ones — protecting the invariant that yesterday's generated screen still runs on today's cached preview bundle.

That pinning is not decorative. Anyone who has watched a React Native project quietly break because Reanimated 3 shipped a breaking change on a Tuesday knows what an unpinned stack costs. Expo SDK bumps happen. They happen deliberately, all-at-once, tested end-to-end — not one dependency at a time.

The primitive vocabulary: eight components, styled with className

Every generated screen composes from a short list of primitives:

Every one of these has been in the React Native standard library for years. Every one has thousands of Stack Overflow answers, thousands of GitHub issues resolved, and — critically — thousands of examples in the model's training data. When the AI writes <Pressable onPress={handlePress} className="bg-primary rounded-lg p-4">, it is not guessing at a proprietary API. It is writing idiomatic React Native.

Higher-level components — cards, list rows, sheets, tab bars — are composed on demand, in the project's own components/ folder, owned by the project. The generated app grows a library that fits its own aesthetic, rather than inheriting a generic one.

The invisible guardrails

Some of the most valuable things in the scaffold are things you never notice until you try to write around them:

Web-safe storage. The Supabase client uses AsyncStorage on native and nothing on web. Web bundles are also evaluated in Node during dev-server startup, and AsyncStorage reaches for window inside Supabase's session-restore path. Left as-is, ReferenceError: window is not defined takes down the dev server before it ever listens. Fixed once in src/db/client.ts; every generated project inherits the fix.

Preview auto sign-in. In the editor preview, the Supabase client auto-signs-in as demo@rapidnative.com. This means an auth-gated screen renders as the signed-in state instead of an empty login page, so the AI can build post-login UI and see it work immediately. Exported production apps never touch this path.

Split cache config. The same QueryClient runs with no cache in the editor (fresh data every mount) and full cache + persistence in production. One queryClient.ts, one isPreview branch. The AI writes hooks that work in both without knowing which is which.

Auth cache invalidation. useAuth().signOut doesn't just call client.auth.signOut() — it clears the entire non-auth query cache, so the next screen mount refetches with the new session. Sign-out actually signs out.

Root-level keyboard handling. KeyboardAvoidingView is at the root layout, not per-screen. Every form input across every screen is protected. Screens that need extra care wrap themselves again, but the default is "keyboard doesn't obscure inputs."

Offline sync. useOffline() hooks NetInfo into onlineManager at boot. Every TanStack Query hook automatically pauses on disconnect and resumes on reconnect. Users on flaky networks get consistent behavior across the whole app.

These are the exact patterns that a junior developer would spend a week discovering the hard way. In a RapidNative-generated app, they are gifted at project creation.

The most valuable code in the scaffold is code no one has to write again — Photo by ThisisEngineering on Unsplash

The "don't touch" contract

A short list of files ship complete and are marked read-only to the AI:

• src/db/client.ts — the single Supabase client
• src/db/types.ts — generated from SQL migrations
• src/providers/AppProvider.tsx and ThemeProvider.tsx
• src/hooks/useAuth.ts
• The root app/_layout.tsx
• package.json (adds allowed; removes and changes forbidden)

The reasoning is inverted from most "AI can touch anything" builders: the parts of the app that are most likely to break silently are the parts you least want the AI regenerating on a whim. Auth, the client, the provider tree, generated types — these are load-bearing invariants. The AI writes screens, hooks, and components around them, not through them.

What we deliberately don't ship

Just as important as what is in the scaffold is what is not:

No pre-built UI library. Explained above. Primitives + NativeWind is the whole vocabulary.

No ORM. No Prisma, no Drizzle, no schema-as-code. The database schema lives in supabase/migrations/*.sql, is applied to a real Postgres (PGlite in the editor sandbox, real Supabase in production), and generates src/db/types.ts from the applied state. Anyone who has watched an ORM's TypeScript types drift out of sync with the deployed schema knows why.

No Redux, MobX, Zustand, or Jotai. State lives in React state, refs, and TanStack Query. Server state is cache; UI state is local. The AI never writes a store.

No global styles. Every styling decision runs through NativeWind's className prop. StyleSheet.create() is banned. Hardcoded colors are banned. Consistency is a compile-time property, not a code review artifact.

No mock adapters. The database is real in every environment. What renders in preview is what ships. Test data lives in supabase/seed.sql, applied to the sandbox at boot.

Every "we don't ship this" is a bet that removing a thing makes the model's output more reliable. The bets have paid.

Why this matters for anyone shipping mobile apps with AI

You can build a mobile app with any AI code generator. What you cannot do with most of them is hand the exported code to a React Native developer and have them ship it. The generated project is a bespoke runtime, a proprietary component API, a template you rented, not a codebase you own.

A RapidNative-generated app is idiomatic React Native + Expo + Supabase, in the layout the community expects, using dependencies pinned to versions that were current when Expo SDK 57 shipped. Any React Native developer can open it, read it, extend it. Any CI pipeline can build it. The App Store submission uses eas submit. There is no runtime, no launcher, no proprietary layer between the app and the platform.

The react native starter template underneath is not a marketing feature. It is the reason the AI's output holds up when you ship it.

Try it — see what you inherit

Every RapidNative project starts from this exact scaffold. Describe an app in plain words, watch the AI compose against the primitives you just read about, and inspect what you get back — the code, the provider tree, the semantic tokens, the pinned versions. Export it as a zip whenever you want.

Start building a mobile app free — 20 credits, no card required. If you want to see the exact flow that ports a Lovable or Figma design into this scaffold, our PRD-to-app and image-to-app flows both drop into the same foundation. To go deeper on the underlying pipeline, our state layer walkthrough and fullstack-in-one-prompt posts cover how screens, database, and auth get generated together on top of everything above.

The React Native docs and Expo Router docs are the canonical references for the primitives the AI writes against. NativeWind's documentation explains the className styling system. Reading those three is the fastest way to understand exactly what your generated app is doing.

The scaffold does the boring work. Your prompt does the interesting work. That is the whole trick.