How RapidNative Delivers Real-Time React Native Live Preview Across Every Device

The moment you finish describing a screen to RapidNative, the AI generates the code — and within seconds, a pixel-perfect preview of that screen appears in the editor. No terminal window. No npx expo start. No cable connected to your laptop. The preview just works.

That seamless experience is the product of a layered preview architecture that most users never think about. Under the hood, RapidNative runs three distinct preview systems in parallel: an in-browser renderer that delivers react native live preview with sub-second hot updates, a checkpoint system that generates shareable snapshots for stakeholder review, and a Docker-based Expo tunneling layer that pushes your app to physical devices via QR code.

Each tier serves a different audience and a different stage of the build process. Understanding how they fit together explains why RapidNative feels so much faster than a traditional local development setup — and why you can go from prompt to testable prototype without touching a single config file.

A modern development workflow where live preview is a first-class citizen, not an afterthought.

The Three Tiers of Preview: A Quick Map

Before diving into mechanics, here's how the three tiers stack up:

The genius of this design is that each tier operates independently. The in-browser preview doesn't wait for the checkpoint. The checkpoint doesn't require a connected device. You get the right feedback loop at the right moment without any manual switching.

Tier 1 — In-Browser HMR: React Native Live Preview Without a Terminal

The in-browser preview is the one you interact with constantly during a build session. Every time the AI modifies a component or you edit a line of code directly, the preview panel updates — usually before you've finished reading the generated code.

How the Bundler Works

RapidNative runs a custom bundler called almostmetro inside a browser Web Worker. By offloading compilation to a separate thread, the main UI thread stays responsive while the bundler rebuilds in the background.

The bundler receives file changes via a typed message protocol (watch-start, watch-update, watch-rebuild, hmr-update). When you or the AI modifies a file, the change flows like this:

Editor change / AI output
   ↓ Redux dispatch
   ↓ VirtualFileSystem.updateFile('/app/screen.tsx', newCode)
   ↓ VFS watcher fires 'update' event
   ↓ BundlerWorkerClient.sendUpdate([{ path, type: 'update', content }])
   ↓ almostmetro Worker → IncrementalBundler.rebuild()
       ├─ [fast path] HMR only → onHmrUpdate()
       └─ [full path]  watch-rebuild → onBundle()
   ↓ Preview iframe receives update
   ↓ React Fast Refresh patches components in-place

The key distinction is the fast path vs. the full path. For the vast majority of edits — changing a color, updating text, adjusting layout — the bundler produces an HMR update containing only the modules that changed. This is posted directly to the iframe via postMessage(), and React Fast Refresh applies the patch without reloading the page or losing component state.

Full rebuilds happen when the module graph changes significantly — like when the AI generates a brand-new screen with new imports. These take slightly longer but are still measured in milliseconds on modern hardware.

The Iframe + Blob URL Pattern

Each screen preview is rendered inside a sandboxed iframe. When the bundler produces a full bundle, RapidNative doesn't serve it from a server endpoint — it creates a JavaScript Blob URL on the client and sets that as the iframe's src. The iframe loads instantly from memory, no network round-trip involved.

The HTML injected into the iframe is carefully constructed. It includes:

• Console interception — forwards console.log, console.warn, and console.error to the parent window so they appear in the editor's log panel
• Source map resolver — decodes VLQ-encoded source maps so that runtime errors point to your original .tsx file and line number, not minified bundle output
• HMR listener — listens for hmr-update messages from the parent and applies module patches inline
• Runtime error handler — catches uncaught exceptions and posts structured error data back to the editor, which highlights the offending file

This architecture means each screen gets its own isolated JavaScript context. An error in one screen's component tree doesn't crash the previews for other screens.

Per-File Error Isolation

This is one of the most developer-friendly aspects of the preview system: broken files don't break the whole project.

When almostmetro encounters a syntax error or a module that fails to compile, it replaces that file with a BrokenComponentStub — a placeholder component that renders a visible error card. The rest of the bundle continues to function. You can still navigate to other screens, interact with working components, and see the rest of your app running normally while you fix the broken file.

File-level errors are tracked in a ProjectBundlerState.fileErrors Map, so the editor can highlight exactly which file is broken without guessing.

Multiple screens preview independently — an error in one screen doesn't stop the others.

Tier 2 — Real Device Preview via Expo Tunneling

The browser iframe preview is great for fast iteration, but there are things it can't tell you: how the app feels in your hand, whether touch targets are the right size for your thumbs, how animations perform on a three-year-old Android device.

RapidNative addresses this with a second preview tier: on-demand Docker containers that run a real Expo/Metro development server and expose it to the internet via Expo tunnel.

Container Lifecycle

When you want to test on a real device, RapidNative provisions an isolated Docker container for your project. The container lifecycle is managed by an internal Workspace Server orchestrator and exposed via the /api/preview/[pid] route:

