Vibe-Coded to Native: Converting a Lovable Web App into iOS + Android Apps

GravityOne arrived with a working web product built on Lovable. The database, the auth layer, the API endpoints, even the Stripe integration were all in production, serving real users on the web. The brief was simple: get the same product into the App Store and Play Store. The hidden brief, as it usually is, was the opposite of simple: do it without rebuilding the backend, without diverging the two codebases six months from now, and without producing a "wrapped website" that gets rejected by reviewers and ignored by users.

This post walks through that engagement at the level of detail we wish more case studies offered — week by week, hours spent per phase, what we kept, what we rebuilt, what failed first review, and what the numbers looked like on launch day. It is not generic "how to launch a mobile app" content. It is one specific Lovable-to-native conversion, with the messy parts left in.

Why a native app, not a PWA or a webview wrapper

We talked the founder out of two cheaper options before we agreed to do this. The first was a Progressive Web App. PWAs have legitimate use cases, but consumer products that need push notifications, biometric auth, deep links from third-party apps, or App Store discovery do not get them from a PWA — at least not reliably across iOS Safari, where push support is still patchy and home-screen install is a hidden gesture. The second was a Capacitor or Cordova-style webview wrapper. We have shipped exactly zero of those in five years for a reason: even when they pass review (less than half the time on first try in our experience), users notice within a week and the one-star reviews start.

Day-7 retention on the GravityOne web app was sitting at 11%. Day-7 retention on the launched native apps stabilised at 33% over the first 30 days — a 22-point uplift. We have seen the same shape on enough engagements to stop calling it luck. Push, instant app-switch resume, and a home-screen icon are not decorative features. They are the thing that makes the product part of someone's day. A wrapped web app has none of them in a way that feels native, and users can tell.

Anatomy of one engagement: GravityOne, 14 weeks, 796 hours

The chart above is the entire engagement on one axis. Below, week-by-week, what actually happened in each phase, with the choices we made and the things that surprised us.

Week 1 — Backend audit and the "do not rebuild" decision

Before writing any mobile code we ran our standard 22-criterion audit on the existing Lovable codebase, with one major difference: this time we audited the backend specifically, because that's what the mobile app would inherit. Findings: 23 Row Level Security policies (4 of which read using (true), the polite way to say "no security at all"), one Stripe webhook still unsigned in production, three Edge Functions with no rate limits, and a small but real N+1 query on the discovery feed that mattered more once mobile users were polling on cellular.

We hardened the backend in week one — not as part of the mobile work, but as a precondition for it. By the end of the week, the same web app was running on a measurably safer Supabase project, and the mobile app had a stable contract to build against. The decision we made deliberately was not to add a separate "mobile API" surface. The mobile app would hit the same endpoints the web app hit. Where the payload had to differ (lighter list responses, push token registration, app-version gates), we added three new endpoints to the same API — not a second one.

This is the single most important architectural decision in any web-to-native conversion. Once you have two APIs they will diverge, and the divergence will eat a sprint per quarter forever. We build web-to-native conversions on a shared backend by default precisely because we have watched parallel APIs become technical debt on two separate engagements.

Week 2 — Native shell, navigation, auth on device

Stack pick: React Native via Expo's bare workflow, with EAS for builds and OTA. The reasoning is not aesthetic — the web app was already in React. The TypeScript types, the validation schemas, the API client, and a meaningful chunk of the business logic could move across without rewriting. Flutter is a great option when there is existing Dart expertise on the team or when pixel-identical rendering across platforms is a hard requirement. GravityOne had neither, so React Native was the path of least new code.

By the end of week two we had: an Expo bare RN project with EAS configured for both stores; deep-link configuration on iOS (Universal Links) and Android (App Links); Supabase Auth wired up against the same user table the web app used (so a user could sign in on either client with the same credentials); and the navigation tree — React Navigation with a tab + stack hybrid that matched the web app's information architecture without slavishly copying its URL structure.

Weeks 3–5 — Core flows ported, shared package set up

The chart above is the heart of how we think about web-to-native conversions. Some layers carry across nearly untouched. Others have to be rebuilt because mobile interaction patterns are genuinely different. The split tells you where the engineering hours go.

In weeks three through five we set up a shared TypeScript package — call it @gravityone/shared — and lifted into it: the database type definitions (generated from Supabase), the Zod validation schemas, the API client wrapper, and the more pure business-logic stores (search filters, sort orders, derived state). The web app refactored to import from that package in parallel; the native app imported from day one. By the end of week five, both clients were calling the same typed methods against the same backend. Adding a new field on the server flowed to both clients in a single PR.

