Compose Multiplatform Is a Business Decision, Not a Technical One

Six months ago, Sam and I wrote Helping Decision-Makers Say Yes to KMP because Kotlin Multiplatform (KMP), for sharing business logic, has moved from a bet to the default choice for engineering leaders shipping iOS and Android from one codebase. In this article, I’d like to talk about sharing your UI with Compose Multiplatform (CMP) and why it is a strategic decision to make now.

If you lead engineering at a company still weighing Flutter, still maintaining two native UI codebases “for now”, or still assuming cross-platform means giving something up, CMP is a strong contender.

The comparison you’re actually making

Most cross-platform evaluations are better described as Shared UI evaluations (Touchlab has written about this before). When your evaluation defaults to Flutter vs React Native, it’s a Shared UI evaluation. React Native was first and came out of React for web, both having roots in Facebook/Meta engineering. Flutter came next, with a new language called Dart, its own runtime, and roots from Google engineering.

That comparison is out of date.

Compose Multiplatform is Google’s native Android UI toolkit, extended to iOS by JetBrains. On Android, Jetpack Compose isn’t a cross-platform layer at all, it’s the native, official UI framework. That means there is no compatibility tax, no “close enough to native” compromise, no separate rendering engine sitting between your code and Android. Flutter, by contrast, asks your team to learn Dart and adds a new rendering model on both platforms. I don’t argue with people set on React Native anymore, if you want JavaScript and leverage web engineers, go for it.

Flutter filled a gap between choosing native-oriented mobile development or web-oriented mobile development at a time when CMP didn’t exist. When leaders wanted something better than React Native, without the cost of two native teams, they could decide on Flutter. When Flutter was a new technology, even with Google behind it, it was a risky decision: fewer Dart/Flutter devs, smaller ecosystem, unproven technology. In the past few years, to their credit, Flutter has matured a lot: many Dart/Flutter devs, thriving ecosystem, proven in production.

So if Flutter is so mature now, why choose Compose Multiplatform instead? Many more Kotlin/Compose devs, the Kotlin ecosystem is the gold standard for Android development, the CMP ecosystem growing, and CMP is also proven in production. Unlocking these native development benefits no longer requires separate expensive teams for Android and iOS, now you can have smaller teams building Native Android + CMP for iOS.

New comparison:

• Fully Native Mobile: Kotlin + Swift, two teams, still expensive, best quality
• Compose Multiplatform: Kotlin, one team, less expensive, best quality on Android, great quality on iOS
• Flutter: Dart, one team, less expensive, great quality on both platforms
• React Native: JavaScript, one team, less expensive, good quality on both platforms

Why this is a decision-maker problem, not an engineering one

Every cross-platform conversation eventually lands on the same three topics:

Cost. Now that native Android is cross-platform with iOS through CMP, the cost is in line with Flutter and React Native. Separate native teams building the same features twice was the default cost structure many mobile leaders have accepted so they can build better apps. Sometimes leaders decided Native was too costly and chose between web technologies or Flutter. Compose Multiplatform brings shared business logic and UI code across iOS and Android at cross-platform costs without asking you to abandon native quality and performance.

Risk. The traditional objection to any cross-platform framework is the “risk cliff”: once you commit, and if it doesn’t work out, you’re rewriting both apps. CMP doesn’t force that bet. In the absolute worst case, you keep your Android app, and rewrite iOS. Even better, the KMP/CMP foundation in optionally sharable code means the commitment is gradual and reversible in a way Flutter’s architecture doesn’t allow. And this is true whether you start all-in on CMP for iOS and add SwiftUI where needed, or build up CMP screens into a fully native iOS app.

Hiring and Training. This argument often gets missed in the technology-focused arguments. Flutter requires Dart and knowing the Flutter ecosystem. You are either hiring from a smaller pool or investing in training your existing devs. CMP lets you hire from a very large and experienced pool of existing Android talent or leverage your existing Android developers. Of course, this is also related to cost because leveraging your existing team costs much less than hiring a new team.

Why now?

