How AI-Generated Apps Stay Fast: Our Performance Approach

AI-generated code has a reputation problem. Ask most engineers what they think of it, and you'll hear the same three words: slow, bloated, generic. Big walls of .map() over untyped arrays. ScrollView where a FlatList should be. Ten HTTP round-trips for a screen that should have made zero. And that's before the bundler even opens the file.

We spent two years building RapidNative — a natural-language-to-React-Native app builder — around a stubborn belief: AI-generated app performance is not an accident. It's an architectural discipline that starts long before a single token is generated. This post is a tour of that discipline, top to bottom, with the actual internals that make it work.

"Fast" for an AI app builder is a stacked property, not a single number — Photo by Carlos Muza on Unsplash

What "Fast" Even Means for an AI App Builder

Traditional performance posts pick one axis — cold-start time, JS thread work, list virtualization — and go deep. That framing doesn't fit an AI app builder, because the user experience is a chain of three very different timings:

1. Generation speed — how long from prompt submit to first token, and from first token to a working screen.
2. Preview speed — how long from a code change (AI or human) to the updated app rendering on-screen.
3. Runtime speed — how the generated app itself behaves on a real device after it ships.

Any one of these being slow poisons the whole session. A perfectly optimized generation pipeline is worthless if the preview takes ten seconds to refresh, and a snappy editor is worthless if the code it emits jank-scrolls at 12 fps on a mid-range Android. So the RapidNative approach to AI-generated app performance is a stack of decisions, one per layer, that reinforce each other.

Here's how each layer is built.

Layer 1: Streaming Generation That Reuses Almost Everything

The single biggest lever for generation speed is prompt reuse. Every AI code-generation request has a huge, mostly-static prompt: system instructions, framework rules, project skills, tool schemas. Rewriting those tokens on every request is the difference between a 12-second first response and a 2-second one.

The generate-v3 route (src/app/api/user/ai/generate-v3/route.ts) pre-computes the full system prompt at module load time — FULL_SYSTEM_PROMPT = SYSTEM_PROMPT + pre-loaded-skills — so the byte sequence is identical across every request the server ever serves. That identity is what unlocks provider-side prefix caching: DeepSeek's context caching recognizes the shared prefix and charges the cached portion at roughly a tenth of the normal input rate, while also cutting first-token latency dramatically. On the Anthropic side, generate-v2 uses cacheControl: { type: 'ephemeral' } for a comparable effect within a 5-minute window (Anthropic prompt caching docs).

The generation loop itself is a single agentic pass with two hard limits: stopWhen: [stepCountIs(40), hasToolCall('ask_question')]. Forty steps is the ceiling — enough for a fullstack app scaffold with database migrations and asset generation, tight enough that a runaway loop can't burn a user's credits. ask_question short-circuits the loop the moment the AI needs human input (e.g., picking an app icon), so the pipeline never sits idle waiting for a permissive stop condition.

Streaming happens over Server-Sent Events, but not the usual fragile flavor. Our resilientSSE (src/lib/resilient-sse-instance.ts) is backed by Vercel KV (or Upstash Redis, or in-memory in dev) with a 600-second buffer. If a client's network drops mid-generation, the server-side stream keeps running and chunks are buffered to KV. When the client reconnects — same tab, new tab, a different device — it resumes from the last event ID and replays whatever it missed. In serverless terms, this matters because we can add instances without draining active streams: any node can pick up any client's resumption, since the state lives outside the box.

Context management is the other half. The coding agent's context is capped at CODING_AGENT_CONTEXT_LIMIT = 512000 tokens, and once usage crosses 80% (~410K tokens), compactConversation() folds the older half of the transcript into a single summary message. The recent turns, tool calls, and files stay verbatim so the model still has the sharp edges of the current task. Compaction is what lets a single long editing session stay coherent for hours without slowing down or drifting.

Layer 2: A React Native Bundler That Runs in Your Browser Tab

The preview is where most AI app builders show their seams. If you send generated code to a remote bundler and stream a bundle back, you're paying two network round-trips per keystroke. RapidNative doesn't do that. The bundler runs in the browser, on a Web Worker — the whole thing.

The core is a package called browser-metro (src/modules/file/bundler.worker.ts), an incremental bundler with a virtual filesystem. When a file changes — whether an AI tool call rewrites it or a user edits a line by hand — only the changed modules re-parse and re-link. Parsing uses @sveltejs/acorn-typescript, so TypeScript and JSX go through a single pass instead of the traditional "strip types, then parse JS" two-step. React Native's own primitives (View, Text, FlatList) are aliased to react-native-web at resolve time, which is what lets the exact same source code render both in the browser preview and in a real Expo build on a phone.

