Cross-platform app builders in 2026: what each one actually ships

Sort the market by output and it falls into five kinds. The names matter less than the artefact you end up holding.

1. A web app in a shell. The builder produces a website; a wrapper (a PWA, or Capacitor for the stores) makes it installable. Lovable is the honest example: its FAQ says “Lovable does not generate React Native projects” and points to a PWA or a Capacitor wrapper for the stores. The Android and iPhone “apps” are the same web page. Native vs web app covers what that costs on the phone.

2. One JavaScript codebase driving native views — React Native. The screens are written once, in JavaScript, and rendered through platform components on both phones. This is what most cross-platform AI builders ship: Vibecode (“built using React Native and Expo”), Newly (“Built with React Native and Expo”), Bolt through its Expo integration (“build mobile apps for both iPhone and Android using the same code”), Adalo (“Our mobile builds use React Native”) and Bubble’s native mobile beta (its manual lists the iOS and Android versions “our current version of React Native will support”).

3. Flutter. A Dart codebase that draws its own interface on both platforms. FlutterFlow is the visual builder in this category; its generated project is a standard Flutter one — “the lib/ directory contains all the Dart code that drives your Flutter app.”

4. Two separate native apps. Swift and SwiftUI for iPhone, Kotlin and Jetpack Compose for Android, written as two projects. Rork moved here in 2026 — its docs now say “React Native is a cross-platform approach … Rork used to build apps this way and no longer does for new projects” and “Rork writes a real Android Studio project in Kotlin.” One Rork project can hold both apps, and “each app has its own code.”

5. One shared core, two native interfaces. Each feature’s logic is written once; each platform gets its own native screen. This is what Modaal builds with Duet, and it is the category the rest of this page spends the most time on, because it is the newest and the least understood. Whether it is right for you is a separate question, and one the page answers against ourselves where needed.

The first three kinds share the screens between platforms. The fourth shares nothing. The fifth shares the behaviour and not the screens. That sentence is the whole taxonomy.

React Native’s founding argument is the one every JavaScript team has heard: one team, one codebase, two stores. In 2026 it is still true, and the tools built on it are the most numerous, the most mature, and the easiest to hire for. If your product is a list of things with forms and a feed — most apps — and your developers already write React, a React Native builder will get you to both stores faster than anything on this page, and the code you export (Vibecode, Newly and Bolt all let you download the project) is a project a React developer can carry on.

The trade is structural, not a matter of quality. Because the screens are written once, they are the same screens on both phones. A settings page that follows Apple’s conventions on iPhone follows them on Android too, and vice versa; when you want the two to differ, you write the difference by hand, per platform, inside the shared code. And because the logic runs in JavaScript, everything the phone offers reaches your app through a bridge — first-party frameworks land in Swift and Kotlin at announcement, and reach React Native afterwards, through wrappers. Vibecode and Newly both write that their apps “compile to native iOS and Android code”; the accurate reading is that the views are native components and the logic is JavaScript executed on the device. Neither is a criticism. It is the deal, and it is a good deal for a lot of apps.

React Native vs native argues the decision at length; for iPhone-only projects, Swift vs React Native does. This page only needs the one-line version: if you want the two apps to be the same, share the screens. If you want them to be native, don’t.

Rork is the interesting mover of 2026. It built React Native apps, benchmarked its own agent, and concluded — in its own words — that the agent “writes better Swift apps”, so new projects are now native: Swift for iPhone, Kotlin for Android, React for web, each “with its own code” inside one project with one chat context.

What you get is real: an Xcode project and an Android Studio project, exportable on paid plans (“Paid users own all generated code. Download it via GitHub!”), each following its own platform’s conventions because each is written in that platform’s language. What you don’t get is any mechanism that keeps the two apps behaving the same. The iPhone app and the Android app are two implementations of your product, written by the same agent from the same conversation, and they stay in sync as long as you ask for every change twice and check both. For a small app that is fine. For an app with twenty features, business rules, and edge cases, “the Android version does something slightly different here” is not a bug you’ll notice in the chat window; you’ll notice it in a review.

This is the route to pick when you want native on both platforms and your product is simple enough that two implementations are cheaper than one shared core.

Modaal builds native apps with an architecture called Duet, and Duet makes the opposite trade from React Native. The docs put it in one sentence: “you write the views twice and the behavior once.”

Concretely: “each feature’s logic — its state, the actions that change it, the effects it requests — is written once.” That core is a pure function — no clocks, no network, no IDs inside it; anything nondeterministic goes out as an effect and comes back as an action. “The iPhone app renders that state in SwiftUI; the Android app renders it in Jetpack Compose.” So the iPhone screen follows Apple’s Human Interface Guidelines and the Android screen follows Material 3, because they are two native screens, written in the two native toolkits, by the same agent.

