Pick a cross-platform stack in November 2026 and you are choosing between three different bets. Kotlin Multiplatform shares Kotlin code and keeps the native platform underneath. Flutter draws every pixel itself. React Native maps JavaScript components onto real native views. JetBrains lists Compose Multiplatform 1.12.2 as the current release on its compatibility and versions page, with support for Android, iOS, macOS, Windows, Linux and WebAssembly-capable browsers, so the old “Kotlin is Android-only” objection no longer holds.

This comparison uses only what shipped and was documented by early November 2026. That means Kotlin 2.4.21 (October 8), Flutter 3.47 with its 3.47.8 security patch, and React Native 0.88 (October 19). We also flag three releases that are scheduled but not out: Kotlin 2.5.0, Flutter 3.50 and React Native 0.89. Where the public record has no neutral three-way benchmark, we say so and give you a protocol to run your own.

If you only care about the two UI-first options, our earlier React Native vs Flutter breakdown covers that duel directly. This piece asks a different question: should a team share logic only, share logic and UI, or share nothing but a design system? The answer depends more on your team than on any benchmark.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

Kotlin Multiplatform vs Flutter vs React Native at a glance

The table below compresses the three stacks into 14 rows. Version numbers and dates come from each project’s own documentation as of November 4, 2026. Anything that was not confirmed on an official page is described in words rather than numbers.

Two lines deserve a second look. First, shared UI is optional on the Kotlin side, which is the whole point of KMP. Second, the next-release row matters because all three stacks have a milestone landing within roughly 30 days. If you are about to start a project, you can pin today’s stable versions and plan a first upgrade for December.

What each stack actually shares: logic, UI, or both

The cleanest way to separate these stacks is to ask what crosses the platform boundary. With Kotlin Multiplatform, the unit of sharing is a Kotlin module. You can share networking, persistence, validation and business rules and leave the screens to SwiftUI on iOS and Jetpack Compose on Android. JetBrains positions it exactly that way: native-platform integration with selective code sharing, plus Compose Multiplatform when a team also wants shared UI.

Flutter flips the default. You write the UI once in Dart, and Flutter’s renderer paints it identically on every target. Business logic lives in the same codebase, so there is no seam between shared and native unless you add one through platform channels. That uniformity is Flutter’s biggest selling point and its biggest constraint.

React Native sits between the two. You write components in TypeScript, and the framework renders real platform views. The logic is shared, the UI description is shared, but the pixels on screen come from UIKit and Android’s view system. That is why native-looking controls come cheap in React Native and why custom, brand-heavy visuals cost more than they do in Flutter.

Sharing depth, ranked

Measured by how much code can cross the boundary, Flutter shares the most by default, React Native shares most of it, and Kotlin Multiplatform shares whatever you choose. Measured by how much native behavior you keep without extra work, the order reverses. Neither axis is better. They answer different questions, and a banking app with strict accessibility and platform-convention requirements asks a different one than a content app with a custom visual identity.

// Kotlin Multiplatform: the platform difference is declared, then implemented per target // commonMain expect fun platformName(): String class Greeter { fun greet(): String = "Hello from " + platformName() } // androidMain actual fun platformName(): String = "Android" // iosMain actual fun platformName(): String = "iOS"

That expect and actual pattern is the heart of KMP. The shared class compiles once, and each platform supplies its own piece. Flutter and React Native have no equivalent seam in the language itself. They reach the platform through plugins, platform channels or native modules, which add a bridge to design, version and test.

Where Kotlin’s language story helps

Teams that already run Kotlin on Android and the server get the biggest dividend. The same language, the same coroutines and the same Gradle builds cover the shared module, the Android app and the backend. If you are weighing that language choice on its own, our Kotlin vs Java comparison covers build speed and salary data in detail.

UI fidelity and accessibility

Native UI inherits the operating system’s accessibility behavior, including screen reader semantics, dynamic type and system gestures. Compose Multiplatform has been narrowing that gap on iOS. The 1.11.1 release notes describe native text input behavior, with native caret movement, selection, gestures and system context menus, and the 1.13.0-beta01 notes add password saving and autofill on iOS. Flutter takes the other route and implements accessibility through its own semantics layer on top of the renderer. React Native gets most platform behavior for free because it renders native controls.

For regulated products, such as banking, health and public-sector apps, we would test each candidate with VoiceOver and TalkBack on day one of a pilot. A framework can be excellent on paper and still fail an accessibility review because of one custom control. The cost of finding that out in week two is small. The cost of finding it out before launch is not.

Current versions and what changed in the last three months

