Inside RapidNative's Version History: How We Track Every AI Generation

Our messageTransformer.ts parses this into typed blocks:

• codeproject — a full file generation. May contain multiple files bundled into a single logical "commit."
• quickedit — a surgical before/after snippet, used when the model wants to change a small region without rewriting the whole file.
• action — a structured operation: delete_file, rename_file, etc.
• projectmetadata — app-level state changes (name, icon).
• text — pure conversational content, no code impact.

Every message stored in Supabase has a type column (user, assistant, system, tool) and a content column that holds this structured payload. Because the payload is structured, we can replay it — parse the blocks, apply them in order, and rebuild the file tree exactly as it existed at that point in the conversation.

That's the key insight. Restore isn't a snapshot lookup. It's a replay.

Treating AI generations as an event log — not a snapshot — is what makes restore fast and cheap — Photo by Carlos Muza on Unsplash

How restore actually works

When you click the "restore this version" button next to any prior AI message in the RapidNative editor, here's what happens under the hood.

Step 1 — Load the message history. The editor fetches every message for the project up to and including the target message ID. This is a single indexed query on (project_id, created_at).

Step 2 — Establish the baseline. For v1 and v2 projects, the baseline is empty — the entire file tree is generated by AI, so replay starts from nothing. For v3+ projects (our newer template-based generations), we first load the template baseline files. This matters because our v3 architecture only stores diffs from a known-good Expo starter, not full files. Replaying from empty would leave you with a half-app.

Step 3 — Replay each message in order. For each message, we parse the content blocks and apply them to an in-memory representation of the file tree:

• codeproject block → overwrite each file with the block's content.
• quickedit block → apply the before/after diff. We normalize whitespace and try an exact match first, falling back to a fuzzy match if the file has drifted.
• action block → run the operation (delete_file removes the file from the tree, rename_file moves it).
• delete {filename} user message → treated as a file removal (legacy format).
• rename {old} {new} user message → treated as a rename (legacy format).
• restore {messageId} marker → recursive replay. If we encounter a restore marker in history, we jump to that earlier point and start replaying from there. This is how nested restores compose cleanly.

Step 4 — Persist the rebuilt tree. Once replay finishes, we write the resulting file tree back to the files table with an upsert. The messages table is untouched. The conversation stays intact — the restore itself becomes a new message in the log.

The whole thing takes well under a second for a typical project because the messages table is small (dozens of rows, not hundreds of megabytes) and the replay is pure string manipulation. No file storage system to hit. No blob to download. Just events to reapply.

The package.json trick that saves your dependencies

Here's a subtle problem that took us a while to get right.

Say you built a fitness app. In generation #3, the AI added react-native-svg because you asked for icons. In generation #7, the AI added expo-blur because you asked for a glassy background. In generation #12, the AI added @react-navigation/bottom-tabs.

Now you want to restore to generation #5.

If we replay package.json naively, we'd end up with the version that only has react-native-svg — no blur, no navigation. The moment you build, half your imports fail. Every dependency added after generation #5 is gone. The AI has no memory that it once added them.

We solve this with an add-only merge for package.json during replay. When the replay engine encounters a package.json in a CodeProject block, it doesn't overwrite — it merges. Dependencies accumulate across the full history. Nothing is ever removed just because we're restoring backward.

The pseudo-logic:

mergePackageJsonAddOnly(currentPkg, incomingPkg) {
  return {
    ...incomingPkg,
    dependencies: { ...currentPkg.dependencies, ...incomingPkg.dependencies },
    devDependencies: { ...currentPkg.devDependencies, ...incomingPkg.devDependencies },
  };
}

The scripts, name, and version fields follow whatever the incoming (target) version says. But the dependency lists always accumulate. It's a small, deliberate violation of pure replay semantics, and it prevents a class of confusing failures where the code compiles in isolation but the bundler chokes because a peer dependency vanished.

v3+ templates and the baseline replay

Our earliest projects (v1, v2) followed a "generate everything from scratch" model — every file the app needed, including boilerplate, came from the LLM. That worked, but it burned tokens and produced inconsistencies (the same Expo entry point looked slightly different every time).

For v3+ projects, we start every project from a known-good Expo template baseline and treat the AI's output as diffs on top of the baseline. The template gives us:

• Predictable app.json, tsconfig.json, babel.config.js, and root layout.
• A tested navigation shell.
• Consistent NativeWind and asset conventions.

This changes replay slightly. For v3+ restores, we don't start from empty — we start from the template. Then we replay messages on top. This is why our revertFiles thunk (part of the editor's Redux store) checks the project's version field first, loads the template if needed, and only then walks the message history.

