What Ships in Every RapidNative-Generated React Native App

Every AI app builder makes the same implicit promise: describe your idea and get a working app. What almost none of them tell you upfront is what that app is actually built on — the runtime, the navigation library, the styling system, the icon set, the state management, the animation primitives. All of that matters. Change a UI library and you can rebuild a screen in an afternoon. Change a state management library and you are rewriting for a week.

At RapidNative we ship the same production-grade React Native starter template inside every generated app. No mystery bundle. No proprietary runtime. Just a versioned, opinionated Expo project you could clone by hand and recognize immediately. This post is a full audit of what is inside — the packages, the versions, the design decisions, and the choices we deliberately made not to ship.

If you are evaluating an AI React Native app generator, or just curious what a modern React Native starter template looks like in 2026, this is the blueprint.

Photo by Markus Spiske on Unsplash

Why the stack matters more than the AI

The best AI-generated code is worthless if it lives on an unmaintained foundation. That is the trap most no-code tools fall into — they generate something that looks great inside a browser preview but becomes a black box the moment you try to eject it. You cannot ship to the App Store. You cannot debug on a real device. You cannot hand it to a React Native developer to extend.

We chose the opposite path. Every RapidNative project is a real Expo app, using the same libraries a senior mobile team would pick if they were greenfielding a product today. If you export the code, you get a clean project that runs with npm install && npx expo start. There is no runtime translation layer. There is no proprietary component format. What you see in the preview is what runs on device.

That decision cascades into every other stack choice below. Let's walk through it end to end.

The runtime foundation: Expo 54, React Native 0.81, React 19

Every generated app ships with the current stable versions of the core runtime:

• Expo 54.0.13 — the managed workflow, EAS Build integration, and the entire expo-* module ecosystem
• React Native 0.81.4 — the New Architecture is on by default; Fabric renderer and TurboModules are live
• React 19.1.0 — Server Components on web preview, use hook, the new ref prop API
• React DOM 19.1.0 — because every project also runs in the browser via react-native-web
• TypeScript 5.9.3 — strict mode, no any in generated code

The choice of Expo over bare React Native was not close. Expo gives us EAS Build for iOS and Android artifacts without asking users to install Xcode. It gives us over-the-air updates without wiring CodePush by hand. It gives us expo-router, which we will get to next. And every expo-* module we use is vetted for the New Architecture — no more praying that react-native-vector-icons will work on a fresh install.

The React 19 version is more interesting. React Native 0.81 formally supports React 19, which means we get the React 19 use hook for reading promises inline in components, the improved ref forwarding, and Server Components in the web preview build. Generated code takes advantage of these where they simplify data-fetching patterns.

Navigation: Expo Router 6 (file-based routing)

Navigation is one of the most-argued corners of React Native. React Navigation, Expo Router, react-native-navigation — they all have loyalists. We picked Expo Router 6.0.12 and stopped debating.

Expo Router is file-based routing. If you have used Next.js App Router, you already know the mental model: the file system is the route table. app/index.tsx is your home screen. app/(tabs)/profile.tsx is inside a tab layout. app/settings/notifications.tsx is a nested route.

Under the hood, Expo Router is a thin wrapper around @react-navigation/native 7.1.18 and @react-navigation/bottom-tabs 7.4.9, so nothing is being reinvented. What Expo Router adds is deterministic routing — the AI can generate a new screen just by writing a file in the right location, without touching a central navigator config. That is a huge win for an AI code generator, because it means every screen is a self-contained artifact you can add, delete, or move without regressing the rest of the app.

The templates also install react-native-web 0.21.1 so every route renders in the browser preview. This is the mechanism behind RapidNative's real-time preview: the same route files render inside an iframe as you edit, then compile to native when you scan the QR code.

Photo by Andrew Neel on Unsplash

Styling: NativeWind 4 + a semantic token system

The templates ship with NativeWind 4.2.1 — Tailwind CSS for React Native — as the sole styling system. There is no StyleSheet.create() in generated code. Every visual property lives in a className string.

The Tailwind config extends far beyond utility classes. It defines a semantic color token system that mirrors what shadcn/ui uses on the web:

• background, foreground — page-level colors
• card, card-foreground — surface colors
• primary, primary-foreground — brand accent
• secondary, muted, accent, destructive — semantic variants
• border, input, ring — form controls
• chart-1 through chart-5 — data visualization
• sidebar-* — layout chrome

These tokens are defined as CSS variables in a theme.ts file that is loaded through NativeWind's cssInterop. That means a single change to theme.ts flips the entire app between light and dark mode — every generated screen uses bg-background text-foreground instead of hardcoded hex values, so re-theming an app is a five-line diff.

Also shipped:

