Three months ago, a client came to me excited. They'd built their product in Lovable, a scheduling tool for small service businesses, and wanted it "on the App Store by next week." I remember the exact feeling: that sinking moment when you realize the person across from you has a fundamental misunderstanding about what they actually have.
They had a React web app. A good one. Built with Vite, Tailwind, Supabase backing everything. But that's not a mobile app in the way they meant it. I spent the next hour explaining the gap between "something that works on a phone" and "something you can install from an app store," and honestly, I wish I'd had this article saved to send them immediately.
The Three Paths Nobody Talks About Until It's Too Late
What I've realized working with AI-built apps in Islamabad's startup scene is that most founders don't actually know they're at a fork in the road. They think there's one way forward, but there are really three completely different approaches, each with entirely different tradeoffs.
The first is the PWA route, wrapping your Lovable app in a manifest file, throwing in a service worker, and calling it a day. I was skeptical about this until I built one for an internal appointment system. Users add it to their home screen, and boom, full-screen app without the browser chrome. No Apple review gauntlet, no $99 annual developer fee, just instant deployment.
The problem? It's 2025 and web push on iOS is still broken. We shipped this with notifications enabled, feeling confident. Then we realized four out of five iPhone users never bothered adding it to the home screen, so they never got a single notification. The client came back three months later asking for a real app. That hurt more than the work itself.
Capacitor: The Middle Ground That Looks Easier Than It Is
Path two is wrapping your app with Capacitor. This is seductive because it looks straightforward, you keep your Lovable codebase, rebuild the native shell, ship to stores. The wrap itself? Afternoon work. Getting past Apple's review? That's where everyone underestimates.
Apple's Guideline 4.2 will reject a website in a frame. They want to see real mobile behavior, native push notifications through APNs and FCM, proper offline states, native sharing. I watched a founder spend three weeks fighting with Google OAuth inside a WebView (Google blocks that by default for security reasons, error 403), implementing deep links, reworking their auth flow. Most of that pain wasn't Capacitor's fault. It was spaghetti in the original web app.
This is where the quality of your Lovable codebase matters. A clean app with organized auth flows? Capacitor is genuinely viable. A mess with auth scattered across components and localStorage treated like a database? You're in for a bad month.
React Native: When You Actually Need an App
The third path is rebuilding in React Native or Flutter. I know that word-"rebuild"-makes developers flinch. But sometimes it's the only option that doesn't feel compromised.
If your product is a feed people scroll through for twenty minutes, a chat app, anything with heavy gestures or complex animations, a WebView wrapped in native chrome will always feel slightly wrong. The scroll physics won't quite match native expectations. Modal sheets won't animate right. Keyboard behavior will feel off-brand.
For Lovable conversions specifically, I'd lean React Native over Flutter. You keep your TypeScript and React logic. Your Supabase queries, your business logic, your types, all of that carries over. You're only rewriting the UI layer, not learning a completely new ecosystem and language.
What I'd Actually Do
Here's my honest take: I agree with the framework in the original article, but I'd add one crucial step first, audit your web app ruthlessly before committing to any path. Store reviewers will create accounts, try to delete them (Apple now requires this), hit screens with no network, and rotate their phones. Things that slide on a web app will get caught by Apple's testers.
For most of my clients, the answer has been Capacitor with serious backend work, not PWA. The notification problem on iOS is a deal-breaker for anything that depends on user engagement. But I've also seen the PWA win for internal B2B tools where iOS notifications don't matter at all.
The real lesson is this: Lovable is a web framework. It's exceptional at that job. Treating it like a mobile app factory sets up unrealistic expectations about deployment timelines and feature parity.
What's your situation? If you're building in Lovable right now, have you thought about where this ends, or are you hoping it just magically becomes an App Store app?
Source: This post was inspired by "Lovable Mobile App: What You Actually Get" by Dev.to. Read the original article
