Why vibecoding doesn't work for mobile apps (and what to do with your v0 prototype)

Straight answer first: vibecoding doesn't produce a production mobile app because the tools don't generate what the stores require. Vercel's v0 generates a React/Next.js website — not React Native (Vercel Community, 2026). Bolt generates React Native via Expo, but it runs in a browser sandbox with no Xcode, no Android Studio, and no Expo build pipeline (Bolt Help Center, 2026). So you walk out of v0 with a PWA-in-disguise that Apple rejects as a "repackaged website," or out of Bolt with code that never becomes an .ipa or .apk. The prototype is great. It just isn't an app. Treat it as an interactive wireframe, then rebuild the production version in Flutter or native.

I shipped two mobile apps solo, from zero to the stores: OverAir (digital memory over WhatsApp — 0 paying customers today, I'll say that openly) and Studio Kallos (booking for beauty studios). Both are Flutter, live on the App Store and Google Play. I know exactly where vibecoding stalls on mobile, because I've hand-built everything it skips.

This post is the ruler. Where v0/Bolt/Lovable stop. Why they stop. And what to do with the prototype you already have.

What each tool actually generates

The first confusion is thinking "it made a pretty screen on a phone" means "it made an app." It doesn't. Here's what each one actually produces in 2026:

Tool	Real output	Becomes a store app?
v0 (Vercel)	Next.js + React + Tailwind. A website.	No. It's a site. Wrapped in a WebView, Apple rejects it.
Bolt.new	React Native via Expo	Code yes, build no — runs in a browser sandbox, no Xcode/EAS (Bolt, 2026)
Lovable	React web + Supabase	No. It's a web app. Same fate as v0.

v0 is honest about this, actually. Vercel built its own v0 iOS app in React Native with Expo — and they explained they moved the business logic from client to server precisely so the native app could be a thin shell over the API (Vercel Engineering, 2026). Translation: not even Vercel uses v0 to generate v0's own native app. They used React Native engineers.

Bolt got closer — it generates real Expo. But one line in its own support docs kills the illusion: the code runs "in a browser sandbox that cannot run Xcode, Android Studio, or the Expo build pipeline" (Bolt Help Center, 2026). You have the code. You don't have the factory that turns code into a signed binary. And the factory is the hard part.

Apple's wall: Guideline 4.2

If you wrap the v0 prototype (which is a website) inside a WebView and submit it to the App Store, you hit Guideline 4.2 — Minimum Functionality. Apple's official text is blunt:

"Your app should include features, content, and UI that elevate it beyond a repackaged website. (...) apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." — App Store Review Guidelines 4.2

"Web clipping" is Apple's own term for exactly this: a site inside a WebView. A PWA wrapped in a native shell trips this rule often. Apple doesn't publish a rejection rate, so I won't invent one — but the reviewer's stock reply is well known: "your app is not sufficiently different from a mobile web browsing experience." I wouldn't gamble the review queue (still hours-to-days in 2026) on an app with a coin-flip chance of bouncing back on 4.2. That's the wrong way to spend your launch window.

The 5 native pieces the prototype never builds

A pretty screen is what vibecoding does well. The problem is everything under the screen. Here are the five I had to hand-build for OverAir and Kallos — and that no prompt delivers ready:

1. Real push notifications

In OverAir, push is the product — it's how a memory reminds you. For that I needed firebase_messaging, APNs token registration on the iOS side, a push certificate in Apple's portal, and a notification channel on Android. Can a v0 prototype send a notification? Sure — a browser notification, which on iOS depends on Safari being open and which nobody sees. Not the same thing. Native push requires APNs and FCM wired into the binary. The prompt never touches it.

2. Biometrics and native permissions

Camera, microphone, Face ID, location — each needs a usage-description string in the Info.plist (iOS) and a declared permission in AndroidManifest.xml. Forget the Info.plist string and the app crashes the instant it requests the camera, or bounces from review. In Kallos I use image_picker for client photos and permission_handler to orchestrate the permission flow. That's native config, not JSX. A vibe-coder doesn't write Info.plist.

3. Deep links / universal links

When a Kallos client taps a booking link, the app opens on the right screen. That's app_links in Flutter + an apple-app-site-association file hosted on the domain + Android's assetlinks.json, with signature verification. It's tedious, it's native, and it's invisible — until it's missing, and the link opens the browser instead of the app. No vibecoding tool builds the domain-association files for you.

4. Splash, adaptive icon, and shortcuts

This is what separates "real app" from "prototype." Native splash screen (not that 2-second white flash), an adaptive icon that reshapes for the Android launcher, long-press shortcuts on the icon. In Kallos I generate these with flutter_launcher_icons. Without them the app looks amateur on the first screen — and the first impression on a store listing is the icon. Vibecoding ignores 100% of this.

5. Offline state and sync

A mobile app opens on the subway, in an elevator, on bad 3G. It has to work offline and sync later. A web prototype assumes a connection always exists. Rewriting for offline-first isn't a tweak — it's an architecture decision you make up front.

The hidden cost: signing, provisioning, and the stores

Even if you had Bolt's perfect React Native code, you'd still be missing the part that costs money and time: turning code into a binary that enters the store. Nobody vibe-codes that.

Item	What it is	Cost / friction
Apple Developer Program	Required account to publish iOS	$99/year (Expo Docs, 2026)
Google Play Developer	Required account to publish Android	$25, one-time fee (Expo Docs, 2026)
Distribution certificate + provisioning profile	Cryptographic signature on the iOS binary	Generated via EAS or Xcode; require an Apple account with credential permissions (Expo App Signing, 2026)
TestFlight / Play internal track	Test distribution before the store	Tester setup, signed build, processing
Review	Apple/Google approval queue	Hours to days, with 4.2 risk

Code signing is where most founders coming from vibecoding get stuck. It's not a product concept — it's a chain-of-trust cryptography handshake between you, Apple, and the device. Expo, which automates this better than anyone, still requires you to have an Apple account with permission to create certificates, identifiers, and provisioning profiles (Expo, 2026). The vibecoding tool never reaches that door. (For UAE builders: the Apple and Google fees are the same in USD regardless of region — roughly AED 363/year and a one-time AED 92.)

Hot reload: the number that changes your day

There's a productivity argument the hype skips. When you build mobile for real, you run the app in a simulator and edit constantly. The speed of that loop decides how many iterations you get per hour.

Flutter hot reload: 0.4 to 0.8 seconds, preserving app state (Flutter Docs, 2026). Change a color, save, and half a second later the screen updates without losing where you were in the flow. React Native's Fast Refresh improved with the New Architecture, but changes touching a native module still force a full rebuild (Flutter vs React Native, 2026) — and a full rebuild is tens of seconds.

Building OverAir and Kallos, the practical gap between half a second and a 30-second rebuild is brutal — easily 30x more iterations per hour when the loop is sub-second. That's not a benchmark number, it's a workday number. For someone writing UI 6 hours a day, that's the difference between testing 400 variations and testing 12.

What to do with your v0 prototype

Here's where I flip from "doesn't work" to "use it right." The v0/Bolt/Lovable prototype has value — it's just not the value you were sold. Use it like this:

Treat it as a high-fidelity interactive wireframe. It solved your design, screen flow, copy, and palette. That's real work and it saves days of Figma. Show it to an investor, validate with a user, lock the scope.
Extract the decisions, not the code. Write down: which screens, what navigation, which UI states. That's the brief for the production version.
Rebuild the native layer in Flutter (my pick) or React Native with a team that actually knows Expo. Flutter because one codebase ships iOS + Android, hot reload is sub-second, and the whole stack — push, deep links, permissions, splash, offline — has mature packages.
Don't try to "export and fix" the vibe-coded code. I've run the math: unpicking v0's React to force it into React Native is more work than rebuilding clean. The prototype assumed web in every architecture decision. Migrating those assumptions one by one costs more than starting from the right base.

The verdict

Vibecoding is an excellent prototype machine and a nonexistent mobile-app factory. For a landing page, internal dashboard, or web MVP that validates an idea — go for it, v0 and Lovable save weeks. For an app that ships to the App Store and Google Play, I'd avoid starting with vibecoding, because the easy part (the screen) is the only part it does, and the hard part (native + signing + review) is 100% manual either way.

If you've got a v0 prototype and want it to become a production app, the honest path is: prototype becomes the spec, Flutter becomes the product. That's how OverAir and Kallos went from idea to store. It's the work Hens does — take the validated idea and ship the signed binary that survives review.