Web to native · for a working web app with its code in a repository
Turn your web app into native iOS and Android apps — from the repository you already have
You have a web app, its code in GitHub, and users asking for the app. Connect the repository. Modaal reads it the way a mobile developer would — routes, data model, API, auth — and writes a plan you approve. Then your AI agent rebuilds it feature by feature as real native apps: SwiftUI on iPhone, Jetpack Compose on Android, from one project, against the backend you already run. Not a web page in a shell. The Xcode and Android Studio projects are on your disk from the first feature.
Connect a GitHub repo → get a plan (screens, features, what maps to what) → approve it → agents rebuild natively, both platforms from one project → test each feature on a phone → submit from your own store accounts. Backend, data, users and auth carry over; screens are rebuilt for the phone, not ported from CSS. Works with React, Next.js, Vue and plain HTML repositories. Free for one project. Web to native is rolling out to early-access users in October 2026; join the list on this page and you are in the first group. Everything else on this page — the Free plan, both platforms, projects on your disk — is live today.
What a wrapper gives you, and what this gives you
A wrapper (Capacitor, or a service built on it) puts your web app inside a native shell so it can go in the stores. It is the fastest route and the right one when the website is the product. It is still a web page: navigation, gestures and new device layouts are whatever the web app does, and Apple’s guideline 4.2 sets the bar — “Your app should include features, content, and UI that elevate it beyond a repackaged website.”
Web to native produces a different thing: native apps whose screens are built from the platform’s own parts, that follow platform updates first, that an iOS or Android engineer can open, and that talk to the same backend as your web app. The web app keeps running as the web product. Convert a web app to a mobile app compares the routes if you are not sure which you need.
How it works, in the order you see it
1. Connect the repository. Sign in with GitHub and pick the repo. Modaal reads the route tree, the data model, the API calls and the auth provider. It does not need your web app to be built in any particular tool.
2. Read the plan. Before any code, you get a document: the screen list (from your routes), the features, what maps to what, what the phone app will do differently from the web app, and what is out of scope. This is the same document a developer would write after reading your repo. Edit it, then approve it.
3. The agents rebuild, feature by feature. Each feature’s logic is written once; the iPhone app renders it in SwiftUI and the Android app in Jetpack Compose — from Modaal’s documentation, “Each feature’s logic — its state, the actions that change it, the effects it requests — is written once.” The screens are re-created for the phone from the plan, not translated from CSS. The API, the auth and the data are the ones your web app uses; with Supabase, the iPhone app uses Supabase’s own Swift client and the Android app the community-maintained Kotlin client.
4. Test on a real phone. Builds run locally on your Mac with your Xcode; TestFlight and Play testing tracks for the people you want to try it. You review each feature as it lands, and the plan for the next one.
5. Submit from your own accounts. Apple Developer Program ($99 a year) and Google Play Console ($25 once), opened in your name; Modaal uploads to them. The Xcode and Android Studio projects stay on your disk, on every plan.
What carries over, what is rebuilt
Carries over: the backend, the database, the users, the auth provider, the API contract, the business rules (re-implemented in the new language, unchanged in meaning), the route tree as the screen list, design tokens as values.
Rebuilt natively: every screen, the navigation, the state handling per screen, layout, and anything that used browser APIs or web-only libraries. Convert a React app to a native mobile app has the layer-by-layer table for React and Next.js codebases.
Who this is for
A founder or product person with a validated web product and users asking for the phone app. A team whose web app is the product and whose phone app needs things the web can’t do well — camera, offline, notifications that open the right screen, widgets, a subscription through the store. Anyone who was about to hire a developer to “convert” the app and wants to see the plan first. Not for a website that only needs an icon and notifications: the wrapper route is shorter for that, and turn a website into an app explains it.
What you keep
The Xcode project and the Android Studio project on your own disk from the first feature, on the Free plan too. Your own store accounts as the publisher. Your own backend under your own credentials. Your own AI agent — Claude, Cursor, Codex and others — on the subscription you already pay for, so there are no credits and no per-token markup. Code export vs no-code lock-in lists the six things a builder can hold hostage; here, none of them are held. The Free plan covers 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.
Frequently asked questions
No. A wrapper runs your web app inside a native WebView. Web to native reads your repository and rebuilds the screens as native SwiftUI and Jetpack Compose apps that talk to the same backend; the result is a project that opens in Xcode and Android Studio, not a shell around a web page.
A GitHub repository of a React, Next.js, Vue or plain HTML web app. The import reads routes, data model, API calls and auth; it does not depend on which tool built the web app.
It rebuilds it. Web UI — components, CSS, browser APIs — has no native equivalent, so the screens are re-created for the phone from the plan you approve, using the platform’s own parts. Design tokens carry over as values; layouts are redone natively.
Yes. The native apps are clients of the API, database and auth provider your web app already uses. Users do not sign up again; with Supabase, the iPhone app uses Supabase’s own Swift client and the Android app the community-maintained Kotlin one.
Yes, from one project: each feature’s logic is written once and rendered in SwiftUI on iPhone and Jetpack Compose on Android. Building both platforms is a Pro feature; the Free plan covers one platform.
Nothing. It keeps running as the web product. The native apps are a separate project with their own release cycle; a change to the web app does not change the phone apps, and the reverse.
No. You connect the repository, read and approve the plan, and test features on a phone. The projects that come out are Swift and Kotlin an engineer can join later, and the plan is the document you would have handed them.
A Mac with Xcode, the GitHub repository, your backend credentials, and your own Apple Developer Program membership ($99 a year) and Google Play Console ($25 once) so the apps are published under your account.
Keep reading
- Convert an iOS app to Android
The same import, starting from an Xcode project.
Related
- Multiplatform Native Apps — Modaal DuetShared logic, no shared UI. iOS renders SwiftUI, Android renders Compose, and a test fails the build if the two ever disagree about what should be on screen.
- Human help — a real engineer when you need themYou build the native app with AI, and a real mobile engineer unblocks you when the agent cannot.