Kotlin Multiplatform vs Flutter is mostly a question about what you want to share. Kotlin Multiplatform (KMP) shares logic and leaves the UI native by default, with Compose Multiplatform as an opt-in for shared UI. Flutter shares both UI and logic, in Dart. React Native shares JavaScript or TypeScript and renders real native components. Pick by the team you have and the apps you already ship, not by benchmark tables. This page is part of HighCircl's series on Hire developers by tech stack: rates, vetting and interview guides.
What each option actually shares
JetBrains' KMP-versus-Flutter page says you can share whichever part of your codebase you want, "from 1% to 100%". The same page quotes Flutter's pitch as "100% code sharing across all platforms." One is a dial, the other is a default.
That's why code-sharing percentages across the web contradict each other. Third-party KMP code-sharing figures disagree, and the JetBrains range is simply "from 1% to 100%". A team that shares only networking, storage and business rules lands low. A team that adds Compose Multiplatform for the screens lands high. The number tells you about the architecture someone chose, not about the technology. Treat any "KMP shares 70%" claim without a stated scope as noise.
Flutter's sharing is fixed by design: one Dart codebase, one UI layer, and Flutter renders its own widgets. React Native sits between the two. You write React primitives that render to native platform UI, so View, Text and Image map to native building blocks, but the code is JavaScript or TypeScript and the UI is shared across iOS and Android by default.
Kotlin Multiplatform vs Flutter vs React Native: comparison table
| Technology | Language | UI approach | Code sharing | Native code access | Web and desktop |
|---|---|---|---|---|---|
| Kotlin Multiplatform (native UI) | Kotlin | SwiftUI or UIKit on iOS, Compose or Views on Android | Logic only, by choice | expect/actual declarations | Kotlin/JS web is Stable, Wasm is Beta |
| Kotlin Multiplatform with Compose Multiplatform | Kotlin | Shared Compose UI | Logic and UI | expect/actual declarations | Desktop Stable, web Beta |
| Flutter | Dart | Flutter-drawn widgets | Logic and UI | Platform channels, dart:ffi | Web, desktop and embedded listed as supported |
| React Native | JavaScript, TypeScript | Native components driven by React | Logic and UI components | Native Modules and Native Components | Android and iOS in core, others out-of-tree |
The maturity picture differs by row, and the per-platform status for the Kotlin options can change between releases. How a KMP adoption plays out in an existing Android and iOS app has the current stability table, so this page doesn't repeat it. KMP itself has been stable since November 2023.
Native code and platform APIs: where each one gets awkward
Every cross-platform tool gets awkward at the platform edge. They just get awkward in different ways.
KMP uses expect/actual declarations: you declare what the shared code needs, then write the Android and iOS implementations in the platform source sets. It's clean when the native side is Kotlin or Swift you control. The caveat is that iOS calls into Kotlin through an interop layer, so the iOS engineers on your team need to be comfortable reading Kotlin-shaped APIs.
Flutter's FAQ lists the options: platform channels for Android and iOS, JNI interop through jnigen for Kotlin and Java, ffigen for Swift and Objective-C, and dart:ffi for C and C++. That's a lot of choice, and the caveat is that every bridge is code in a third language that someone has to own.
React Native uses Native Modules and Native Components, which is how JetBrains' comparison with React Native describes it. The caveat: you're bridging JavaScript to Kotlin or Swift, so any serious native feature needs an engineer who can work in both worlds. The New Architecture has been the default since React Native 0.76, but the two-language problem remains.
Web and desktop: the part that differs most
If web or desktop has to be first-class, this is where the options separate. Flutter's FAQ lists iOS, Android, web, desktop (macOS, Windows, Linux) and embedded as supported targets. Of the three, only Flutter's own FAQ lists embedded devices alongside iOS, Android, web and desktop (macOS, Windows, Linux).
KMP's Kotlin/JS web target is Stable and Kotlin/Wasm is Beta (JetBrains' table, last updated 10 September 2025), and Compose Multiplatform for web is Beta. Desktop on the JVM is Stable. If your web product is a serious React or Next.js app, you may not want shared UI there anyway.
React Native's core targets Android and iOS. Windows, macOS, visionOS, tvOS and web run on out-of-tree platforms maintained by Microsoft, Callstack and the community. "Maintained outside core" is a different promise from "supported by the project", and you should check each one against your release schedule.
How the numbers on this comparison disagree
Search for any of these comparisons and you'll find startup-time tables, memory tables and speed claims. Most don't say how they were measured. Skip them.
The only measured KMP vs React Native test found for this article comes from Software Mansion's benchmark, which built the same SpaceX launch-list app in both and ran it on six real devices, three Android and three iOS. On Android, KMP's download was 2.0 MB against 15.8 MB, with startup two to four times faster and RAM around 120 MB against 175-232 MB. On iOS, download size was roughly tied, startup near identical, and React Native used less memory (45-131 MB against 157-251 MB). CPU results were inconclusive.
Two caveats matter. Software Mansion is a React Native consultancy, so a result favouring KMP on Android runs against its own business, but it's still one app, unoptimised baselines, not replicated. And Android and iOS pointed in different directions. The honest reading is that no neutral benchmark exists, and performance for your product is something to measure in a pilot.
How to choose by team
Opinion first: team shape beats technology. Here is the order of questions to ask.
1. You have native Android and iOS apps and teams
Choose KMP and share logic first. Your engineers keep their languages for UI, you stop writing networking, validation and business rules twice, and you can adopt it one module at a time. Flutter would mean rebuilding what already works.
2. You have no mobile apps, a small team and one design
Choose Flutter. One codebase, one UI layer, one hire to start. For a greenfield product with a single brand look, one codebase covers both stores.
3. You have React engineers and a web app
Choose React Native. Your existing JavaScript and TypeScript skills transfer. For the Flutter-versus-React Native trade-offs in depth, see the two-way Flutter and React Native comparison.
4. You need shared UI but already have Kotlin or Android expertise
Choose KMP with Compose Multiplatform. You get Flutter-style UI sharing without switching language. Check what is stable in Compose Multiplatform per platform before you commit, because iOS and desktop are Stable while web is not.
5. Desktop, embedded or web must be first-class
Start with Flutter, since it lists all three as supported, then check the Kotlin and React Native equivalents against the status table above. Don't assume parity.
6. Pilot one feature before committing
Pick a self-contained feature and build it with your shortlisted option. With KMP that can be a single shared module inside the existing apps. Whatever you choose, measure startup, memory and developer time on your own devices rather than trusting anyone's table, including the one above.
What each choice means for hiring in Europe
Hiring follows the stack. Flutter needs Dart specialists who've shipped to both stores and debugged a platform channel. KMP needs Android engineers who know Kotlin well, plus iOS engineers who can read Kotlin interop and review the shared code. React Native needs JavaScript or TypeScript engineers with mobile experience.
Language popularity gives a rough signal, with caveats. In the Stack Overflow 2025 developer survey, Kotlin was among the languages 10.8% of all respondents (global) had done extensive development work in, against 5.9% for Dart, with Swift at 5.4%. Among professional developers it was 11.5%, 6.1% and 5.7%. These are languages, not frameworks, and Kotlin's number includes Android native and backend work, so it says little about KMP specifically. These are global figures, not European hiring supply.
A practical rule: if the decision splits your team, staff the weaker side first. A KMP project with strong Android engineers and no iOS reviewer ships Kotlin the iOS team can't maintain.
Hiring Flutter, iOS and Android engineers through HighCircl
HighCircl covers Flutter, iOS and Android engineers across seven European countries. Rates run €45-105/hr ($50-115/hr), with a 20% margin that's capped and shown separately. Each engineer passes a four-stage, engineer-led vetting process (about 1 in 10 applicants get through), and a shortlist of three to five arrives within 72 hours. React Native isn't a stack HighCircl lists as covered. If Flutter is your pick, start with hiring Flutter engineers through HighCircl.
FAQ
Is Kotlin Multiplatform better than Flutter?
Neither is better in general. KMP is the better fit when you already have native Android and iOS apps and want to share logic without touching the UI. Flutter is the better fit when you're starting fresh and want one codebase and one UI. The deciding factor is your existing code and team.
Does Kotlin Multiplatform replace Flutter or React Native?
No, because they share different things. KMP shares logic and keeps the UI native, Flutter shares UI and logic in Dart, and React Native shares JavaScript or TypeScript. KMP replaces them only if you add Compose Multiplatform and your team prefers Kotlin to Dart or JavaScript.
Is Flutter or KMP cheaper to staff?
A single Flutter codebase can be staffed by one team, while KMP with native UI typically still needs Android and iOS engineers. We found no sourced salary comparison between the two, so compare quotes for your own role.
Can I use KMP with an existing iOS app?
Yes. KMP compiles shared Kotlin code into a native iOS framework that your Swift code calls, so you can adopt it one module at a time.
Is React Native or KMP better for a React team?
React Native, if the team's skills are the deciding factor. Your engineers already know the language and the component model. KMP makes sense for a React team only if the mobile apps are already native and the shared code is business logic that Kotlin engineers will own.
What does "Kotlin for iOS" mean?
Kotlin compiles to native iOS binaries through KMP, so shared Kotlin logic runs in your iOS app as a framework. The iOS UI stays Swift and SwiftUI unless you add Compose Multiplatform, which lets you write the UI in Kotlin as well.