1. Container creation — A new container is started for the project, running Metro bundler and Expo dev tools.
2. Health validation — Before handing back a URL, the system checks that the container is actually responsive. If validation fails, the container is cleaned up and a fresh one is provisioned.
3. URL generation — The container returns three endpoints:
   • webUrl — the Metro bundler endpoint (e.g., http://hostname:8081)
   • expoUrl — an Expo tunnel URL accessible from any network
   • serverIp — direct container IP for advanced tooling

The expoUrl is what makes real device testing possible without any local setup. Scan the QR code in Expo Go, and the app loads directly from the tunnel — no Wi-Fi pairing, no USB debugging, no manual IP configuration required.

Why This Matters for Non-Technical Users

For the target RapidNative audience — founders, product managers, and designers who may not have a development environment configured — this is transformative. The entire promise of prompt-to-app is that you shouldn't need to set up a toolchain to see your app running on a real phone.

The Expo tunnel container handles everything that would normally require npm install, npx expo start, expo-cli, and a correctly configured local network. You get the full native experience — actual gesture handling, real scroll physics, native fonts — without leaving the browser UI.

Testing on a real device reveals what no browser preview can — touch feel, native rendering, real performance.

Tier 3 — Shareable Checkpoints: Preview That Travels

The first two tiers are synchronous — they update while you work. The third tier is asynchronous and persistent: a bundle checkpoint that saves a snapshot of your app every 30 seconds and makes it accessible via a stable public URL.

How Checkpoints Work

Every 30 seconds (when the bundler is idle, not mid-generation), RapidNative runs a three-step save process:

1. Request an upload URL — the client calls /api/user/projects/[projectId]/demo/upload-url to get a signed Supabase Storage URL.
2. Upload the bundle — the compiled bundle.js (which can be several megabytes) is uploaded directly to Supabase Storage, bypassing Vercel's 4.5MB body limit entirely.
3. Record metadata — a POST to /api/user/projects/[projectId]/demo upserts the project_bundle_preview table with the bundle URL, the Tailwind config, and PWA manifest data. This also triggers a Playwright-based screenshot job that generates the preview card image shown on the dashboard.

The Public Demo Endpoint

The stored checkpoint powers the /api/user/projects/[projectId]/demo GET endpoint — a public-facing preview page that returns a standalone HTML file with the Tailwind CDN, the project's theme config injected inline, and a redirect to the stored bundle.js in Supabase Storage.

This endpoint is what powers:

• Dashboard preview cards — the thumbnail you see for each project without opening it
• Shareable preview links — a URL you can send to a client, investor, or team member to see the current state of your app, no Expo account needed
• Playwright screenshots — used for thumbnail generation and social sharing

The checkpoint preview is intentionally slightly stale — it's a snapshot, not live. But for stakeholder review, this is actually a feature: the link always shows a stable, working version of the app, not a half-edited screen that happens to have a syntax error.

What Makes This Architecture Different

No Local Toolchain Required

Traditional React Native development requires Node.js, npm or Yarn, the React Native CLI or Expo CLI, Watchman, Android Studio or Xcode (or both), and a correctly configured emulator or physical device. A new developer can spend an entire day just getting their environment set up before writing a single line of code.

RapidNative moves all of this infrastructure into the cloud. The Web Worker bundler runs in your browser. The real device preview runs in a Docker container on RapidNative's servers. The checkpoint lives in Supabase Storage. Nothing touches your machine.

Simultaneous Multi-Screen Preview

Because each preview is an independent iframe with its own JavaScript context, RapidNative can display multiple screens simultaneously. When the AI generates a five-screen onboarding flow, all five screens render and update independently. You can scroll through them, see how they connect, and spot inconsistencies across the flow — all in the same editor view.

This is a meaningful difference from standard Expo development, where you typically see one screen at a time in a simulator.

Error Isolation Across the Project

As covered earlier, the per-file error stubbing means the editor stays usable even when a file is broken. In a traditional dev setup, a syntax error typically crashes the entire Metro bundler and requires a manual restart. With RapidNative's in-browser bundler, the broken file gets a placeholder stub, the rest of the app continues running, and the error is surfaced directly in the editor without breaking your workflow.

Frequently Asked Questions About React Native Live Preview

Does RapidNative's in-browser preview use the same bundler as Metro?

No. RapidNative uses a custom in-browser bundler called almostmetro, built to run inside a browser Web Worker. It shares philosophical similarities with Metro (incremental bundling, HMR support) but is entirely self-contained and doesn't depend on Node.js. This is what allows the browser preview to work without any local installation. React Native's official Metro bundler is used in the real device preview tier via Docker containers.

How is the Expo tunnel different from using Expo Go locally?

When you use Expo Go locally, your device and your laptop need to be on the same Wi-Fi network. The Expo tunnel tier in RapidNative uses Expo's tunnel service to expose your container's Metro bundler over the public internet, so you can scan the QR code and preview on any device — even over cellular — without any network configuration.

What happens to the preview when AI is generating code?

During AI streaming, the bundler temporarily suspends checkpoint saves to avoid capturing a half-generated state. The in-browser HMR preview, however, updates in real time as code streams in — you can literally watch the screen take shape as the AI writes each component. Once generation completes and the bundler goes idle, the next checkpoint save captures the finished state.

Build Your Next App and See It Live Instantly

The three-tier preview system is one of RapidNative's most technically ambitious features — and also one of its most invisible. It's designed to feel like magic: you describe a screen, and it appears. You make a change, and it updates instantly. You hand your phone to someone, and they're running your app.

If you haven't tried it yet, the fastest way to understand what real-time react native live preview feels like in practice is to start building — describe any screen you have in mind and watch the preview appear. No setup, no terminal, no waiting.

For more on how the AI pipeline behind the preview works, read Inside RapidNative: How AI Turns a Chat Prompt Into Production React Native Code. If you're interested in the visual editing side of things — clicking any element to change it — check out How Point-and-Edit Works Under the Hood.

And when you're ready to take your preview off the screen and onto the App Store, explore our pricing plans to see which tier fits your project.

Sources and further reading:

• React Native Fast Refresh documentation
• Expo Go and tunnel preview
• Metro bundler documentation