Inside RapidNative: How AI Turns a Chat Prompt into Production React Native Code

You type: "Build a food delivery app with a restaurant list, cart, and checkout screen."

About twelve seconds later, a working React Native application appears in the preview — complete with NativeWind-styled components, Expo Router navigation, and a theme that matches your design system.

No boilerplate written. No npx create-expo-app executed. No component scaffolding by hand.

If you've used RapidNative, you've experienced this moment. But what actually happens in the milliseconds between hitting Enter and seeing production-quality code? This post is the honest, technical answer — the real architecture, the real design decisions, the real data flow.

AI React Native code generation at this level isn't magic. It's a carefully orchestrated pipeline involving multi-step LLM reasoning, real-time streaming, a browser-based bundler, a virtual file system, and a multi-provider LLM routing layer. Let's walk through every hop.

The Architecture at 30,000 Feet

Before diving into each component, here's the full technical stack RapidNative runs on:

The complete data flow for a single generation looks like this:

User types prompt in editor
    ↓
useSendMessage hook (validates credits, compresses + uploads images)
    ↓
sendMessage Redux thunk (collects context, calls API)
    ↓
POST /api/user/ai/generate-v2
    ↓
Step 1: Context Gathering (lightweight model + AI file tools, ≤8k tokens)
    ↓
Step 2: Code Generation (full model, SSE streaming, ≤15k tokens)
    ↓
Frontend SSE parser → Redux files state updated in real time
    ↓
Web Worker bundler (Babel AST transform) → iframe preview refreshes
    ↓
Debounced Supabase persistence (100ms debounce)

Every prompt travels this entire chain. Understanding each hop explains the quality of the output — and why it feels as fast as it does.

Step 1 — The AI Reads Your Project Before Writing a Line

This is the most underappreciated part of the pipeline. Before the main model writes a single character of code, a context-gathering phase runs first.

RapidNative uses a two-step generation architecture: a lightweight, fast model runs Step 1 with access to file-reading tools, and the full-capacity model runs Step 2 with no tools — just generation. The Step 1 model's entire job is to understand the existing project so the Step 2 model doesn't generate code that conflicts with what's already there.

The Step 1 model gets access to five AI tools:

