Turn a Lovable Web App Into iOS or Android

What are the four routes from a Lovable app to mobile?

Every Lovable-to-mobile strategy falls into one of four categories: a Progressive Web App served from a browser, a Capacitor shell that wraps your existing Vite build in a native container, an Expo/React Native rebuild that replaces your web components with native equivalents, or a fully native Swift/Kotlin codebase written from scratch. The gap between these options in cost and timeline is measured in months, not days.

Most Lovable apps are React/Vite single-page applications hosted on a custom domain. That architecture maps cleanly onto Capacitor because Capacitor bundles the compiled web output — the same HTML, CSS, and JavaScript Lovable generates — inside a native iOS/Android shell. No component rewriting is required, though native API access (camera, push notifications, biometrics) must be added via Capacitor plugins.

Expo and React Native require writing or rewriting UI components using React Native primitives (`View`, `Text`, `FlatList`) rather than HTML. Your Supabase data layer, API calls, and business logic transfer; your JSX and CSS do not. Budget for a partial rewrite of every screen.

What is a PWA and why won't Apple approve it in the App Store?

A Progressive Web App is your existing Lovable web app enhanced with a Web App Manifest and a service worker for offline caching. On Android, users can install PWAs to their home screen and receive push notifications. On iOS, Apple has historically limited PWA capabilities — push notifications only arrived with iOS 16.4, and home-screen PWAs still cannot access Bluetooth, NFC, background sync, or advanced camera controls. Apple does not list PWAs in the App Store.

For many Lovable use cases — dashboards, content tools, booking flows — a PWA is genuinely sufficient and zero cost to distribute. The user visits a URL, taps 'Add to Home Screen', and gets a full-screen icon that launches the app. No app review process, no 30% platform cut, no binary submission.

The limits appear when your app needs native hardware: camera that goes beyond basic capture, precise GPS in background, Bluetooth peripherals, push notifications on iOS older than 16.4, or offline storage above the browser quota. If your feature list includes any of these, a PWA is a dead end and Capacitor or Expo is the correct next step.

How does Capacitor actually wrap a Lovable app?

Capacitor is a cross-platform bridge from Ionic. It takes your compiled web build — the `dist/` folder that Lovable's Vite pipeline generates — and packages it inside a native iOS or Android project as a local WebView. From the operating system's perspective, it is a native app. From the user's perspective, it renders your existing web UI. The native shell exposes device APIs to JavaScript via a plugin bridge.

The wrapping process has four concrete steps: install Capacitor into your project, run `npx cap init`, run `npx cap add ios` or `npx cap add android`, and then `npx cap sync` after every build to copy the latest web output into the native project. The native project then opens in Xcode or Android Studio for final signing and submission.

Common integration work after wrapping: add the Capacitor Camera plugin if your app uses file uploads, add the Push Notifications plugin for FCM/APNs, configure deep links for URL schemes (`myapp://`), handle iOS safe-area insets in CSS, and set the correct `Content-Security-Policy` to allow the WebView to call your Supabase backend.

1. Run `npm install @capacitor/core @capacitor/cli` inside your Lovable project.
2. Run `npx cap init` — set the App Name and Bundle ID (e.g. com.yourcompany.appname).
3. Build your Lovable app: `npm run build` to generate the `dist/` folder.
4. Run `npx cap add ios` and/or `npx cap add android`.
5. Run `npx cap sync` to copy the built web assets into both native projects.
6. Open the iOS project: `npx cap open ios` — requires Xcode 15+ on macOS.
7. Open the Android project: `npx cap open android` — requires Android Studio.
8. Configure signing certificates and provisioning profiles in Xcode for iOS submission.
9. Test on a real device before submitting — WebView behavior differs from the desktop browser.
10. Submit via App Store Connect (iOS) or Google Play Console (Android).

What are the app-store review gotchas for a Capacitor-wrapped app?