Before Compose Multiplatform, Flutter filled an important gap when native development was too expensive and web technology was unable to build “good enough” apps. KMP has been gaining ground since 2023 against both Flutter and React Native. CMP has been production-stable on iOS since May 2025 and on Desktop since 2023. At Google I/O 2026, the Android team announced that Android UI Development is Compose First. Compose Multiplatform completely changes the game, but most engineering organizations weighing the cross-platform decision haven’t updated their evaluation to reflect that yet.

In this 2023 Statista survey, you can see Flutter gaining as React Native and other web technologies lost ground. Flutter announced stable 1.0 in 2018, when Kotlin Multiplatform (the shared business logic underpinnings of CMP) was still figuring out which memory model to use. But you can see KMP already finding a niche for those looking for a native cross-platform solution.

In 2024, AppFigures asked “Will React Native’s New Architecture Take the Lead Away from Flutter?” when they saw a different trend in real apps, with Flutter having more usage from 2022 to 2024, but React Native increasing at a higher rate.

However, in 2025, AppFigures noticed something else: “React Native’s New Rival Is Quietly Eating Its Lunch”. They weren’t talking about Flutter, they were talking about Kotlin Multiplatform. KMP was only in 14% of iOS apps on the App Store, but contributed to 27% of iOS app revenue!

What I see is Compose Multiplatform at the adoption inflection point today where Flutter was in 2018. The big difference is that Flutter started from scratch, CMP is building off of Jetpack Compose (Google’s official UI framework for Android), Kotlin (Google’s official language for Android), and Kotlin Multiplatform (used in Google Workspace apps, and many other scaled production apps). That means CMP is at a stage of technical, community, and foundational investment that rivals Flutter right now.

Flutter is no longer filling a gap between native and web technologies. In general, technology is often ready before most have finished evaluating it (the Diffusion of Innovation). If you’re currently funding two full native teams, or you’re in the middle of a Flutter evaluation as the way to consolidate them, adopting CMP now is a genuine advantage over companies still running two native teams or still building with Flutter.

CMP can be incremental at your own pace

If you’re evaluating cross-platform for the first time, CMP and KMP together are the more complete, lower-risk starting point than a Flutter rewrite, because you’re adopting a native Android framework with an iOS extension, not a rewrite into a 3rd platform.

CMP is the shared UI layer on top of KMP’s shared business logic, and both can be adopted incrementally. If you’re already running KMP for shared business logic, CMP is the next increment. CMP extends the same investment in shared business logic to the shared UI. You can do it at your own pace, screen by screen, as fast or as slow as your business and engineering strategy requires.

Touchlab’s place in all this

For Touchlab, KMP is not a side project, it is who we are since 2019. Our open source tooling SKIE, KMMBridge, Kermit, xcode-kotlin, and CrashKiOS all came out of production problems we hit while building for real clients putting KMP into production at scale. As a JetBrains partner and member of the Kotlin Foundation serving on the board of directors and the ecosystem and library committees, we’re part of the conversations shaping where this technology goes next. Our KMP and CMP work is trusted by Amazon, Block, Google, NBCUniversal, and Zwift (yes, A to Z), among many more who see KMP and CMP as strategically important to mobile, web, and desktop products and their ROI.

KMP specialists at the Touchlab level are rare. Engineering leaders call us when a cross-platform decision has real budget and real risk attached. Whether just sharing logic with KMP or going all-in on sharing UI with CMP, Touchlab is here to accelerate, de-risk, and optimize your goals.

The conversation to have this quarter

1. If you have native Android and iOS teams but haven’t yet begun adopting KMP or CMP, you need to ask what’s stopping you. Given that KMP and CMP give you fully native Android, built on skills your teams already have, and can extend into iOS, there is no question that KMP is the better cross-platform framework for your team and your product.
2. If you have begun to adopt KMP or CMP, you need to ask how to accelerate and reap the benefits at scale. Duolingo, Google Workspace, McDonald’s, and philo trust KMP at scale, so can you.
3. If you are thinking about Flutter but don’t already have apps built with Flutter, you need to ask why upskill in a new non-native language and new non-native framework, when CMP brings you fully native Kotlin for a fully native Android app that you can share with iOS (just like Flutter, but better).