All three projects moved between August and early November 2026. The table lists the release that a new project should pin today, with its date and the headline change.

Kotlin 2.5.0-Beta2 is out as a prerelease, and the official Kotlin release page plans 2.5.0 for December 2026 and 2.5.20 for March 2027. Treat the beta as a preview. It reportedly adds a Node.js provisioning toolchain, an npm-dependency DSL and a new Swift export DSL, which would replace the legacy swiftExport block with export.swift. Those details come from a single source and could change before the final build.

Flutter 3.50 is the one to watch. Google’s release schedule targets November 2026, with the branch cut on October 6. A tracking issue exists, but no official announcement had confirmed a stable 3.50 by November 4, so this article treats it as upcoming. React Native 0.89 is likewise unreleased, with an early-December date reported on the project’s release schedule.

One more version detail helps with planning. From Kotlin 2.4.0, the Kotlin standard library for the JVM carries an 18-month support window for each release line, and a bug-fix release lands only for the latest tooling release. In practice that means KMP teams should expect to move forward roughly every few months, while React Native 0.88 already marks 0.85.x as unsupported. Every stack here rewards teams that upgrade on a schedule.

Performance and startup: what the evidence supports

Here is the uncomfortable truth about cross-platform benchmarks in 2026. No vendor-neutral, three-way benchmark with current versions of all three stacks was available when we checked. Most public numbers compare two stacks, use older releases, or measure toy apps. Rather than paste figures that do not hold up, this section lists the evidence that does exist and what each piece can and cannot tell you.

That is three independent project sources plus a tooling reference, and none of them settles the question of which stack is fastest. The JetBrains numbers are the only hard startup figures, and they apply to desktop Compose rather than to a phone. They also come from the vendor, so read them as a signal about direction rather than proof of a win over Flutter or React Native.

Run the benchmark on your own screens

A fair test builds the same three screens in each stack: a long scrolling list with images, a form with validation, and a screen with a custom animation. Run release builds on one mid-range Android phone and one older iPhone. Capture cold start, frame time during the scroll, and peak memory. The commands below cover the Android side using standard Android tooling.

# Cold start time, release build installed adb shell am force-stop com.example.bench adb shell am start -W -n com.example.bench/.MainActivity | grep -E "TotalTime|WaitTime" # Frame stats after scrolling the list for 30 seconds adb shell dumpsys gfxinfo com.example.bench reset # ...scroll the list by hand or with a UI script... adb shell dumpsys gfxinfo com.example.bench | grep -E "Janky frames|90th|95th|99th" # Memory snapshot while the list is on screen adb shell dumpsys meminfo com.example.bench | grep -E "TOTAL PSS|Native Heap|Java Heap"

Log the median of at least five runs per stack, and keep the device at the same temperature and battery level. On iOS, use Instruments with the Time Profiler and Core Animation templates. Record the exact versions in your report, because a result from Flutter 3.47.8 means little when compared against a React Native release from a year earlier.

Pay special attention to the first launch after install. Frameworks that ship their own runtime or renderer often show a larger gap on the first run than on later ones, and your users meet the first run exactly once per install. Also test on a low-end device. A framework that feels instant on a flagship phone can drop frames on the hardware your customers actually carry.

iOS, Android, web and desktop support compared

Mobile parity is close, and the real differences sit on the edges. On Android, all three are first-class, and Kotlin Multiplatform has the shortest path because Android is already Kotlin. On iOS, the Compose Multiplatform 1.11.1 notes record that Apple x86_64 targets were dropped and the minimum iOS version rose from 13 to 14, according to a single source we could confirm.

Flutter 3.47 prepared its pipelines for iOS, macOS and Xcode 27. React Native 0.88 added SceneDelegate lifecycle support on iOS as an additive change, so the older AppDelegate path keeps working. Support is limited to a single scene for now, and the project tells teams to keep UIApplicationSupportsMultipleScenes set to false.

Desktop and web are where the stacks diverge

For desktop, Flutter and Compose Multiplatform both ship credible stories. Flutter 3.47 made Impeller the default renderer on macOS, Windows and Linux. Compose Multiplatform lists the same three desktop operating systems and is working on startup through AppCDS and ahead-of-time improvements. React Native’s 0.88 announcement does not center on desktop at all, so a desktop-first product should weigh that gap. If your target is a desktop-only utility, a webview-based shell is a different category, and our Tauri vs Electron comparison covers that route.

