How to turn a website into an app: the three routes, and what each one puts on the phone

The sentence covers four different goals, and each has a different cheapest answer.

"The site should work well on phones." That is responsive design, done inside the website. No app is involved.

"I want an icon on the home screen." A progressive web app does this. Users add the site to their home screen from the browser; it opens without browser chrome. There is no store listing.

"I need to be in the App Store and Google Play." Now a store-submitted binary is required, and the two routes are a wrapper or a rebuild.

"I need push notifications, offline use, the camera, or the feel of an installed app." A Home Screen web app on iOS 16.4 and later can receive push notifications (WebKit blog, 16 February 2023). Camera, sensors, background work, widgets, platform navigation and offline data are where native code is required, which points at the rebuild route.

Name the goal first. The route follows from it.

A progressive web app is the website itself, served with a web app manifest and a service worker, so that a phone can install it to the home screen and open it full-screen. Nothing is submitted to a store; the site is updated by deploying the site.

What it gives you: a home-screen icon, an app-like window, and on iOS and iPadOS 16.4 and later, push notifications and a badge count for web apps that have been added to the Home Screen — Apple’s WebKit team announced that on 16 February 2023 with the condition that "a web app that has been added to the Home Screen can request permission to receive push notifications".

What it does not give you: a store listing (nobody finds a PWA by browsing the App Store), store payments, and the device capabilities that browsers do not expose. Lovable’s own FAQ names this as the first of its two paths for "an installable app on phones" (read 21 September 2026).

When it is the right answer: users arrive by link, the product is what the browser already does well, and the goal was the icon.

A wrapper is a native iOS and Android project whose main screen is a web view that loads your website, plus a bridge that gives the web page access to native features through plugins. Capacitor, the most-cited tool on this route, describes itself as "a cross-platform native runtime that makes it easy to build performant mobile applications that run natively on iOS, Android, and more using modern web tooling" (capacitorjs.com/docs, read 21 September 2026). Lovable’s FAQ names it as the second path: "wrap your published app with a tool like Capacitor to submit it to the App Store or Play Store".

What it gives you: a store-submittable binary in days, one web codebase, and plugin access to push notifications, camera and file storage.

What the stores say about it. Apple’s App Store Review Guidelines, section 4.2 Minimum Functionality: "Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or ‘app-like,’ it doesn’t belong on the App Store." Section 4.2.2: "Other than catalogs, apps shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." Section 2.5.6 requires that apps that browse the web use WebKit. Google’s Android Developers Blog, 16 October 2020, on apps submitted as a web view of a site: "Such apps are considered webview spam, and are removed from Play", with the advice to "think through what users can do or do better with the app than in a web experience". Google Play’s current policy on minimum functionality says the same in policy language; this page does not quote it.

What that means in practice: a wrapper that is only the website in a frame is what these rules describe. A wrapper passes when the app does something the website does not — offline content, native navigation, push, camera — and looks like an app rather than a page. The build-review-fix loop is in App Store rejection reasons.

When it is the right answer: a store listing is required, the product is content-shaped, and the team will add app-specific features rather than ship the site as is.

A website has two halves. The backend — database, accounts, storage, business logic — is not web-specific: a native app talks to the same API or the same Supabase project the website uses. Supabase publishes its own Swift client library (supabase-swift), and a Kotlin client exists that Supabase’s docs describe as "created and maintained by the Supabase community". The frontend — the screens — is what gets rebuilt, because phones do not run React or Vue natively.

That split is what makes the route practical: the website’s code is the specification of what to rebuild (every screen, state and flow, already decided), the backend needs no migration, and the website keeps running while the app is built. The app becomes a second client of the same data.

What it gives you: an app that uses the phone’s own UI framework and features, code you own, and a review submission that is an app by construction rather than a website with additions.

What it costs: a second codebase to maintain. This is the route that AI agents changed. With the website’s code and the backend schema as input, an agent writes the native screens: Modaal — ours — produces Swift/SwiftUI for iOS and Kotlin/Jetpack Compose for Android from one project, runs on your own AI subscription rather than credits, and keeps the code on your Mac; the Free plan covers one project with unlimited prompts on one platform, and Pro is €9 per user per month on the annual plan. Rork writes a Swift app and a Kotlin app as separate codebases. The React Native route — Expo-based tools — rebuilds the screens in JavaScript instead; React Native vs native covers what that runtime can and cannot reach, and how to build a cross-platform app with AI is the step-by-step.

When it is the right answer: the goal includes anything browsers do not give, or the app has to pass review with margin and be maintained as a product.

1. Do users arrive by link, or do they need to install? By link: the website is the right product, and a PWA covers the icon. Install: continue.

2. Does the app need what the browser does not give? Camera, sensors, offline data, background work, widgets, platform navigation, store payments. No: a wrapper with app-specific additions is defensible. Yes: rebuild.

3. Who maintains the second surface? A wrapper is one codebase and one team. A rebuild is a second codebase; with an agent, the maintenance is prompting against the same backend, but it is still a second product. Decide who owns it before choosing the route — how to choose an AI mobile app builder is the framework for the tool decision once the route is chosen.

Both the wrapper and the rebuild end in a store submission, and the fees do not depend on the route: the Apple Developer Program is $99 per year, and a Google Play developer account is $25 one time. Apple’s review reads the binary against the guidelines quoted above; Google’s review applies the Play policies. The submission steps — bundle identifier, App Store Connect record, screenshots, privacy details, TestFlight, review — are in how to publish an app on the App Store.

The three routes are the same, and the vendor’s own documentation says which two it supports. Lovable’s FAQ (read 21 September 2026): "Lovable builds web applications, and you can design them to be fully mobile friendly. Lovable does not generate React Native projects. If you want an installable app on phones, there are two common paths: make your published app a Progressive Web App (PWA) that users add to their home screen, or wrap your published app with a tool like Capacitor to submit it to the App Store or Play Store."

The third route starts from the export: how to export code from Lovable covers what the export contains, and migrating a Lovable app to a mobile app covers the rebuild on the Supabase backend the Lovable app already uses.