Where the work actually happened in those three weeks was the UI layer — the part of the chart sitting at 38%. Every list, every form, every card had to be rebuilt against React Native primitives. <Pressable> replaces <button>. <TextInput> replaces <input>. The design system primitives ported cleanly (colours, typography, spacing tokens all came from the same JSON file), but the components themselves were new. This is the unglamorous reality of "code sharing in React Native" — the language is the same, the runtime is not.

Weeks 6–8 — Real-time, messaging, push notifications

Mobile-only surfaces showed up in the second sprint block. Real-time presence (who is online in a group right now) used the same Supabase Realtime channel the web app already used. In-app messaging was straightforward. Push was not.

Push notifications are the single best documented and worst implemented mobile feature. We follow a specific 12-failure-mode checklist when setting them up because we have hit every one. On GravityOne we hit two: the FCM token race on Android cold start (token registered with our server before the messaging() instance had finished initialising; fix: defer registration until the first foreground heartbeat), and a silent APNs failure on TestFlight where production certificates were correct but sandbox certificates had expired two months earlier. The Apple developer dashboard does not warn you about this; we found it by inspecting the NSError domain on a failed schedule and correlating it with the certificate console.

By the end of week eight, push delivery was sitting at 96.8% within 60 seconds on real devices across both platforms. The target was 95%. The remaining ~3% is the structural ceiling imposed by carrier-side delivery on Android, which no amount of client engineering will fix.

Weeks 9–10 — Offline reads, perf budget, image pipeline

Offline is where most "wrapped web app" projects fall over. Browsers handle offline by failing gracefully; native apps are expected to keep working. We built a small explicit sync layer on top of expo-sqlite: read-cache for feed and profile data, written through to disk on every network response and read from disk on every cold start. No write-side conflict resolution (the product did not need offline writes), so we dodged the hardest part of sync. We build offline this way on most React Native apps — explicit, boring, debuggable.