On the web, Compose Multiplatform for WebAssembly was still described as Beta at the start of October, with no confirmed stable date. Flutter has a web target, though Flutter 3.50 changes involving viewport-fit and SafeArea handling are listed as pending. React Native moved toward the web by making W3C EventTarget-style event dispatching the default in 0.88, which narrows the gap between native and web event semantics. Teams that need an SEO-driven public website should still build that in a web framework and use these stacks for the app.

Developer experience, tooling and the new Kotlin Toolchain

Tooling is where Kotlin Multiplatform historically cost teams the most time, and it is also where JetBrains made its biggest recent move. In October 2026 the company published guidance recommending Kotlin Toolchain 0.13 as the starting point for most new KMP projects. The post on starting a KMP app with Toolchain 0.13 says the IDE integration needs IntelliJ IDEA 2026.2.3 or Android Studio Rabbit 1 | 2026.2.1 or newer, plus the latest Kotlin Toolchain plugin. Version 0.12 had already added multiplatform library publishing, a Wasm app preview and Compose Hot Reload from the command line.

Gradle remains the build backbone for Kotlin projects, so build-tool fluency pays off. If your team is unsure whether to stay on Gradle or move, the Gradle vs Maven comparison is a useful companion read. Expect a steeper first week with KMP than with the other two, mostly because a project mixes Gradle, Xcode and an IDE plugin.

Flutter’s toolchain is the most self-contained of the three. One SDK, one CLI, and DevTools, which reached version 2.61.0 on October 20, 2026 according to the DevTools 2.61.0 release notes. Widget Previews graduated to stable in Flutter 3.47, which lets designers and developers render individual widgets without launching the full app. The Flutter team also published Genkit Dart 1.0 on October 8, 2026, a stable framework for AI-powered features and agentic workflows in Dart and Flutter.

React Native’s day-to-day experience depends on Metro, which moved to version 0.87 in 0.88, and on Expo for many teams. The 0.88 post says the release will be available in the Expo SDK 58 releases. Upgrades have become calmer, too. The project calls 0.88 the third release with no user-facing breaking changes after 0.83 and 0.86. If you are starting from zero, our React Native tutorial walks through setup to store submission.

Testing and CI

Whatever you choose, plan CI around the Apple toolchain. Every stack needs a macOS runner to produce an iOS build, and Xcode version drift is a repeat source of breakage. Both Compose Multiplatform and Flutter documentation reference Xcode 27 readiness this autumn, so pin your Xcode version in CI and upgrade it on purpose, never by accident.

For shared Kotlin code, write tests in the common source set so they run on every target. For Flutter, widget tests run fast without a device. For React Native, component tests run in Node and device tests run through your preferred end-to-end tool. The common thread is a small, fast unit-test layer plus a thin layer of real-device smoke tests before each release.

Cost and pricing: what you actually pay for

None of the three charges a license fee. Current official sources list no price for Kotlin Multiplatform or Compose Multiplatform, and React Native is open source with no paid framework product. The money goes elsewhere, and the table below separates the real cost drivers.

The Shorebird figures come from a third-party service and say nothing about Flutter’s own pricing. We include them because over-the-air code push is a real line item for teams that cannot wait on app-store review for a hotfix. For a very small startup, headcount dwarfs every row in this table. For a large organization, the hiring pool row matters most, because it drives recruiting time and salary pressure for years.

Real-world examples and what they signal

The public record gives us four concrete signals, and we add five team profiles that show how the choice plays out. The profiles are composites for illustration, not named customers, so treat them as decision aids.

Four signals from the projects themselves

Google’s ADK for Kotlin 1.0. Google announced general availability on September 9, 2026, and the ADK for Kotlin 1.0 announcement says it uses a Kotlin Multiplatform core with Android-first and server-side support. A Google agent toolkit built on KMP is a strong endorsement of the shared-logic model.

JetBrains’ Ship Kotlin Everywhere Award. JetBrains reportedly said in October 2026 that three KMP apps won its 2026 award. It is ecosystem promotion with no adoption figures, so we read it as a pulse check, not data.

React Native on Meta Quest. The React Native blog announced in February 2026 that the framework comes to Meta Quest. That pushes the model beyond phones and into headsets.

Flutter’s desktop and agent push. Flutter 3.47 made Impeller the desktop default, and Genkit Dart 1.0 targets agentic apps. A Flutter blog post from October 20 pitches the framework for mobile, web, desktop, automotive displays and embedded kiosks.

Five team profiles

The Android-first fintech. A team with a mature Kotlin Android app and a Kotlin server wants an iOS version. Sharing the domain and networking layers in KMP, then building SwiftUI screens, protects their platform-convention requirements and reuses the language skills they already pay for.