The part that makes this different from “two apps that happen to share a library” is how parity is proven. Each feature starts as a one-page spec — the states, the transitions, a row per ending — written as Given / When / Then scenarios. A tool compiles the scenarios into fixture files, and “both platforms replay the same fixtures and the gate is byte equality, so a divergence fails the build on the commit that caused it.” Fixtures are build products: never edited by hand, and where a fixture and the prose disagree, the fixture wins. When you want the platforms to differ — a share sheet on iPhone, a different affordance on Android — the divergence is recorded as a decision, not left as an accident.

Two practical consequences. You don’t have to decide about Android on day one: the new-project wizard offers “iPhone and Android together” and “iPhone now, Android later”, and the second records every feature exactly as the first would, so adding Android later is per-feature work in the same repository, not a rewrite. And the output is ordinary: an Xcode project and an Android Studio project on your Mac, in Swift and Kotlin, that any platform developer can open — there is no Modaal runtime in the app.

The honest limits, from the same docs page: you write the views twice, so a screen costs two implementations; “you still need a Mac”, because iOS builds run through Xcode; building both platforms is a Pro feature (the free plan builds one); games start from a different template; and Duet itself is pre-release — the framework is open on GitHub, but no packaged artifacts are published yet. Modaal is free for one project with unlimited prompts on one platform; Pro is €9 per user per month billed annually (€15 monthly) and unlocks both platforms — details on the pricing page. For the full mechanism, read the Duet framework overview; for where it sits against Flutter, React Native and Compose Multiplatform, the framework comparison.

Put these to every tool before you put your product into it. Every answer on this page came from asking them of the vendor’s documentation.

1. What is the Android app, physically? A web page, a JavaScript bundle inside a native shell, a Dart app, or a Kotlin project. The answer to everything else follows from this one.

2. Is Android a second project or the same one? Same code (React Native, Flutter, web shell); separate code in one project (Rork); one shared core, two shells (Modaal). Each has a different cost curve as the app grows.

3. Can a platform developer open it? An Android developer can open a Kotlin project in Android Studio and a React developer can open an Expo project; neither can do much with a Bubble app, which “can only be run on the Bubble platform.”

4. On which plan is the code yours? Vibecode, Newly, Bolt and Superapp say export is available; Rork says paid plans; FlutterFlow lists code download from its Basic plan; Bubble says never; Adalo does not offer it as of September 2026. The export table has the plan-by-plan detail for nineteen tools.

5. What happens on the day Apple or Google ships a new API? First-party stacks get it at announcement. Everything else gets it when a wrapper does.

6. Who keeps the two apps behaving the same? You, by testing both (separate native apps); nobody, because they are the same code (shared screens); or the build (shared core with recorded fixtures).

If a vendor page can’t answer one of these in a sentence, that is also an answer.

Sometimes the right number of platforms is one. If your users are on iPhone and your team is small, an iPhone-only native app with a real Swift codebase — Superapp, or Modaal’s “iPhone now, Android later” template — beats a mediocre app on two stores, and you keep the option to add Android when the numbers say so. Games should not be cross-platform-by-framework at all; they start from a game template and share art, not architecture. And if the “app” is really a website people should be able to open from a link, a well-made web app is the honest product and no wrapper improves it.

Whether sharing code between the platforms is right for your app is a real question with two defensible answers, and our documentation argues both sides before recommending anything. Read that before you read any vendor page, including ours.

Sorted by what you want to end up holding.

Your team writes React, and one codebase for both stores is the point → a React Native builder. Vibecode and Newly are mobile-first and both export the Expo project; Bolt reaches the same place through Expo if you say “mobile app” in the first prompt. Bubble’s native mobile is the same category in public beta, without export.

You want a visual builder and Flutter is your stack → FlutterFlow. Real Dart project; code download from the Basic plan.

You want native Swift and Kotlin on both stores and your app is simple → Rork. Two native projects, one chat, parity by your own testing.

You want native on both stores and the app will grow → Modaal. One shared core per feature, SwiftUI and Compose screens, parity enforced by the build, Xcode and Android Studio projects on your Mac. Needs a Mac; both platforms need Pro.

You only want an iPhone app, today → Superapp (Swift, browser or Mac version, export on any plan) or Modaal’s iPhone-only template — compared in how to make an iPhone app.

You are choosing by criteria rather than by name → how to choose an AI mobile app builder, and the alternatives pages for one-to-one comparisons. And if the question is not which builder but how the build actually goes from one project to two native apps, that is the companion guide.