The bundler lives in a Web Worker so parsing never blocks the editor UI — Photo by Markus Spiske on Unsplash

Two design choices in the bundler pay off constantly:

• Per-file error isolation. If a component throws a syntax or type error at parse time, we don't blow up the bundle. The broken file is replaced with a stub that renders a visible error card, and the rest of the app keeps working. So a user editing screen A can still navigate to screen B, C, and D while A is temporarily broken — the AI can then repair A in the background without the user losing state.
• Shimmed native packages. expo-font, expo-constants, @react-native-reanimated, and nativewind all get pre-compiled shims injected into the graph, so we never have to fetch them at runtime and we never trigger XHR calls during bundling. This is a big part of why the first paint after a code change is near-instant.

For deeper detail on how bundle deltas stream through the pipeline, we wrote a whole separate post on the two-step AI pipeline and browser bundler — this post focuses on how the layers combine into overall AI-generated app performance.

Layer 3: The System Prompt Itself Enforces Performance

This is the part most AI code-gen platforms don't do, and it might be the single highest-leverage decision we made. The AI's system prompt is not a vague "please write good code" instruction. It contains an explicit decision table for when to use which React Native primitive, and it's non-negotiable.

For lists:

• FlatList (virtualized) — feeds, paginated lists, gallery grids, or any list expected to exceed roughly 15 items. Must include a keyExtractor for stable reconciliation. Handlers wrapped in useCallback.
• ScrollView + .map() — only for static or short lists under ~15 items.
• Never a FlatList inside a ScrollView — nesting kills virtualization, which is the point of using FlatList in the first place. See the React Native FlatList docs for the underlying constraint.

For images:

• Downloaded assets are saved locally and referenced via require(), not fetched from remote HTTPS URLs at runtime. This eliminates per-image network waits on first paint.
• Filenames from tool outputs are preserved exactly — no renaming — so cache keys stay stable across regenerations.

For navigation:

• Detail screens use dynamic Expo Router paths like [id].tsx with useLocalSearchParams(), not static screens with ad-hoc parameter passing. This keeps route trees flat and lets Expo Router's own memoization kick in.

For styling:

• NativeWind (Tailwind for React Native) compiles all styles in a single pass at build time, sidestepping the runtime StyleSheet resolution cost of ad-hoc style={{ ... }} objects scattered across components.

None of these are unusual patterns for a senior React Native engineer — they're just discipline. What's unusual is making them the AI's default rather than something a human has to review for. Over hundreds of thousands of generations, the compounding effect is what keeps AI-generated app performance predictable instead of being a lottery.

Layer 4: The Editor Stays Responsive While the AI Works

An AI editing session generates a lot of state churn: new files, edited files, streaming tool calls, updating cost counters, changing agent selections, live bundle diffs. Naive React would re-render half the UI on every token.

We built the editor around Redux Toolkit with heavily memoized reselect selectors. Domain-specific selectors like selectChatData, selectBrowserResponsiveData, and selectWorldDimensionData combine multiple slices into derived data, and thanks to reselect's referential equality, downstream components only re-render when the specific derived value they depend on actually changes — not every time the store updates.

The editor iframe talks to the parent window through a MessageManager that wraps postMessage in a promise-based RPC layer. One nice detail: it detects the "layer path prefix" (the section of the file tree the AI is currently editing) once and caches it as layerPathPrefix, avoiding a regex match on every message. When you're pushing thousands of messages during a long generation, that adds up.

Two supervisor components watch the editor at runtime:

• RecoveryOrchestrator — monitors for build errors and blank-screen conditions. If the preview goes blank because a broken file broke everything downstream, it triggers targeted recovery rather than making the user reload.
• AutoRetryManager — auto-restarts generation on specific transient failure codes. Because these retries are gated behind an isAutoFix detection (a prompt-shape check for phrases like "There's an error in … Please fix this error."), they're never billed to the user's credit balance. Free retries make it safe to be aggressive about them.

We've written more about how the editor's state layer is put together in Redux, Context, and Beyond: State in RapidNative's AI Editor.

Layer 5: Database Queries That Never Do the Same Work Twice

The Supabase side of the platform is boring in the best way. The performance work is almost entirely in indexes and covering-index shapes.

The files table — the largest table in the system by row count — has a covering index specifically for the "list all files in a project" query:

idx_files_project_id_fast(project_id) INCLUDE(id, file_path, file_type, updated_at)

INCLUDE puts the selected columns directly in the index leaf pages, so listing a project's files is a single index scan with no heap fetch. For direct file lookups, a composite idx_files_project_path(project_id, file_path) handles the read path with the same shape.

For team access checks — the hottest read path outside of file operations — we push the logic into a single Supabase RPC (check_project_access(projectId, email)) instead of doing the multi-table join in application code. And we use partial indexes aggressively for hot subsets:

CREATE INDEX idx_project_share_active
  ON project_share (project_id)
  WHERE team_access_level IN ('view', 'edit');

Filtering on active shares means the index is 40-60% smaller than the naive version, which keeps it in memory and keeps lookups in the sub-millisecond range even as the table grows.

When a route needs multiple pieces of context, we resolve them with Promise.all ([userLookup, agentResolution, projectLookup, accessCheck]) rather than serially. It's a small thing, but it shaves 100-200 ms off routes that need three or four database reads to get going.

Covering indexes and partial indexes are the boring, high-leverage half of AI-generated app performance — Photo by Umberto on Unsplash

Layer 6: Cost Is a Performance Property Too

Most performance posts stop at latency. But for an AI product, cost per iteration is a performance property, because it's what determines whether users are willing to iterate quickly. A tool that generates in 3 seconds but costs $2 per prompt will feel slower than one that generates in 8 seconds but costs 5 cents, because users hesitate before every request.

We've optimized aggressively for cheap regeneration:

• Prefix caching hit rate is ~90% after the first request in a session, because the system prompt is byte-identical across all requests. Cached input tokens bill at roughly 10% of fresh input rate.
• "Fix with AI" is completely free. When we detect the specific prompt shape produced by our error UI ("There's an error in … Please fix this error."), we skip credit deduction entirely. Debugging your own generated app shouldn't cost you.
• Auto-recovery is free but tracked. isAutoFix retries are logged so we can measure them in dashboards, but the user's balance is untouched.
• Context compaction happens transparently, so long editing sessions don't quietly balloon into expensive regenerations.

The full breakdown of how this maps to the credit system lives in RapidNative's Credit System: Pay for What You Build, but the design principle is worth stating outright: if iteration is cheap, iteration is fast, because the human never pauses to think about whether the next prompt is worth submitting.

How These Layers Combine

The layers reinforce each other in ways that are easy to miss when you look at them separately:

• Prefix caching (Layer 1) makes generations cheap, which makes the "Fix with AI" free-retry policy (Layer 6) economically sane.
• The browser bundler (Layer 2) means the moment a tool call writes a file, the preview updates without a network round-trip — which means Layer 3's performance rules pay off immediately in the visible UI.
• The recovery orchestrator (Layer 4) knows about the bundler's per-file error isolation (Layer 2), so a broken file triggers a targeted repair prompt instead of a full session restart.
• Fast database reads (Layer 5) mean the initial project load into the bundler VFS completes in one round-trip, so the preview is warm before the AI even starts responding.

None of this is magic. It's just a lot of small, deliberate decisions that respect the fact that AI-generated app performance is a whole-system property, not a single trick.

What This Means for What You Ship

If you spin up a project on RapidNative today — whether you start from a natural-language prompt, a whiteboard sketch, or a screenshot of an existing app — what you get out of the pipeline is Expo-compatible React Native code with:

• FlatList where it matters, ScrollView where it doesn't
• Local image assets, not runtime network fetches
• Dynamic routes and useLocalSearchParams, not switch statements
• NativeWind styles compiled at build time, not resolved at render
• Memoized event handlers and stable key extractors on every list

That's the same code you export when you publish to the App Store or Google Play. There's no watered-down "AI version" of the code that gets swapped for something better at export time — the preview and the shipped binary run the same source.

The Takeaway

Every conversation about AI-generated app performance eventually reduces to the same question: does the tool trust the model, or does the tool constrain it? A pure "let the model figure it out" approach produces the slow, bloated, generic code the reputation is built on. A heavily constrained approach with real architectural discipline — prefix-cached prompts, in-browser incremental bundling, hard rules for React Native primitives, memoized editor state, indexed queries, cheap iteration — produces apps that don't need a rewrite to feel native.

That discipline is the whole product. If you want to see what it feels like to iterate on a real app in a loop where each turn takes seconds instead of minutes and costs cents instead of dollars, start a project on RapidNative — twenty free credits, no credit card, no waiting for a bundler somewhere else.