The design-led consumer startup. A handful of engineers, one brand-heavy visual identity and a tight launch window. Flutter’s single renderer keeps animation and layout identical on both phones, so QA tests one UI instead of two.

The web company adding an app. A React team ships a dashboard on the web and needs a mobile companion. React Native lets them reuse TypeScript types, API clients and mental models, and Expo handles much of the build pipeline.

The enterprise with legacy native apps. Two aging native apps, two teams, drift between features. KMP lets them move one module at a time into shared Kotlin without a rewrite, which a full Flutter rewrite cannot offer.

The internal-tools shop. A small group builds mobile and desktop utilities for staff. Flutter or Compose Multiplatform covers desktop and mobile from one codebase, which React Native handles less naturally for desktop.

Notice the pattern across all nine examples. The deciding factor is rarely raw speed. It is the shape of the existing team, the existing code and the platforms on the roadmap. That is why a framework ranked third on a feature chart can still be the right pick for your company.

Language, hiring and team fit

Technology choices are really staffing choices. A framework that your current engineers already half-know will ship faster than a better one that requires retraining. JavaScript and TypeScript are the default skills of web teams, which is why React Native tends to win at companies that started on the web. Our React, Vue and Svelte comparison shows how deep that frontend skill pool runs.

Kotlin skills concentrate in Android and backend teams. That makes KMP attractive for organizations with a strong Android group, and awkward for ones whose mobile developers are all Swift specialists. Flutter asks everyone to learn Dart, a language that few engineers bring with them but that most pick up quickly because it reads like a blend of Java and TypeScript.

We deliberately avoid quoting job-posting counts or salary averages here. The research we pulled for this piece did not surface a current, sourced dataset for all three stacks, and stale figures would mislead more than they help. Check your own regional job boards and your recruiter’s pipeline before you lean on a hiring-pool argument.

Pros and cons of each stack

The Flutter deprecation point is easy to misread. Material and Cupertino became standalone packages at version 1.0 on August 12, 2026, and the original in-framework libraries remain available in 3.47 but are scheduled for formal deprecation in the fall release. New projects should depend on the standalone packages from day one.

Use-case recommendations: which stack for which job

The recommendations below follow the team profiles above. Match your situation to the closest one rather than to the tool you like most.

You already ship a Kotlin Android app. Choose Kotlin Multiplatform. Extract the shared domain layer first, keep native UI on both platforms, and adopt Compose Multiplatform for iOS screens only after a pilot feature.

You need pixel-identical UI on every device. Choose Flutter. One renderer removes cross-platform visual drift, and 3.47’s desktop Impeller default helps if you also target laptops.

Your team is a React or TypeScript shop. Choose React Native with Expo. Reuse types and API clients, and plan to pin 0.88 once Expo SDK 58 is available for your project.

You are modernizing two native apps. Choose Kotlin Multiplatform. Incremental module sharing is the lowest-risk migration path, and you never freeze feature work for a rewrite.

You need mobile and desktop from one team. Choose Flutter or Compose Multiplatform. Both document macOS, Windows and Linux, and React Native’s current release does not emphasize desktop.

You are building AI-agent features on device. Look at KMP with ADK for Kotlin 1.0 if you are Android-first, or Flutter with Genkit Dart 1.0 if you are Dart-first. Both ecosystems shipped stable agent frameworks this fall.

For a longer treatment of the two UI-first options, including adoption trends, see our earlier Flutter vs React Native comparison. If you choose Flutter after reading this, the Flutter production tutorial gets a first app running in 13 steps.

Migration guide: moving an existing app

Most teams do not start from a blank repository. These steps cover the most common move, from a native Android and iOS pair to Kotlin Multiplatform, followed by notes for the other two directions.

Native apps to Kotlin Multiplatform

Update your IDE to IntelliJ IDEA 2026.2.3 or Android Studio Rabbit 1 | 2026.2.1 or newer, and install the Kotlin Toolchain plugin.

Pin Kotlin 2.4.21 in your Gradle build. Do not adopt the 2.5.0 beta in production.

Pick one low-risk module, such as a date formatter or API client, and move it into a shared module.

Expose the shared module to iOS and confirm it builds in Xcode on a real device.

Add tests that run on both targets, then repeat for the next module.

Decide on UI sharing late. Prototype one screen in Compose Multiplatform before committing.

// build.gradle.kts (shared module) plugins { kotlin("multiplatform") version "2.4.21" } kotlin { androidTarget() iosArm64() iosSimulatorArm64() sourceSets { commonMain.dependencies { // shared networking, storage and domain code goes here } } }