• tailwindcss 3.4.18 — the underlying utility engine
• tailwind-variants 0.1.20 — for building component variant APIs (button sizes, card styles)
• react-native-css-interop 0.2.1 — the runtime that maps className to native style props

We chose NativeWind over Tamagui, Restyle, and Unistyles for one blunt reason: Tailwind is what the AI already knows. Every open-source LLM has ingested millions of Tailwind class strings. Generation quality is markedly higher than any competing styling system.

The component vocabulary: primitives, not pre-built libraries

Here is the choice that surprises most people. We do not ship a component library.

No shadcn-for-React-Native. No React Native Paper. No React Native Elements. No Gluestack. The generated apps use React Native's built-in primitives — View, Text, Pressable, ScrollView, FlatList, TextInput, Modal, Image — plus a very small custom kit for theme-aware wrappers.

Why? Two reasons.

First, information density. A pre-built UI library forces the AI to memorize dozens of custom component APIs. Generation errors compound. The user asks for a "checkout button with an icon on the right" and the AI has to remember whether it is <Button rightIcon={...}> or <Button icon="right"> or <Button>...<ButtonIcon /></Button>. When you compose from primitives, there is one API to remember: <Pressable><View><Text>Checkout</Text><ChevronRightIcon /></View></Pressable>. The AI writes it correctly every time.

Second, exportability. When you export a RapidNative project and hand it to a React Native developer, there is nothing proprietary to learn. It is idiomatic React Native code. There is no upstream dependency that could ship a breaking change and silently break every generated app.

The tradeoff is real: pixel-perfect components take slightly more lines. We accept that tradeoff because the resulting code is portable, maintainable, and does not paint the user into a corner.

For heavier interactions we do ship a small set of headless primitives:

• @gorhom/bottom-sheet 5.0.0-alpha.11 — modal drawers with gesture handling
• react-aria 3.44.0 and react-stately 3.42.0 — accessibility primitives on the web preview
• @expo/html-elements 0.12.5 — semantic HTML on the web build

Icons: Lucide (with a curated 143-icon subset)

Every project ships with lucide-react-native 0.510.0. That is the entire Lucide icon set — over 1,400 icons, exposed as tree-shakable React components.

But the AI is not allowed to pick from all 1,400. The system prompt whitelists 143 curated icons — Home, Search, Bell, User, Settings, Heart, Star, Plus, ChevronLeft/Right, and so on. Every icon in that list has been checked to render correctly on iOS, Android, and web with the shipped icon runtime.

Why constrain it? Because outside that curated list, LLMs hallucinate. Ask an AI to add a "trending stocks" icon and it will confidently import TrendingChartIcon which does not exist in Lucide. Constraining the vocabulary at generation time turns "does this icon exist?" from a runtime question into a compile-time guarantee. If the AI ever needs an icon outside the list, there is an escape hatch — a QuickEdit that expands the vocabulary — but the default set covers 99% of real screens.

All icons are wired through NativeWind's cssInterop so they respect Tailwind color classes. <HomeIcon className="text-primary" /> picks up the theme's primary color on both light and dark mode without a single useColorScheme call.

Data and state: Vibecode DB + TanStack Query 5

The fullstack template ships with a real data layer. This is what separates a generated UI mockup from a generated product.

Vibecode DB (@vibecode-db/client 3.0.4) is a multi-adapter client abstraction. It provides a single API surface — client.from('users').select('*') — but under the hood it can talk to:

1. A mock in-memory store with seed data (default in the preview)
2. PocketBase (pocketbase ^0.26.8) for self-hosted deployments
3. Supabase (@supabase/supabase-js ^2.90.1) for hosted Postgres + auth

The AI writes the same query code regardless of the adapter. That means a project starts life running against seeded mock data — no backend required to see the preview render with realistic content — and switches to a real backend the moment the user connects one.

On top of the client sits TanStack Query 5.90.16 with two persistence add-ons:

• @tanstack/react-query-persist-client 5.90.18 — cache persistence between app launches
• @tanstack/query-async-storage-persister 5.90.18 — writes the cache to AsyncStorage

And @react-native-async-storage/async-storage 2.2.0 provides the underlying storage layer, plus @react-native-community/netinfo ^11.4.1 so the app knows when it is offline and can defer mutations.

The pattern the AI writes looks like this:

const { client } = useApp();
const { data: users, isLoading } = useQuery({
  queryKey: ['users'],
  queryFn: async () => {
    const { data } = await client.from('users').select('*');
    return data;
  }
});

That is idiomatic TanStack Query. Every React Native developer will read it and know exactly what it does. The useApp() hook is the one thin custom layer — it hands back the active database client from context.

There is also expo-sqlite ~16.0.10 and sql.js ^1.14.0 available for projects that need a local-only database (an offline journaling app, a workout tracker). And zod ^3.25.76 ships for runtime schema validation of API responses.