The performance budget was the other half of these two weeks. On a Samsung A14 (a $230 entry-level Android, our reference device for the bottom-quartile user), cold start landed at 1.9s against a 2.5s target. First screen interactive at 0.9s against a 1.5s target. We hit those by deferring the bundle split such that auth-aware screens were in the main bundle and everything else lazy-loaded, by aggressively prefetching the hero image of the first feed item before render, and by moving the Hermes engine onto the runtime (Expo's default in bare workflow as of SDK 50).

Week 11 — Internal beta, crash budget, the "is it ready" call

TestFlight build out the door first, then Firebase App Distribution for Android. 24 internal testers, then a wider circle of 80 over four days. Sentry and Crashlytics live from the first internal build. The crash-free-session rate stabilised at 99.7% by the end of the week against a 99.6% target. We do not submit to either store below 99.5% — we have learned the hard way that a crash that shows up in 0.5% of sessions in internal beta tends to show up in 1.5% of sessions on real users, and 1.5% gets you a one-star wave.

Week 12 — iOS submission, rejection, resubmission

First iOS submission was rejected the next afternoon. Guideline 4.1 — Design — Permission Strings. The NSCameraUsageDescription string read "Required to upload photos", which Apple's reviewer correctly noted does not tell the user what the camera will be used for in this specific app. We rewrote the four permission strings to be specific ("Take a photo of your venue check-in to share with your group"), resubmitted, and were approved 41 hours later.

This is the single most common rejection reason we see — five of our last 14 submissions, the most frequent category on the chart above. The fix takes ten minutes. The cost of not fixing it pre-submission is at least two days of calendar time. We wrote up the full rejection-reason breakdown elsewhere, but the headline applies: every permission string in your Info.plist should describe a specific user-visible behaviour, not a developer-facing requirement.

Week 13 — Android submission

Approved on first attempt, 27 hours from submission. The friction on Android was earlier in the process: we hit a bytecode lint warning that would have produced a Play Console warning at upload time (a deprecated API call on the FCM instance ID, fixed in a one-line refactor), and we tightened the Data Safety form to declare exactly the categories of data the app actually transmits. Play's reviewers are less likely to reject and more likely to warn-and-publish; getting it right pre-submission is about avoiding the warnings, not avoiding outright rejection.

Week 14 — Public release, monitoring, OTA channel setup

Phased rollout on both platforms: 5% of users on day one, 25% on day three, 100% on day seven. EAS Update configured with two channels — production and staging — so that JavaScript-only changes can ship the same day they merge to main, but anything touching native modules still goes through a real store build. We are deliberate about which change goes which path — OTA-shipping a native module change is the fastest way to brick an app version on user devices.

Where the 796 hours actually went

The category breakdown is the most actionable view for anyone budgeting a similar engagement. Feature port — the work of taking flows that already existed on the web and rebuilding the UI layer for React Native — was 47% of the total. Mobile-only surfaces (push, deep links, offline, performance) were 15%. The native shell and auth were 8%. Submission across both stores was 10%, with the iOS resubmission accounting for most of that. Backend hardening was 7%. The remainder went to launch and monitoring.

The interesting number is the one missing from the chart: backend rebuild was zero hours. The Supabase project the web app already used was the Supabase project the mobile app used at launch. If we had rebuilt the backend from scratch against a new design — which is what a from-scratch native app would have done — we would have added an estimated 280–340 additional engineer-hours and 6–8 weeks of calendar time. That is the explicit value of the reuse-existing-backend approach: not a small refactor saving, but a structural saving you can put on a board update slide.

Production targets vs actuals at launch

Nine production targets, eight of them met or beaten at launch. The one we missed — first-try iOS submission — cost two days of calendar time. Everything else was either inside budget (cold start, push delivery, bundle size) or beyond it (Day-7 retention came in 22 points above the web baseline, which is the number that matters to the founder).

How to do this on your project: the decision tree

The GravityOne conversion is what we call a Path A engagement: the backend already existed and was healthy enough to keep. Roughly 60% of the projects we take on are Path A. The other 40% are Path B — the web app is UI-only, the data is mocked, the auth is a stub, and the backend has to be built around the existing UI as a reference design. Path B engagements take 12–18 weeks instead of 8–14, and the engineering split shifts heavily toward backend work in the first month.

The decision tree is short:

• Does your Lovable / Claude / Bolt / v0 / AI Studio build have a real backend — a database, an auth layer, API endpoints, and a billing integration that have actually served real users at some point? Yes → Path A. No → Path B.
• Is your web app already in React? Lovable, Bolt, v0, Claude and AI Studio all output React, so the answer is almost always yes. Yes → React Native is the default. No → look at Flutter, but only if there is existing Dart expertise on the team.
• Do you need iOS only, Android only, or both? If both, the conversion path described in this post applies. If one platform only, the engagement is shorter — but the per-platform submission work does not shrink, so the saving is not proportional.
• Do you need offline writes, AR / VR, or heavy hardware access? If yes, this conversion path is the wrong call — those products want native iOS / Android, not React Native. We will tell you so on the first call.

Steps in detail — what to actually do, in order

For founders running this themselves rather than hiring it out, the engineering sequence is consistent. The hours change, the steps do not.

1. Audit the existing backend, not the frontend. You are about to add a second client. RLS policies that read using (true), unsigned webhooks, and unrated Edge Functions are bombs you do not want a mobile reviewer to find for you. Run a real audit. Our 22-criterion rubric is open-source enough to copy.
2. Lift types, validation and the API client into a shared package. Even if the web app does not have one yet, set it up before writing native code. The web app refactors to import from it in parallel; the native app imports from day one. This is the single biggest mistake people skip and pay for later.
3. Start the native build with Expo bare workflow. EAS for builds and OTA, full access to native modules when you need them. Avoid the fully managed workflow if you expect to add native modules in the next 12 months — the migration off it is not free.
4. Wire auth before any feature. Same provider as the web app, same user table. If your web app uses Supabase Auth, Firebase, Clerk, Auth0 or NextAuth, the native SDK exists. A user signing in on the app should see the same account they have on the web.
5. Build navigation as a tree, not as URL paths. React Navigation's tab + stack model is fundamentally different from React Router. Deep links map to the tree, not to web URLs. Plan this on paper before writing any screens.
6. Port flows in vertical slices, not horizontal layers. "Profile flow end to end" produces a shippable surface in a week. "All forms across the app" produces nothing shippable for three weeks. The vertical slice keeps the team motivated and gives you a real beta build to test against on every sprint.
7. Wire push notifications around week six, not week twelve. Push is the most-failure-prone subsystem in any mobile app. The earlier you discover the FCM token race or the APNs sandbox cert mismatch, the cheaper the fix. Use the 12-failure-mode checklist during integration, not after rejection.
8. Set the performance budget on a real low-end device. An entry-level Android in your target market, not a flagship. Measure cold start, first interactive, and bundle size from the first internal build, not the day before submission.
9. Write the permission strings before they cost you a rejection. Every entry in your Info.plist and AndroidManifest.xml should describe a specific user-visible behaviour. "Required to upload photos" fails. "Take a photo of your venue check-in to share with your group" passes. This is ten minutes of writing.
10. Submit iOS before Android. iOS review is slower and rejection is more likely. Knowing the result before you submit Android lets you reuse the same marketing copy, screenshots, and metadata with confidence. If iOS rejects, you have not also wasted Android review time.

How much does this cost end-to-end?

The GravityOne engagement was 796 engineering hours over 14 weeks. At our blended rates that lands around $79k. The honest range we see across roughly 14 web-to-native conversions in the last 18 months is wider:

• Path A, simple product (B2B SaaS, internal tool): 8–10 weeks, 400–550 engineering hours, $40k–$60k.
• Path A, medium complexity (consumer app, marketplace): 10–14 weeks, 600–850 hours, $60k–$95k. GravityOne sits in this band.
• Path A, complex (real-time social, fintech, healthcare): 14–18 weeks, 900–1300 hours, $95k–$160k. Compliance work and offline-first complexity push the upper bound.
• Path B (UI-only web app, no backend yet): add 4–6 weeks and $25k–$50k for the backend build that Path A skipped. The mobile-only portion stays similar.

Two numbers worth holding on to. First: the backend-reuse saving is structural, not marginal. For GravityOne it was roughly $30k–$40k of avoided work, plus 6–8 weeks of calendar time. Second: App Store submission consistently eats more time than the budget anticipates. Every engagement we have closed in the last two years has lost at least one day to permission-string or screenshot revisions, and three of the last fourteen lost more than a week to a real rejection cycle. Plan for it.

Why we are reasonably opinionated about React Native here

We default to React Native on web-to-native conversions, but the defaults have a logic and we will tell you when to break them.

Pick React Native if your web app is in React (Lovable / Claude / Bolt / v0 / AI Studio all output React), you want code reuse across web and native, and your team is already comfortable with the React mental model. You will be importing types, schemas, and a chunk of business logic across the boundary cleanly.

Pick Flutter if you already have Dart expertise on the team, you need pixel-identical rendering across iOS and Android (rare for most products, common for brand-led design systems with very strict tolerances), or your design language depends on highly custom canvas-style UI that Flutter renders more cleanly than RN does. We have shipped Flutter when it was the right call. It was not the right call on GravityOne.

Pick native iOS / Android only if the app's core value is in deep hardware integration (AR, ML on device, precision sensors, complex audio pipelines) or in platform-specific UX patterns users explicitly expect. Most consumer apps that need a "really native feel" actually need good animation work, not native code. React Native plus Reanimated v3 closes the perceived gap on 90% of the animations users notice.

What we would do differently on the next one

Three things in priority order. First, we would set up the shared package in week zero, not week three. The first two weeks of porting work is faster when types and schemas already live in a place both clients can import from. We treated the shared package as a refactor; on the next engagement we will treat it as a precondition.

Second, we would write the permission strings on day one, not the day before submission. Knowing what camera, location and notification permissions the app will need is a product question, not a submission question. Writing the strings early forces the conversation with the founder about which permissions are actually justifiable — and we removed two permissions entirely on GravityOne after that conversation, which simplified the privacy declaration and the Data Safety form.

Third, we would wire crash reporting before TestFlight, not with TestFlight. The first internal build is the build where real users start finding crashes that internal testing missed. The earlier you have a Sentry or Crashlytics dashboard with real session counts, the faster you find the failure modes that matter.

Where this work actually happens

We run web-to-native conversions as a focused service: backend reused, frontend rebuilt in React Native (or Flutter where it fits), both stores live inside 8–18 weeks depending on Path A vs Path B. The same team that does the conversion stays on for the post-launch 30-day stability watch and, in most cases, the ongoing React Native development retainer that follows. Where the backend is the limiting factor — not present, not healthy, or not designed for the mobile load profile — we add SaaS web app development capacity into the same engagement so the backend, web and native ship in lockstep instead of three diverging tracks.

About the author

Ritesh — Founding Partner, Appycodes

LinkedIn

Ritesh scoped and led the GravityOne web-to-native conversion described above. Most recent shipped projects include a Lovable-built marketplace migrated to a native React Native app across both stores in 12 weeks, and a Bolt-built consumer app where the backend needed building from scratch around the existing vibe-coded UI.

Last reviewed: May 22, 2026