React Native to Flutter, or the reverse

Both directions are rewrites of the UI layer, so migrate by feature rather than all at once. Embed the new stack in the existing app as a module for one screen, ship it, and measure crash rates before you move the next screen. Keep the backend contract stable so both clients can run side by side. Budget extra time for state management, because the idioms differ more than the syntax does.

Upgrade hygiene for the next 30 days

If you run React Native 0.85 or earlier, note that 0.85.x became unsupported when 0.88 shipped, so plan the upgrade. The 0.88 post says that if you are on 0.87 you should be able to move up without app code changes. Flutter teams on 3.47 should take the 3.47.8 patch for the CA-key security fix, then evaluate 3.50 only after Google confirms the release.

Whichever path you take, write down a rollback plan before the first production release of the new stack. Keep the old app store listing build reproducible, keep feature flags for the migrated screens, and watch crash-free session rates for at least two release cycles. Teams that skip this step tend to discover their problems from one-star reviews instead of dashboards.

Risks and what could change next

Each stack carries a visible risk in the coming quarter. For Kotlin Multiplatform, it is the cadence of change. Kotlin 2.5.0 is planned for December, and the beta already points to a new Swift export DSL, an experimental KMP compilation scheme and a smaller library publication format. Those are improvements, but they also mean build scripts will move. Pin versions and read the changelog before upgrading.

For Flutter, the risk is the planned deprecation of the in-framework design libraries and the pending 3.50 changes. Stricter Android Intent verification is listed as targeting 3.50 and could surface in apps that rely on implicit intents. It is the kind of change that shows up in a CI run, not a product launch.

For React Native, the headline item is Swift Package Manager support. React Native 0.87 added experimental Swift Package Manager support, and 0.88 is now the latest stable release. If your app relies on libraries that have not adopted SwiftPM, test that path early. None of the three has announced a next-generation successor in the sources we checked. Kotlin 2.5.0 is planned for December 2026, Flutter 3.50 is targeted for November 2026, and Compose Multiplatform 1.13.0 is still in beta, so none of them is a confirmed stable release yet. For broader context on developer tooling choices, browse our software coverage.

Verdict: which one should you pick?

There is no single winner, but there is a clear decision rule. Choose by the skills you already pay for, then by how native your UI must feel, then by how many platforms you need.

Our overall take: for greenfield consumer apps with a web-heavy team, React Native 0.88 is the lowest-risk start. For teams with Android depth or strict native requirements, Kotlin Multiplatform is the strongest long-term bet, and its backing from both JetBrains and Google’s ADK for Kotlin work is the best sign yet. Flutter wins when one consistent UI across several targets is the actual requirement. If your team cannot say which of those describes it, run the three-screen benchmark above for two weeks before you commit.

Frequently asked questions

Is Kotlin Multiplatform stable in 2026?

Yes. JetBrains promoted Kotlin Multiplatform to stable in November 2023. Compose Multiplatform, the optional shared UI toolkit, is documented as stable for Android, iOS and desktop, while its WebAssembly web target was still in Beta in early October 2026.

What is the latest version of each framework?

As of November 4, 2026: Kotlin 2.4.21 with Compose Multiplatform 1.12.2, Flutter 3.47 (security patch 3.47.8), and React Native 0.88. Kotlin 2.5.0, Flutter 3.50 and React Native 0.89 are scheduled but were not confirmed as released.

Can Kotlin Multiplatform replace Flutter or React Native?

It can replace either when your team prefers Kotlin, but it solves a different problem. KMP shares logic and lets you keep native UI, while Flutter and React Native are UI-first. With Compose Multiplatform you can share UI too, which makes KMP a direct alternative for Kotlin-first teams.

Which framework is fastest?

No neutral three-way benchmark on current versions was available when we checked, so we do not name a winner. JetBrains reports desktop startup gains for Compose, but those are vendor figures on two machines. Run the three-screen test in this article on your target devices.

Do these frameworks cost money?

No framework license fee appears in the current official sources for any of the three. Real costs come from engineers, Mac build hardware, CI and optional services such as third-party over-the-air patching, where one service lists $0, $20 and $400 plans.

Should I migrate a working app?

Only if you have a concrete problem, such as duplicated logic across two native apps or a team that cannot keep two codebases in sync. Migrate one module or one screen at a time and measure crash rates after each step.

Is Flutter’s Material library being removed?

The original in-framework Material and Cupertino libraries remain in Flutter 3.47 but are slated for formal deprecation in the fall release. Standalone material_ui and cupertino_ui packages reached version 1.0 on August 12, 2026, so new projects should use those.