Lovable + Despia vs a native rebuild: two ways to turn the Lovable app that validated your idea into a mobile app

1. Is the phone app the same product as the website, or a different one? If users want the web app in their pocket with notifications and an icon, the wrapper is the shorter route. If the phone app has its own jobs — camera-first flows, offline use, widgets, the lock screen, a store subscription with a paywall that has to pass review — it is a different product and is built as one.

2. Do you want to keep building in Lovable, or move the mobile product out of it? With a wrapper, Lovable stays the source of truth: change the web app, and the mobile app changes with it (Despia: “a UI or logic change goes live without an App Store resubmission”). With a rebuild, the mobile apps have their own project and their own agent; the web app in Lovable keeps going as the web product, and the two are maintained separately.

3. Who will own the mobile code in a year? A wrapper’s exported project is the shell around your web app; the product logic stays web code. A rebuild’s projects are Swift and Kotlin an iOS or Android engineer can take over, or an acquirer can read. Code export vs no-code lock-in has the six layers this question is really asking about.

Three rows: the two routes this page is about, and the do-it-yourself version of the first — Capacitor — because Lovable’s own documentation names it and Despia positions against it (“Capacitor takes your web build and puts it inside a native shell, then gives you the real native project to go with it”).

What it is, in its own words: “Despia Native – Turn Lovable Apps into Mobile Apps Instantly”; “Lovable builds the app. Despia gets it approved. Plug in 50+ native features the App Store and Play Store require - without changing your stack.” How it works: “Despia takes the same Lovable app and ships it as a real native binary for iOS and Android, with your web code running in the platform WebView.” The web code reaches native features through a JavaScript SDK; the published list includes push notifications, biometric verification, camera access, offline support, in-app purchases, haptic feedback, contact access, Siri shortcuts, background location, local storage, file sharing, social sharing, deeplinking and screenshot capture. Updates: “Web content updates ship over the air through remote hydration, so a UI or logic change goes live without an App Store resubmission.” Export: “you can export full Xcode and Android Studio projects at any time” — what those projects contain beyond the shell is not stated on the pages read. Price, as published 25 September 2026: Solo Pack $249 one-time for iOS or Android; Hybrid Pack $498 one-time for both; an “AppStore Payments” add-on at $7 per month (listed as starting 25 September 2026). Despia states the conversion takes “under 60 minutes”; this page does not verify that. What you keep: one codebase, the Lovable workflow, over-the-air changes. What you accept: the app is your web app in a WebView (WebKit on iOS, per guideline 2.5.6); platform UI — navigation, sheets, new device layouts such as the iPhone Duo’s — is whatever the web app implements; and the store bar for wrapped sites applies, which is the next paragraph.

The store rule, quoted. Apple’s guideline 4.2, Minimum Functionality: “Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or ‘app-like,’ it doesn’t belong on the App Store.” Despia’s feature list is aimed at exactly that sentence — a wrapper that adds push, biometrics, purchases and camera is doing something the website does not — and the guideline is a bar, not a ban. What has passed and what has not is on turn a website into an app and App Store rejection reasons.

What it is: an AI app builder for native iOS and Android apps, on a Mac, with your own AI agent. The output is not a shell around the web app; it is the product rebuilt in the platform’s own frameworks. From Modaal’s documentation: “Each feature’s logic — its state, the actions that change it, the effects it requests — is written once,” and “The iPhone app renders that state in SwiftUI; the Android app renders it in Jetpack Compose.” The Xcode project and the Android Studio project are on your disk on every plan, including Free.

Import from Lovable — the button. Your Lovable project is the input. Connect it (Lovable’s two-way GitHub sync is available on every Lovable plan), and Modaal reads the codebase — the routes and screens, the data model, the Supabase schema and auth — and writes a plan: the screen list, the features, and what maps to what, as a document you approve before any code is written. Then several agents rebuild the app feature by feature: the logic once, the SwiftUI screens for iPhone, the Jetpack Compose screens for Android, against the same Supabase backend your web app already uses (Supabase’s Swift client is Supabase’s own library; the Kotlin client is community-maintained). You review each feature on a real phone as it lands. The web app stays in Lovable, untouched, as the web product. How to migrate a Lovable app to a mobile app is the same route done by hand, step by step, and is the reference for what the import automates.

What you keep: the backend, the data, the users, the web app. What you get: two native apps from one project, that follow the platform first — new device layouts, system components, StoreKit 2 and Play Billing for the paywall — and that an iOS or Android engineer can open. What you accept: the mobile product now has its own project; a change to the web app in Lovable does not change the phone apps, and the reverse. Price: Free for one project with unlimited prompts on one platform; Pro is €9 per user per month billed annually, €15 monthly, and adds both platforms, TestFlight distribution and Git collaboration — /pricing. The AI runs on the subscription you already have.

Lovable’s documentation names Capacitor as a store route, and Despia describes it accurately: “Capacitor takes your web build and puts it inside a native shell, then gives you the real native project to go with it.” You export the Lovable code (export code from Lovable has the three ways), add Capacitor, and get an Xcode project and an Android Studio project you own and maintain, with plugins for native features you wire up yourself. It is the same architecture as Despia — web code in a WebView — with the vendor replaced by your own developer time and no over-the-air layer unless you add one. Guideline 4.2 applies in the same way.

The website is the product and you want it on phones this week: Despia, or Capacitor if you have a developer. Add the native features that make it more than the site in a frame, and read 4.2 before submitting.

Users are asking for things the web app cannot do well on a phone — camera-first capture, offline, widgets, notifications that open the right screen, a subscription through the store: the native rebuild. Import the Lovable project into Modaal, approve the plan, and ship the iPhone and Android apps from one project while the web app keeps running in Lovable.

You are not sure yet: the wrapper is reversible and the spec is portable. Ship the wrapper, watch what phone users actually do for a month, and write those findings into the one-page PRD; that document is the input to the rebuild whenever the answer to question 1 changes.

You may hire or sell: the rebuild, because the mobile code is then Swift and Kotlin an engineer or an acquirer can read; code export vs no-code lock-in has the questions they will ask.