• get_files_content — Read any project file, with optional start/end line ranges for efficiency
• list_dir — List files by directory path prefix
• glob — Pattern-matching file search (e.g., **/*.tsx, components/**)
• batch_grep — Regex search across all project files with surrounding context lines
• get_images_by_keywords — Find or generate images by semantic description

These tools query the Supabase virtual file system (VFS) directly — real file content, not summaries. When the AI calls get_files_content(["app/index.tsx", "components/Header.tsx"]), it receives the actual TypeScript source back with full fidelity.

Step 1 also automatically injects two context files into every generation:

• layout.md — A markdown file describing the global layout structure and Expo Router navigation patterns in the project
• theme.md — A markdown file defining the color palette, typography, spacing, and design tokens in use

This is what makes new screens visually consistent with existing ones. The AI knows your app uses indigo as the primary color, uses a specific card component pattern, and has a bottom tab navigator with three tabs — because it read theme.md and layout.md before generating anything. Step 1 runs up to 4 tool-call steps and uses up to 8,000 tokens. It's optimized for speed and low cost.

Step 2 — Code Generation and Real-Time Streaming

Once context is gathered, Step 2 begins. This is where the actual AI React Native code generation happens.

The full-power model receives:

• The complete project conversation history (all prior messages and previously generated code)
• The context gathered in Step 1 (relevant file contents, theme, layout)
• A template-specific system prompt defining React Native file conventions
• File path configuration to ensure correct directory structure
• The user's current prompt

Step 2 has no tools — no file reads, no searches. It generates. The output arrives as a streaming response over Server-Sent Events (SSE) with six event types:

event: start       → { projectId, timestamp, model }
event: text        → { content: "...streaming code chunk..." }
event: tool_call   → { toolName, toolCallId, args }      ← Step 1 only
event: tool_result → { toolName, success, output }       ← Step 1 only
event: usage       → { promptTokens, completionTokens }
event: done        → { finishReason: "stop" }

The frontend sendMessage Redux thunk parses these events in real time. As text chunks arrive, it looks for two types of structured code blocks within the stream:

CodeProject blocks — Full file content, used when creating new files or doing major rewrites:

<CodeProject>
  <File path="app/checkout.tsx">
    // complete file content
  </File>
</CodeProject>

QuickEdit blocks — Surgical text replacements for targeted changes, far more efficient than rewriting complete files:

<QuickEdit path="components/CheckoutButton.tsx">
  <OldText>backgroundColor: '#333'</OldText>
  <NewText>backgroundColor: colors.primary</NewText>
</QuickEdit>

QuickEdits are a key architectural optimization. When a user asks to "change the button color," RapidNative doesn't regenerate the whole file — it outputs a targeted replacement. This means faster streaming, lower token usage, and zero risk of the AI accidentally touching code it wasn't asked to change. When the old text is found in the file, the replacement is applied atomically.

The main generation model runs with up to 15,000 output tokens — enough to generate multiple complete screens and components in a single pass.

Generated code streams in real time — the preview updates as each file block lands

Real-Time Preview: From Streaming Code to a Running App

The live preview in RapidNative isn't a static mockup — it's an actual running React Native application, rebuilt in real time as the AI streams code.

Here's how the preview loop works:

1. Generated files enter Redux. As the SSE stream delivers file content, the saveFile action updates the in-memory VFS state inside Redux. File objects are keyed by path — app/checkout.tsx, components/CartItem.tsx, etc.

2. A Web Worker receives the update. The editor runs a dedicated bundler.worker.ts Web Worker that handles all code transformation. Running transforms in a worker keeps the main thread responsive — the UI never freezes during generation.

3. Babel transforms the code. The worker runs a Babel AST parser on the React Native/Expo TypeScript source, transpiling JSX and TypeScript into JavaScript the browser can execute.

4. The iframe preview refreshes. The bundled output is injected into a sandboxed preview iframe that renders the app using a React Native renderer. The preview updates within ~200ms of a streaming code chunk arriving.

5. Runtime errors are caught and surfaced. The bundler parses errors from both Babel compilation and runtime execution, categorizes them, and surfaces them in the editor UI. If the AI generates a syntax error, you see it immediately — with file name, line number, and context.

This entire loop — streaming chunk to visible preview — typically completes in under a second. The debounced Supabase save runs asynchronously behind the preview refresh, so persistence never blocks the user experience.

The Multi-LLM Routing System

One of the more interesting architectural decisions is that RapidNative isn't tied to any single LLM provider. Model selection is entirely database-driven.

There are three model purpose categories, each mapped to a different database-stored configuration:

At runtime, the system queries the config and instantiates the appropriate model object:

switch (config.provider) {
  case 'openrouter': return createOpenRouterModel(config.modelId);
  case 'bedrock':    return createBedrockModel(config.modelId);
  case 'vertex':     return createVertexModel(config.modelId);
  case 'azure':      return createAzureModel(config.modelId);
}

Supported providers include OpenRouter (with routing across 200+ models), AWS Bedrock, Google Vertex AI, and Azure (supporting both OpenAI and Anthropic models). Model swaps happen at the database row level — no code change, no deployment required.

For Anthropic models (via OpenRouter or Azure), the system also enables prompt caching — the large system prompts sent with every generation request get cached at the provider level, dramatically cutting latency and token cost for repeat generations. The system detects Anthropic models at runtime and attaches the appropriate cacheControl metadata.

This architecture also provides resilience. If one provider rate-limits or has degraded performance, routing can be switched at the database level and takes effect immediately for all subsequent requests.

Templates, Themes, and the Exported Code Structure

Not every app starts from a blank canvas. RapidNative's template system shapes what the AI generates at the file-system level.

Templates are pre-defined project configurations that include:

• A set of starter files (base app/index.tsx, navigation config, etc.)
• A rapidnative.json config file that defines directory path conventions
• Template-specific AI instructions — what component libraries to use, what file patterns to follow
• A project type declaration (expo, react-native, or web)

Available templates include NativeWind (the default — Expo Router + NativeWind CSS), NativeWind Themed (with a pre-built design token system), Fullstack (complete with backend integration scaffolding), and Admin Dashboard (data-heavy table and chart layouts).

When the AI generates code in Step 2, it parses the rapidnative.json config to read the correct file paths for this project. The system prompt enforces these conventions explicitly:

✅ CORRECT: app/index.tsx, app/[screenname].tsx
✅ CORRECT: components/Header.tsx
❌ WRONG:   screens/index.tsx  (if template uses 'app/')

This constraint prevents one of the most common failure modes in AI code generation — files getting placed in wrong directories, breaking imports and Expo Router's file-based navigation.

The output is real, portable React Native code — not a proprietary intermediate format. When you export from RapidNative, you get a standard Expo project. Run npx expo start, open it in VS Code, and hand it to a dev team who immediately recognize the structure. No vendor lock-in at the code level.

Multiple Input Modes, One Pipeline

While this post focuses on the chat-to-code path, the same generate-v2 endpoint handles all of RapidNative's input modes:

• Text prompt — Natural language description of screens and features
• Sketch/whiteboard — The sketch-to-app feature converts hand-drawn wireframes into React Native screens using the VISION model
• Screenshot/image — The image-to-app feature reverse-engineers UI from screenshots, also using the VISION model
• PRD document — The PRD-to-app feature parses structured product requirements into multiple coordinated screens

Each input mode differs only in what gets injected into the Step 1 context and the initial message. For image inputs, the imageUrl is passed directly to the VISION model. For PRDs, the document is injected as structured context before the context-gathering phase. The generation, streaming, bundling, and persistence layers are identical across all modes.

What "Production-Ready" Concretely Means

The phrase gets used loosely in AI tooling. Here's what it means in practice for RapidNative's output:

Navigation — Generated screens use Expo Router file-based routing. Navigation is handled via the file system structure, the same pattern a senior React Native developer would write.

Styling — NativeWind provides utility-first styling that compiles to StyleSheet.create() at build time — not inline styles, not a CSS-in-JS runtime overhead.

Component patterns — The AI is constrained to correct React Native primitives: FlatList for scrollable lists, TouchableOpacity for tappable elements, SafeAreaView for layout containers. No web-only HTML like <div> or <span> bleeds in.

Theme consistency — Because theme.md and layout.md are injected at every generation, new screens automatically match the visual system of existing ones. The 8th screen you generate looks like it belongs with the first seven.

Real device testing — Via Expo Go, generated apps can be tested on physical devices instantly by scanning a QR code — no build step, no TestFlight wait.

What "production-ready" doesn't mean: the AI decides your data architecture, authentication strategy, or API design. Those are engineering decisions that belong to humans. RapidNative handles the UI layer — screens, components, navigation, styling — at a level that would take a developer hours per screen. The business logic layer is where your team's judgment still applies.

Does RapidNative use ChatGPT?

No — RapidNative uses a multi-provider routing architecture supporting OpenRouter, AWS Bedrock, Google Vertex AI, and Azure. The specific models used for code generation, context gathering, and vision tasks are configurable at the database level, making the platform model-agnostic by design.

Can you edit the generated code manually?

Yes. The virtual file system is fully editable in the editor. You can modify any generated file directly, and the preview updates live. The exported project is standard Expo code — open it in any IDE and continue development normally.

The Bottom Line

The leap from "type a sentence" to "working mobile app" involves a surprisingly deep technical stack: two-stage LLM reasoning with tool-use, multi-provider routing, real-time SSE streaming, a browser-side Web Worker bundler, Redux-managed file state, and Supabase persistence. Each layer is designed to make the next one faster and more reliable.

Understanding the pipeline makes you a better user of it. Be specific in prompts so the context-gathering phase has something meaningful to work with. Use targeted edit requests when you want surgical changes — the QuickEdit path is faster and safer than full regeneration. For apps with many screens, start with a PRD input to give the AI architectural coherence from the beginning.

The fastest way to see the pipeline in action is to run it. Start building for free on RapidNative — no credit card required. Your first screen takes about 15 seconds.

Related reading: How AI is Changing React Native Development · Generative AI for App Development · React Native Performance with AI-Generated Code