Convert Lovable to a Mobile App for iOS and Android

You built a working app in Lovable. It runs in the browser and does what you want. The next step, getting it onto the App Store and Google Play as a real native app, is where most people stall. And this is not toy-level native: Despia reaches background GPS that survives a force-kill, NFC read and write, Apple Health, native OAuth, on-device Vision OCR, speech recognition, and persistent WebSockets, alongside the everyday push, biometrics, and in-app purchases. This walks the whole path, from a Lovable web app to a signed native binary on both stores, and it is honest about where Despia fits and where it does not.

What going native actually requires

Lovable gives you the web app. To ship it as a native app you need three more things: a signed native binary for each store, native device features the browser cannot reach, and a way through App Store and Play Console review. You can assemble all of that yourself with Xcode, Android Studio, and a Mac, or you can keep your Lovable codebase as the source of truth and let Despia produce the binary and the native features from it.

Despia runs your Lovable web app inside the platform WebView (WKWebView on iOS, a Chromium-based WebView on Android) and exposes 50+ native features through a single JavaScript function. You keep one codebase. The web app stays where you already build it, in Lovable.

Start by connecting the Despia MCP to Lovable

If you have not used Despia before, do this first, because it saves you from hand-writing any native code. Despia publishes an MCP server that teaches Lovable how the despia-native package works, so Lovable writes correct native calls instead of guessing at them.

In Lovable, open Connectors, go to Chat connectors, click New MCP server, name it Despia, and paste the URL (no authentication needed):

https://setup.despia.com/mcp

Allow tool usage when Lovable asks. Then, before you build anything native, ask Lovable a direct question: based on the Despia MCP, can Despia support every native feature this app needs. Lovable will read the Despia docs through the MCP and answer. That one question decides your whole path, so ask it early.

Check your feature list against what Despia supports

Despia covers the native surface most apps need: push notifications, Face ID and Touch ID, camera, GPS, NFC, in-app purchases, native OAuth, offline storage, haptics, and more, all through despia(). For the large majority of Lovable apps, that is the entire list.

It is not the entire list for every app, and pretending otherwise would waste your time. Despia supports the features it ships. If your app depends on something outside that set, for example heavy real-time AR, a custom Metal or OpenGL renderer, or a niche native SDK that Despia does not bridge, you are past what a web-native runtime can do for you. Despia still gives you a way forward there: you can export the full Xcode and Android Studio projects at any time and continue in native code. That export is the honest escape hatch, and it is exactly why checking your feature list against the docs through the MCP before you commit is worth the five minutes.

Keep building in Lovable, ship updates over the air

Once you are on Despia your workflow does not change. You keep building in Lovable. Because the web app is the source of truth, web changes ship to your installed apps over the air through remote hydration, with no App Store or Play Console resubmission. Change a screen, deploy in Lovable, force close the app, reopen, and the change is there.

You only rebuild the binary when you add a native capability that has to be compiled in, such as switching on a new integration. Content, layout, copy, and logic changes all go out over the air.

One detail AI builders get wrong, and the MCP corrects: native calls must be gated to the Despia runtime, and the right check is the user agent, never a window.despia object.

const isDespia = navigator.userAgent.toLowerCase().includes('despia')

// native schemes only resolve inside the runtime, so gate them
if (isDespia) {
  despia(`revenuecat://launchPaywall?external_id=${userId}&offering=default`)
}

Why this is more than a wrapper

A plain wrapper like PWA Builder is the obvious cheap option, and for a truly simple case it can be enough. Where wrappers get people rejected is that they hand the store a web page in a native shell with no native substance, which runs straight into App Store Guideline 4.2 and the minimum-functionality bar both stores enforce. Despia is a web-first native framework rather than a shell, so the native features are actually present and you can clear the functionality requirements that reject wrappers.

	Plain wrapper	Despia
