Guide · framework and vendor claims quoted from their own sites, 10 Sep 2026

    React Native alternatives in 2026 — sorted by why you are leaving

    Most “React Native alternatives” lists rank frameworks by GitHub stars. That is useless, because the right alternative depends entirely on why you are looking: native feel, a team that does not write JavaScript, code you can open without a vendor, or the cost of two platforms. This page sorts the six real options by that reason — including the one that did not exist two years ago.

    Verified

    First, the case for not leaving. If your engineers write JavaScript and the app is a list-and-form product that ships weekly to both stores, React Native is still the pragmatic answer, and the vibe-coding builders that sit on it — Vibecode (“built using React Native and Expo, which compile to native iOS and Android code”), Newly, Bolt with Expo — are the most numerous and the easiest to hire around. The React Native vs native guide makes that case properly. This page assumes you have read it and still want out, and asks the only useful question: out to where, and why?

    There are four reasons people search for this. Each one has a different best answer.

    Reason 1: you want the app to feel like the phone — native UI, day-one platform features

    This is the most common reason and the one the star-count listicles get most wrong, because the two frameworks they rank first — Flutter and Compose Multiplatform — do not give you native UI either. They give you a different shared UI.

    Flutter says so itself: it “has its own implementations of each UI control, rather than deferring to those provided by the system,” drawn by its own renderer, which is “shipped along with the application.” That is a fine design for an interface that should look the same everywhere; it is not a route to platform-native controls. (Flutter in depth, including how to vibe-code it: Vibe coding Flutter.)

    Compose Multiplatform, from JetBrains, is “an open-source, declarative framework for sharing stunning UIs across multiple platforms,” powered by Kotlin Multiplatform and Jetpack Compose, with iOS marked Stable on its site. It is the natural move for an Android team — “Use your Jetpack Compose skills across platforms” — and on iOS it draws Compose UI, not SwiftUI. Same shape of trade as Flutter, different language.

    If native UI is the reason, the alternatives that actually deliver it are the two native routes further down: two separate native apps (Swift and SwiftUI, Kotlin and Jetpack Compose) or one shared core with a native interface per platform. Both put Apple’s and Google’s own controls on screen and get new platform features the day they ship, because those stacks are what the announcement is written in. Until recently both also meant two teams. That is the part that changed.

    Reason 2: your team does not write JavaScript

    Then the alternative is whichever stack your team already writes.

    Kotlin team → Kotlin Multiplatform and Compose Multiplatform. Shared Kotlin logic on both platforms, and either Compose UI on iOS as well (Compose Multiplatform) or a SwiftUI interface on top of the shared Kotlin core. The second variant is worth knowing about because it is also how the shared-core route below works.

    Web team that is not a React Native team → Capacitor. Ionic’s Capacitor is “an open source native runtime for building Web Native apps. Create cross-platform iOS, Android, and Progressive Web Apps with JavaScript, HTML, and CSS.” Your web app runs in a native shell with a bridge to device APIs. It is the honest way to get a Lovable- or v0-built web app into the stores; it is not a way to get native UI. Ionic Framework and NativeScript live in the same neighbourhood for web teams; .NET MAUI is the equivalent for .NET teams. None of these is a wrong answer for the team it fits, and none of them changes the native-UI question.

    Swift or Kotlin team → native, obviously, and the only interesting question is whether the other platform costs a second team. See Reason 4.

    No engineering team at all → an AI builder, in which case the question is not the framework but what the builder ships and on which plan the code is yours. That is a different page: cross-platform app builders sorted by output.

    Reason 3: you want code you can open without the vendor

    If the real complaint is “my app lives inside a builder”, the framework matters less than the export terms, and here the market moved in 2026.

    The clearest signal is Rork, which was a React Native builder and says in its own docs: “React Native is a cross-platform approach: one JavaScript codebase that renders native UI on both iOS and Android. Rork used to build apps this way and no longer does for new projects.” It now writes “a real Android Studio project in Kotlin” alongside a Swift app, “each app has its own code,” and on export: “Paid users own all generated code. Download it via GitHub!” Rork gives its own reason — “Internal benchmarks showed the agent writes better Swift apps, so we switched” — which is Rork’s claim, not ours; we have measured nothing. The move itself is the fact.

    The native-output builders are the ones whose export is a project a stranger can open on Monday: Bitrig (real Swift, full Xcode projects, bring your own agent), Nativeline (actual SwiftUI from a macOS app) and Superapp (native Swift with in-product submission) on the Apple side; Google AI Studio (a Kotlin and Jetpack Compose project, free) on the Android side; Rork and Modaal on both. Every one of those produces a language Apple or Google publishes, opened by a tool Apple or Google ships. The code-export guide has the plan-by-plan detail for nineteen tools, quoted from each vendor.

    The test to apply to any alternative, framework or builder: can I open the project without you? If the answer needs the vendor’s runtime, cloud, or subscription, you have changed landlords, not left.

    Reason 4: you chose React Native for the cost, and the cost is gone

    React Native’s founding argument was economic: one team, one codebase, two stores. Every alternative on the star lists — Flutter, Compose Multiplatform, Capacitor — keeps that argument and changes only the language. They are React Native alternatives in the sense that they are other ways to avoid paying for two platforms.

    The alternative that did not exist two years ago drops the premise. When an AI agent writes the code, you are no longer paying two salaries for two native apps; you are paying one subscription and reviewing two plans. So the question becomes: can two native apps be kept the same without a shared UI?

    Two separate native apps, one agent. Rork’s route, and what any engineer with Claude Code or Codex can do by hand: a Swift project and a Kotlin project, written by the same agent from the same description. You get native UI on both sides and real projects on disk. What you do not get is a guarantee that the two apps behave the same; that is discipline, review, and tests you write twice.

    One shared core, two native interfaces. Modaal Duet is this route. Each feature’s logic is written once and both apps run it. The interface is written twice, natively — real SwiftUI on iPhone, real Jetpack Compose on Android — so an iOS sheet is an iOS sheet and an Android bottom sheet is an Android bottom sheet. Parity is proven rather than promised: recorded scenarios are replayed on both platforms in the build and the resulting state has to match byte for byte, or the build fails. Where the platforms should differ on purpose, the difference goes into a ledger a person reviews. When we moved our own app, Memory Lane, to Android this way, zero logic files changed and the ledger had six entries. You bring your own agent — Claude, Codex, Cursor and ten more — and the projects are real Xcode and Android Studio projects on your Mac from the first build. Free plan: one project, unlimited prompts, one platform; both platforms on Pro at €9 per user per month, billed annually (pricing).

    Against React Native specifically: same economy (one description, both stores), the platform’s own controls instead of a bridge, and an exit that is two ordinary native projects instead of one JavaScript app you have to rewrite twice to leave. Against Flutter and Compose Multiplatform: the same difference, plus no second UI toolkit to learn.

    The six options on one line each

    Stay on React Native if your team writes JavaScript and the app is a list-and-form product. Flutter if you want one identical interface everywhere, or desktop targets. Compose Multiplatform if you are an Android team that wants Kotlin on iOS too. Capacitor if you have a web app and need it in the stores this month. Two native apps with your own agent if you want native UI and are happy to keep two projects aligned by hand. One shared core, two native apps (Modaal) if you want native UI, both stores, one description, and the build to prove the two apps agree.

    Then apply the one test that survives every framework war: open the project without the vendor. If you can, it is yours.

    React Native alternatives by what is shared, what draws the screen, and what you own

    OptionWhat is sharedWho draws the pixelsWhat you ownLeave RN for this when…
    React Native (stay)Screens + logic, in JavaScriptPlatform components, driven through a JS bridgeA JS project (+ Expo)Your team is JS and the app is lists and forms
    FlutterScreens + logic, in DartFlutter’s own renderer (Impeller), its own controlsA Dart projectYou want one identical UI everywhere, or desktop
    Compose MultiplatformScreens + logic, in KotlinCompose, on iOS as well as AndroidA Kotlin Multiplatform projectYou are an Android team
    CapacitorEverything — it is your web appA web view in a native shellA web projectYou have a web app and need the stores now
    Two native apps + your agentNothing (kept alike by discipline)SwiftUI on iOS, Compose on AndroidTwo native projectsYou want native UI and accept two projects to align
    Modaal (shared core)Logic only, proven equal by the buildSwiftUI on iOS, Compose on AndroidXcode + Android Studio projects on your MacYou want native UI, both stores, one description

    Framework descriptions from each framework’s own documentation, read 10 September 2026. No performance claims — the differences are structural.

    Frequently asked questions

    It depends on why you are leaving. For an identical interface on every platform, Flutter. For an Android team, Compose Multiplatform. For a web app that needs the stores, Capacitor. For native UI on both platforms without two teams, two native apps written by an AI agent — either as separate projects, or as one shared core with a native SwiftUI and a native Compose interface, which is what Modaal builds. Star counts do not answer the question; your reason does.

    Flutter compiles to a native binary but draws its own interface: its documentation says it “has its own implementations of each UI control, rather than deferring to those provided by the system.” So it replaces React Native’s bridge with a different shared UI, not with platform controls. If native UI is your reason for leaving, Flutter does not deliver it; native Swift and Kotlin do.

    Not one codebase for the screens — native UI means SwiftUI on iOS and Jetpack Compose on Android, written separately. What you can share is the logic. Kotlin Multiplatform does this for Kotlin teams; Modaal Duet does it with an AI agent writing both interfaces, and proves the two apps behave the same by replaying recorded scenarios on both platforms in the build.

    Rork’s own docs say: “React Native is a cross-platform approach: one JavaScript codebase that renders native UI on both iOS and Android. Rork used to build apps this way and no longer does for new projects,” and give the reason as “Internal benchmarks showed the agent writes better Swift apps, so we switched.” That is Rork’s claim about its own agent; we have not measured it. Rork now writes separate Swift and Kotlin apps.

    In 2026, no. The reason React Native and its alternatives exist is that native used to mean two teams. With an AI agent writing the code, the second platform is a second plan to review rather than a second salary. The remaining question is how you keep two native apps behaving the same — by discipline, or by a shared core the build checks.

    For the goal React Native serves — both stores from one description — yes. Modaal builds two native apps, Swift and SwiftUI for iPhone and Kotlin and Jetpack Compose for Android, from one project and one shared core, with no JavaScript bridge and no cross-platform runtime. Free plan on one platform; both platforms on Pro.

    Start free. Ship native.

    One project, unlimited prompts. No card.

    Download for Mac

    Keep reading