arrow_back Back to Blog
capacitor vs react native lovable react native mobile app

Capacitor vs React Native for Lovable Apps

·

Capacitor vs React Native is the first real decision when you want your Lovable app in the stores, and most comparisons online are written for teams starting from nothing. You’re not starting from nothing. You have a working React + Vite app with Tailwind, shadcn components and a Supabase backend, and that changes the answer quite a bit.

Short version: Capacitor ships what you already have inside a native shell. React Native throws away your UI layer and keeps almost everything else. Both are legitimate. They fail in different ways.

Capacitor: your app, in a box

Capacitor takes the dist folder from npm run build and loads it in a WebView inside a real iOS and Android project. You add it with a couple of commands, point webDir at dist, run npx cap add ios, open Xcode, and you can have your Lovable app running on your own phone the same afternoon. Your components, your routes, your Supabase calls, all unchanged.

Native features come from plugins. @capacitor/push-notifications for push (which means setting up Firebase Cloud Messaging for Android and an APNs key for iOS, an hour of clicking through two consoles you’ll hate), @capacitor/camera, @capacitor/haptics, and so on. For payments inside the app, RevenueCat has a Capacitor plugin, and you will need it, because selling digital stuff through Stripe inside an iOS app is how you get rejected.

The catch is that it still feels like a website. Scrolling has that slightly wrong momentum. The keyboard shoves your layout around unless you handle it. Tap a link that opens in the same WebView and there’s no back gesture. None of that is fatal, but users notice, even if they can’t say what’s off.

And then there’s Apple.

The 4.2 problem

App Store guideline 4.2 is “minimum functionality”, and reviewers use it on apps that look like a website in a wrapper. A Capacitor build of a Lovable app is, technically, a website in a wrapper. Whether you get through depends on how much the app does that a browser can’t.

We had a founder come to us after their second 4.2 rejection. The app was a booking tool, pretty solid, wrapped with Capacitor, and the only native thing in it was a splash screen. The reviewer’s note was two sentences long and basically said “this is your website”. What got it through on the third try wasn’t a rewrite. We added push reminders for upcoming bookings, a native share sheet, offline caching of the user’s own bookings, and Sign in with Apple next to Google. Same WebView underneath. That was enough.

So Capacitor can work for iOS. You just have to give the reviewer native reasons to believe it’s an app.

React Native: same brain, new face

React Native renders real native views. No DOM, no WebView. That’s why it feels right, and it’s also why your Lovable UI doesn’t come with you. Every <div>, every shadcn <Dialog>, every Tailwind class on a <button> needs rewriting with <View>, <Text> and <Pressable>. NativeWind gets you Tailwind-style class names back, which helps more than you’d expect, but the components themselves are new.

What does come with you is the stuff that took longest to get right. Your Supabase project stays exactly as it is: tables, RLS policies, edge functions, auth users. @supabase/supabase-js runs in React Native. You give it AsyncStorage for the session and it mostly behaves. Your types, your validation (if you used zod, it’s portable as is), your business logic in hooks, a lot of it moves over with light edits.

We use Expo for this, without much debate. EAS Build does the iOS signing and the cloud builds, so you don’t need a Mac in the loop for every build, and updates to JavaScript can ship over the air without another review. Bare React Native gives you more control and more Gradle errors at 1am. I’d rather have Expo.

The real costs are time and drift. A rewrite takes longer than a wrap, there’s no way around that. And once you have a React Native app, Lovable doesn’t edit it. Your web app keeps changing in Lovable, and every feature you want on mobile has to be built twice. If your web app is still changing weekly, that’s a real tax.

How I’d choose

Pick Capacitor if:

  • Your app is mostly forms, lists and dashboards
  • You need to be in the stores soon and the web app is still changing every week
  • Android is the main target (Google Play doesn’t apply anything like 4.2)
  • You’re fine adding a few native features specifically so Apple says yes

Go React Native if the app lives on gestures, maps, a camera, audio, or long scrolling feeds; if people will open it ten times a day and the WebView feel will grate; or if you already got a 4.2 rejection and don’t want to argue with review forever.

There’s also a middle path people don’t talk about enough. Ship the Capacitor version first, learn what people actually use on their phones, then rebuild just those screens properly in React Native later. Your Supabase backend doesn’t care which client is talking to it, so nothing you do in phase one is wasted on the backend side.

What I wouldn’t do is wrap the app, submit it to Apple with zero native features, and hope. That’s the path that ends with the two-sentence rejection email.

If you want a second opinion on which way your app should go, send us the link and tell us what it does. If a wrapper is enough for your app, we’ll say so.