The projects table gained a version column ("v1", "v2", "v3", …) and a can_be_rolledback boolean specifically to route restore requests through the right replay logic. Older projects can still be restored — we just apply the older rules.

Streaming, checkpoints, and bundle snapshots

Version history isn't just about what happens after a generation. It also has to survive what happens during one.

Our AI pipeline streams tokens over Server-Sent Events (SSE). The user sees code appear character by character in the editor. This is good UX but it's a fragile moment — if the tab crashes mid-stream, or the network hiccups, or the user's laptop closes the lid, the message is incomplete.

Two mechanisms keep version history intact through this:

1. Persistent fetch with resumable streams. We wrap the SSE consumer in a persistentFetch helper that supports resumption. If the connection drops, we can pick up where we left off rather than starting the whole generation over. The message doesn't get committed to the messages table until the stream completes cleanly.

2. Session storage for prompt recovery. Before we even fire the request, we drop the original prompt (and any attached image URL) into sessionStorage under a key like rn_restart:${projectId}. If the tab reloads for any reason, our recovery orchestrator sees the stored prompt and offers to resume. This is one of five recovery layers (L1 silent AI retry, L2 iframe reload, L3 full page reload, L4 surface to user, L5 auto-restart) that make the streaming experience feel robust even when the network isn't.

Alongside the messages/files split, we also take bundle checkpoints — a throttled, 30-second-interval snapshot of the compiled bundle.js and manifest.json, uploaded directly to Supabase Storage via a signed URL. This lets us render the app on the dashboard without spinning up an active bundler session. It's not part of version history proper (you don't restore to a bundle) but it's part of the same design philosophy: durable snapshots at the moments that matter, not on every keystroke.

Streaming AI code generation is fragile — durable snapshots are what let it feel bulletproof — Photo by Kelly Sikkema on Unsplash

The little details that make it feel good

A few smaller decisions add up to a version history experience that gets out of your way:

• Message ordering. When we save a generation, we timestamp the user prompt and the AI response two seconds apart so they always render in the right order — even if both were persisted in a single transaction. Our interleaveMessages helper groups messages by created_at and orders within a group as user → assistant → system → tool.

• Optimistic UI. The moment you press send, your message appears in the Redux store before it hits the database. The AI response streams in over SSE. Everything you see is either committed or clearly marked as pending — there's no ghost message state.

• Message-level feedback. Every AI response has a feedback column (good/bad/null). When you thumbs-up or thumbs-down a generation, we're not just collecting training data — we're marking version history for future you. You can find the last "good" checkpoint without scrolling.

• Restore-as-message. When you restore to a prior point, the restore action itself becomes a message in the log ("restore {messageId}"). Version history has version history. If you restore, then restore again, we can walk the trail.

• Credit-aware retry. If our automatic recovery layer re-runs a generation because of a bundle error, we skip credit deduction for that retry via our team_ai_request_logs table. You never pay twice for the same intent.

What we learned

Three things surprised us building this.

First: separating events from state is more important than any specific storage decision. We tried early prototypes where every generation wrote a full snapshot of the file tree to blob storage. It worked, but restore felt heavy and storage grew fast. The moment we moved to messages-as-events + files-as-projection, the whole system got smaller and faster. Restore went from "download this snapshot" to "reapply these events" — and events are tiny.

Second: replay engines need escape hatches. Pure replay is beautiful in theory. In practice, package.json breaks the model. So do renamed files that reference each other. So do files that got hand-edited by the user between generations. Every one of these needed a targeted exception. The rule became: replay purely by default, but be willing to violate purity when the violation is safer for the user.

Third: the source-of-truth question is the design. In an AI code generation product, the temptation is to treat the code as the source of truth. But code is a projection. The real source of truth is the conversation — the sequence of prompts and responses that produced the code. Once you accept that, restore, share, comment, and even collaborative editing all get cleaner. We could rebuild an entire project from just the messages table if we ever had to. That's the invariant we design around.

Try it — every generation is safe

If you've been burned by an AI builder that lost your work, we built RapidNative specifically for you. Every generation is tracked. Every prompt is recoverable. Every version is one click away.

• Start building a mobile app from a prompt — free tier available, no credit card.
• Turn a whiteboard sketch into a working app.
• Convert a PRD into a working prototype.
• If you want to compare tools first, read our take on why we built a browser-based AI app builder from scratch, how we stream code in real time, and how a single prompt becomes production React Native code.

The best AI mobile app builder is the one you can trust to remember every step of the conversation. That's what we optimized for.

If you're a developer curious about the underlying tech: React Native + Expo, Supabase Postgres for the message store, Server-Sent Events for streaming, Redux for editor state, and Vercel + Next.js App Router for the API layer. Nothing exotic — just carefully-chosen primitives arranged around a single invariant: your conversation is the source of truth.