Photo by William Iven on Unsplash

Animation and interaction: Reanimated 4, Legend Motion, Gesture Handler

The animation stack is opinionated and fast.

• react-native-reanimated 4.1.3 — the modern Reanimated with worklets running on the UI thread
• react-native-worklets 0.5.1 — worklet runtime
• @legendapp/motion 2.4.0 — declarative animation API built on top of Reanimated
• react-native-gesture-handler 2.28.0 — pan, pinch, and swipe gestures, native-thread
• react-native-svg 15.12.0 — for anything vector

The choice of Reanimated 4 matters. Reanimated 3 was already the state of the art. Version 4 doubles down on the New Architecture — smaller runtime, better crash reporting, cleaner worklet ergonomics. Any animation the AI generates runs at 60fps on the UI thread by default; you do not have to remember to add useSharedValue to avoid dropped frames.

Legend Motion sits on top for the common cases. Instead of writing a useSharedValue + useAnimatedStyle block for a simple entry animation, generated code writes:

<Motion.View animate={{ opacity: 1, y: 0 }} initial={{ opacity: 0, y: 20 }}>

Same 60fps, one-third the lines. This is a good example of the philosophy: we optimize for what the AI generates most often, not for what a hand-coder might build once.

Auth, theming, and fonts: the polish layer

Every generated app boots into a themed, authenticated, safe-area-aware shell. The polish layer is invisible when it works and glaringly wrong when it does not.

Authentication. A useAuth() hook reads the current user from Vibecode DB's auth adapter. In the preview build, the mock adapter auto-signs-in a fake user so the AI can generate authenticated screens without wiring a login flow. When you plug in a real Supabase backend, the same hook starts returning the real signed-in user without a single code change.

Theming. A ThemeProvider sets CSS variables at the root of the app. Every semantic color token — background, foreground, primary — resolves through those variables. A ThemeToggle component is pre-installed to flip between light and dark mode. Because the theme lives in CSS variables (via NativeWind), the switch is instant and does not require re-rendering every styled component.

Fonts. Every template ships with Inter (400, 500, 600, 700) as the body and heading font, and JetBrains Mono (400, 500) as the monospace font. They load through expo-font 14.0.9 at splash-screen time so the app never flashes fallback fonts. Tailwind exposes them as font-heading, font-heading-bold, font-body, font-body-medium, font-mono, and font-mono-medium.

Chrome. The usual Expo modules are pre-configured:

• expo-splash-screen 31.0.10 — animated splash
• expo-status-bar 3.0.8 — theme-aware status bar
• expo-system-ui 6.0.7 — background color matching
• expo-linking 8.0.8 — deep linking
• expo-linear-gradient 15.0.7 — gradients
• expo-image 3.0.9 — the fast image component
• expo-image-picker ~17.0.10 — camera and library access

Nothing exotic. Nothing missing.

What we deliberately don't ship

The interesting part of a starter template is not what is included — it is what is not. Here are the omissions and the reasoning:

Redux, Zustand, Jotai, MobX. No global state library. TanStack Query handles server state, React Context handles UI state, and that covers 95% of real screens. Adding a global store to a fresh app is premature optimization.

Formik, React Hook Form, Yup. No form library. React Native forms are typically small — three inputs, a button — and the ceremony of a form library outweighs the benefit at that scale. Zod validation is available for API responses.

Stripe React Native, RevenueCat, in-app purchase SDKs. No payments. These are heavy native modules with entitlement configuration that only makes sense once the app has a real monetization plan. Add them via QuickEdit when they matter.

Firebase, Sentry, Amplitude, Mixpanel. No analytics or crash reporting. Same reasoning — real projects should pick one deliberately, not inherit one because a template shipped it.

A UI component library. Covered above.

The template is intentionally smaller than most people expect. That is the point. Every dependency is a maintenance surface. The fewer of them a generated app carries, the more it stays true to the "code you would have written yourself" promise.

Ship-ready from the first prompt

Add it all up: a first prompt to RapidNative produces a project that has file-based navigation, a themed component system, a data layer with local persistence, gesture-driven animations, a safe-area shell, custom fonts, and a working auth flow. All of it is idiomatic, exportable code you can hand to a React Native developer without an apology.

That is what "generative" is supposed to mean — you get a real app, not a preview.

If you want to see the stack in action, start a project on RapidNative and check the package.json after your first prompt. Every dependency listed here will be there. Every version will match. You can also compare directly against a hand-picked Expo starter template — the surface area is the same, but you get to skip the setup afternoon.

Ready to see it yourself? Describe your app idea in plain English and get a running React Native project in under a minute. No credit card required. Or if you prefer to start from a picture, try our screenshot-to-app or whiteboard sketch-to-app flows — same stack, different starting point.