Apple and Google both review Capacitor-wrapped apps and both have rejected patterns to avoid. Apple's App Store Review Guidelines — specifically 4.2 (Minimum Functionality) and 2.5.6 (JavaScript execution from external sources) — are the two most common rejection reasons for WebView-based apps. Understanding them before you submit saves weeks of back-and-forth.

Guideline 4.2 requires that apps offer 'unique' functionality beyond what a website provides. Apps that are simply a thin wrapper around a mobile website — with no native features, no offline mode, no device API usage — are commonly rejected. Adding at minimum one meaningful native capability (push notifications, camera, biometrics, or offline access) significantly improves approval odds.

Guideline 2.5.6 prohibits apps from downloading and executing arbitrary JavaScript at runtime. Your Capacitor build must bundle all JavaScript locally in the native package. If your Lovable app dynamically loads scripts from an external CDN, those calls must be removed or inlined before submission. Google Play has analogous policies but is generally more lenient with WebView-based apps.

When should I choose Expo over Capacitor?

Choose Expo when your app requires a genuinely native user experience — fluid 60fps scrolling, native navigation gestures, complex animations, or deep integration with device hardware like Bluetooth, ARKit, or background location. Expo compiles to true native code using React Native, which means your UI components are native views, not a WebView rendering HTML. The trade-off is that every screen must be rewritten using React Native primitives.

Expo's managed workflow dramatically simplifies the iOS/Android build pipeline: builds run in the cloud (EAS Build), over-the-air updates are handled by EAS Update, and most native API access works without ever opening Xcode. For teams without iOS/Android experience, Expo's managed workflow is significantly less friction than a fully custom React Native setup.

The business case for Expo over Capacitor comes down to one question: does your product's success depend on a native feel? For a booking app or dashboard, Capacitor is usually indistinguishable from native to the end user. For a consumer social or fitness app where smooth animations and native gestures are part of the value proposition, Expo's native rendering is worth the rebuild cost.

What auth and deep-link work is required for any mobile path?

Supabase Auth requires additional configuration for mobile apps regardless of which path you choose. The browser-based OAuth flow — where Supabase redirects to a Google or GitHub login page — does not work inside a native WebView or React Native app by default. You must configure a custom URL scheme for deep linking so the auth redirect returns to your app rather than a browser tab.

For Capacitor: add your bundle ID as a Capacitor URL scheme in `capacitor.config.ts` and register it in Supabase's Auth settings under Redirect URLs. The Supabase JS client handles the session exchange automatically once the redirect lands on the correct scheme.

For Expo/React Native: use `expo-auth-session` or the Supabase community `react-native-auth-ui` package. Configure `exp://` or your custom scheme (`myapp://`) in Supabase's allowed redirect URLs. PKCE flow (not implicit) is required for mobile OAuth — the Supabase JS v2 client uses PKCE by default.

Push notification tokens are separate from auth tokens. For Capacitor, the `@capacitor/push-notifications` plugin provides the device token after the user grants permission. That token must be stored in your Supabase database and associated with the user ID if you intend to send targeted notifications.

How do I pick the right path for my Lovable app?

The decision tree is straightforward once you know three things: whether you need App Store presence, what native APIs your feature list requires, and what your mobile budget is. Most Lovable-built apps — dashboards, SaaS tools, booking flows, community platforms — are well-served by Capacitor. Only apps where the mobile interaction itself is the product usually justify an Expo rebuild.

Use a PWA if: you do not need App Store presence, your users come via link not search, and you have no native hardware requirements. Estimated timeline: 1–3 days. Use Capacitor if: you need App Store presence, your existing Lovable app works well on mobile web, and your native API requirements are push notifications and/or camera. Estimated timeline: 2–6 weeks. Use Expo if: the app's core value requires native animations, complex gestures, background processing, or deep hardware integration. Estimated timeline: 6–16 weeks.

The question to ask yourself: does the mobile version of this app need to feel native, or does it need to be available in the App Store? Those are different requirements. The first points to Expo. The second points to Capacitor. Both are legitimate paths — the mistake is picking Expo's timeline and cost when Capacitor would have satisfied the actual user requirement.