Setup	Point at a URL	Point at a URL
Native device features	Few or none	50+ through despia()
OAuth	Runs inside the WebView, often blocked	Native secure browser session
Guideline 4.2 / minimum functionality	Frequently rejected	Native features to clear it
Over-the-air updates	Varies	Web layer via remote hydration
Rejection guidance	On your own	Indexed fix list in the docs
Escape hatch	None	Export full Xcode and Android Studio project

A few of those rows are worth a sentence each.

OAuth is the clearest one. Native WebViews are exactly where Google and Apple block embedded OAuth, so wrapper sign-in tends to break. Despia opens sign-in in a real secure browser session through the oauth:// bridge, using ASWebAuthenticationSession on iOS and Chrome Custom Tabs on Android, which is what the stores require and what users recognise as legitimate.

Performance is the myth. The idea that a wrapped app is inherently slow does not hold. Despia runs on the same WebView engines that power fast production apps, and when a Despia app feels slow the cause is almost always the web app itself. The docs include a performance guide that covers the usual culprits.

Free-trial fraud and the expensive features are handled too. Despia's Storage Vault survives uninstall and reinstall, so a user cannot wipe the app to reset a free trial, and you can lock sensitive values behind Face ID. NFC, GPS, and other capabilities that normally sit behind paid tiers on other tools are included at no extra cost.

One thing no framework fixes for you is the layout. If your app looks like a website, with sidebars, hamburger menus, and desktop navigation, reviewers reject it regardless of how it was built. Get the mobile-first structure right, a fixed shell with one scrolling area, bottom navigation, and safe-area handling, and the native features do the rest. If you connected the MCP, ask Lovable to build it that way from the start.

Why not Capacitor

Capacitor is the serious alternative, and its plugin ecosystem is genuinely larger than Despia's. If your app needs a long tail of specialised native integrations, that breadth is a real advantage and worth being straight about.

For most apps it is breadth you never use. The features 99% of apps actually ship, push, biometrics, camera, GPS, NFC, in-app purchases, OAuth, offline storage, are the ones Despia provides out of the box. Because those decisions are made for you, the rest of the pipeline gets simpler in ways that matter more day to day than plugin count:

Deployment runs entirely in the browser. Despia builds and submits with no Xcode and no Android Studio, while Capacitor keeps you in the native toolchains and a Mac for iOS.

Hosting stays yours. Despia serves your web layer from wherever you already host, Lovable's built-in hosting, Netlify, or your own setup, with no migration.

Over-the-air updates are free at any scale. Capacitor's live updates run through third-party services that bill by monthly active users, so your update costs climb as you grow. Despia ships OTA updates over unlimited MAUs at no cost, which is the difference that shows up once the app takes off.

So the honest split is this: reach for Capacitor when you truly need its plugin depth or your own native code alongside it. Choose Despia when you want the native features almost every app needs, a browser-only pipeline, hosting freedom, and OTA that does not get more expensive as you scale.

Publish to the App Store and Google Play

When the app is ready, Despia builds the signed binaries and submits from the browser, with no CLI and no Mac required. The two walkthroughs below cover each store end to end. Do iOS first if you are shipping both, since App Store review usually takes longer.

iOS: https://setup.despia.com/deployment/apple-ios/automatic

Android: https://setup.despia.com/deployment/google-android/automatic

Short version: set your app icon and splash, register your bundle ID, build, then submit through TestFlight and the Play Console testing track before promoting to production. On Google Play you now register the package name before you create the listing, so copy your bundle ID from Despia first and register it exactly, since it cannot be changed later.

If you get rejected

Rejections happen to everyone, wrapper or not. What matters is what you do next. Despia keeps an indexed list of the common App Store and Play Store rejections with the specific fix for each, covering minimum functionality, login-service requirements, privacy strings, and more. Start there, apply the fix, resubmit.

Read the store rejection playbook

The point of Despia is not to wrap your app and wish you luck. It is to get it approved, with the native features and the fix playbook that actually clear review.

Get it on the stores

Take the app you built in Lovable and ship it to iOS and Android without a CLI or a Mac. Connect the Despia MCP so Lovable writes the native code, keep updating over the air, and submit from the browser.

See the setup docs at setup.despia.com or start building at despia.com.