arrow_back Back to Blog
lovable mobile app mobile app native app

Lovable Mobile App: What You Actually Get

·

If you searched “Lovable mobile app” you probably meant one of two things, and they get mixed up all the time.

The first is Lovable’s own app for your phone. That exists. You can open your projects on iOS or Android, prompt changes, and check a preview while you’re on a train. It’s a remote control for the Lovable editor. It does not turn what you built into something that goes in the App Store.

The second meaning is the one founders email us about: “I built my product in Lovable, can it be a real mobile app now?” Short answer, Lovable builds a React web app (Vite, Tailwind, shadcn, usually Supabase behind it). It does not output a Swift project, a Kotlin project or an Expo project. Your app runs in a browser. Everything below is about the ways to get from that browser app onto a phone, and which one I’d pick for which kind of product.

Path 1: make it a PWA and stop there

A progressive web app is your existing Lovable app with a manifest file, a service worker and some icons. Users open the site in Safari or Chrome, tap “Add to Home Screen,” and get an icon that opens full-screen without the browser bar. No store review, no developer accounts, no $99 a year to Apple.

For internal tools, B2B dashboards and anything people use at a desk most of the time, this is honestly the right answer and I’ll say so on a sales call even though it means we don’t get the project. The work is small, mostly fixing the layout bugs that show up when there’s no browser chrome (the bottom tab bar sitting under the iPhone home indicator is the classic one, fixed with env(safe-area-inset-bottom)).

The catch is iOS. Web push notifications on iPhone only work after the user has added the app to the home screen, which most people never do unless you walk them through it. We built a PWA for a small appointment booking business last spring. Android users got reminders fine. On iPhone, about one in five customers had installed it to the home screen, so four in five never got a single reminder, and no-shows barely moved. They came back three months later for a store app.

Path 2: wrap it with Capacitor

Capacitor takes your built web app and puts it inside a native iOS and Android shell, with plugins for push, camera, biometrics, haptics and so on. You keep the Lovable codebase, you can keep prompting in Lovable for most UI changes, and you rebuild the native shells when you ship.

It’s the route most Lovable founders try first, and it’s where people underestimate the work. The wrap itself is an afternoon. Getting through Apple review is not, because a website in a frame gets rejected under Guideline 4.2 (minimum functionality). Apple wants to see the app do app things. In practice that means native push through APNs and FCM instead of web push, a proper offline state instead of a white screen when the network drops, native sharing, and login that doesn’t bounce the user out to Safari and lose them. Google OAuth inside a WebView is its own small nightmare, because Google blocks sign-in from embedded WebViews (Error 403: disallowed_useragent), so you need the system browser flow with a deep link back into the app.

A clean Lovable app is the easy case. A messy one, with auth logic scattered across components and localStorage used as a database, takes a lot longer, and most of that extra time goes into fixing the web app rather than anything mobile.

Path 3: rebuild the frontend natively

React Native with Expo, or Flutter. You keep the Supabase backend, database, auth and edge functions exactly as they are, and rewrite the screens.

People hear “rewrite” and flinch, but for some products it’s the only option that feels right in the hand. If your app is a feed people scroll for twenty minutes, a chat app, anything with heavy gestures, maps with lots of markers, or video, a WebView will feel slightly wrong, and users can tell even if they can’t say why. Scroll physics, keyboard behaviour, the way a modal sheet drags down. Those are the things a wrapped web app never quite nails.

Between the two, I lean React Native for Lovable apps because the code is still TypeScript and React, so your business logic, Supabase queries and types mostly carry over. Flutter is a great toolkit and I’d still pick it for a brand new app with a design system built from scratch. For a Lovable conversion, throwing away all the TypeScript to write Dart is hard to justify.

So which one

Roughly how I’d decide, without pretending it’s a formula:

  • Used mostly on desktop, mobile is a nice-to-have: PWA.
  • Needs to be in the stores, mostly forms, lists and dashboards, push matters: Capacitor.
  • The phone is the product, people live in it daily, heavy interaction: React Native rebuild.

And before any of the three, check the web app is actually ready. Store reviewers will create an account, try to delete it (Apple requires in-app account deletion if you offer sign-up), hit every screen with no network, and rotate the phone. Things that slide on a web app get caught there.

If you want a second opinion on which path fits your Lovable app, send us the link on the contact page. We’ll tell you which one we’d pick, including when the answer is “just ship the PWA.” More about how we do conversions is on the home page.