Convert a web app to a mobile app: the three routes, and what carries over in each

1. Is the phone app the same product as the website, or a different one? If users want the web app in their pocket with an icon and notifications, the wrapper is the shortest route. If the phone app has its own jobs — camera, offline, widgets, notifications that open the right screen, a subscription through the store — it is a different product and gets built as one.

2. Who will own the mobile code in a year? A wrapper’s project is a shell around web code; the product logic stays in the web app. A native rebuild gives you Swift and Kotlin projects an iOS or Android engineer can take over, or an acquirer can read. Code export vs no-code lock-in is the long version of this question.

3. Do you need Android at the same time? Most conversions do — a web product already serves both. A wrapper covers both from one web app; a by-hand rebuild is two apps; an agent rebuild from one project covers both if the tool writes the logic once. Ask how Android comes out before you pick.

The table shows what carries over from your repository in each route and what gets rebuilt. Rows are routes, not products; the tools that do each are named in the sections below.

What it is: your web app running inside a native WebView, packaged for the stores with Capacitor (do it yourself) or a service like Despia (which describes its own output as “your web code running in the platform WebView”), with a bridge so the web code can use push, camera and purchases. What carries over: everything — it is the same web app. What you accept: the app is still a web page; navigation, gestures and new device layouts are whatever the web app implements, and Apple’s guideline 4.2 sets the bar: “Your app should include features, content, and UI that elevate it beyond a repackaged website.” A wrapper that adds push, offline or camera clears it; a site in a frame is what the sentence is written for. Turn a website into an app has the full route and what has passed.

What it is: what a mobile developer does when you hand them your repository. They read the routes (each becomes a screen), the data model, the API calls and the auth provider; they rebuild the screens in SwiftUI for iPhone and Jetpack Compose for Android; they point both at the same backend. If the backend is Supabase, the iPhone app uses Supabase’s own Swift client and the Android app the community-maintained Kotlin one. What carries over: backend, data, users, auth, business rules, the API. What is rebuilt: every screen, the navigation, the state handling — twice, once per platform. What you accept: two codebases to maintain, and a brief you have to write well enough that the developer builds the app you meant. The brief is the same document as the one-page PRD: screens, what each must do, what is out. If your web app is React or Next.js, convert a React app to a native mobile app has the file-by-file view of what maps and what doesn’t.

What it is: the by-hand route, done by agents, from your repository. You connect the GitHub repo; Modaal reads it the way a developer would — routes, screens, data model, API, auth — and writes a plan: the screen list, the features, what maps to what, as a document you approve before any code is written. Then the agents rebuild feature by feature: the logic once, the SwiftUI screens for iPhone, the Jetpack Compose screens for Android, against the backend your web app already uses. From Modaal’s documentation: “Each feature’s logic — its state, the actions that change it, the effects it requests — is written once,” and “The iPhone app renders that state in SwiftUI; the Android app renders it in Jetpack Compose.” You test each feature on a real phone as it lands; the Xcode and Android Studio projects are on your own disk from the first feature, on every plan. The web app keeps running untouched.

What carries over: the same as route 2 — backend, data, users, auth, business rules. What is rebuilt: the screens, natively, from the plan — the UI is re-created for the phone, not ported from CSS. What you accept: a Mac, and reading the plan instead of a one-line prompt. Price: Free for one project with unlimited prompts on one platform; Pro is €9 per user per month billed annually, €15 monthly, and adds both platforms, TestFlight distribution and Git collaboration — /pricing. The product page is /web-to-native; the import is rolling out to early-access users in October 2026, and the list is on that page.

Website is the product, users want it on the home screen with notifications: wrap it, add the native features that make it more than the site in a frame, read 4.2 before submitting.

The phone app has its own jobs, you have a developer, and one platform is enough for now: rebuild by hand; write the PRD first so the developer builds what you meant.

The phone app has its own jobs, you want both platforms, and you'd rather approve a plan than hire: connect the repo to Modaal; the web app stays as the web product and the native apps ship from one project.

Not sure yet: the wrapper is reversible and the spec is portable. Ship the wrapper, watch what phone users do for a month, then rebuild from the spec if the phone becomes the product.