Most teams that ship on Android and iOS have written the same validation rules twice, once in Kotlin and once in Swift. At some point the two versions stopped matching. Kotlin Multiplatform is JetBrains’ fix for that. You write the shared parts once in Kotlin, and the compiler turns them into native output for Android, iOS, desktop, web, and server targets.
People usually find it while comparing Flutter and React Native. That comparison is a bit lopsided, because KMP doesn’t try to draw your screens at all.
JetBrains maintains the compiler and tooling. Google backs it as an officially supported way to replace two separate native codebases with one shared logic layer.
Most adoption numbers come from JetBrains itself, so keep that in mind. In JetBrains’ own KMP Survey Q2 2024, 65% of teams reported improved performance and quality after adopting the technology, and 55% reported improved collaboration across platform teams.
What Is Kotlin Multiplatform?
JetBrains built it as a code sharing technology. It is not a rendering framework, and that difference matters more than it sounds.
A team writes business logic once in Kotlin and reuses it on every platform, instead of rebuilding the same rules three or four separate times.
Where it really differs is in what stays native. Most cross-platform app development frameworks ship their own rendering engine and run it on top of every platform. Kotlin Multiplatform leaves native UI alone. UI only gets shared if a team decides to add Compose Multiplatform on top.
Kotlin Multiplatform vs Kotlin Multiplatform Mobile (KMM)
The original name was Kotlin Multiplatform, announced at KotlinConf 2017. In 2020, JetBrains split out the Android- and iOS-focused subset into a separate product called Kotlin Multiplatform Mobile, or KMM, to focus on the most common mobile use case.
That didn’t last. In July 2023, JetBrains deprecated the KMM name and folded it back into Kotlin Multiplatform (KMP), citing years of naming inconsistency and abbreviation confusion as the technology spread well beyond mobile.
So if a tutorial or job listing from before 2023 says KMM, it means the same thing. The expect and actual mechanism never changed name or behavior. Current JetBrains documentation just uses Kotlin Multiplatform everywhere.
It isn’t a full UI abstraction layer, and it isn’t a rewrite tool either. It’s a way to stop duplicating the parts of an app that have nothing to do with how a screen looks.
How Does Kotlin Multiplatform Work?
A project gets split into a common source set plus one source set per platform.
Business logic, data models, and networking calls go in the common module. Platform details sit next to the platform they belong to.
When common code needs something only a platform can provide, it declares an expect function or class. Each platform then writes its own actual implementation, and the Kotlin compiler links the two together at compile time, not at runtime.
The classic first example is a platform name. Common code says it needs one. Android returns one string, iOS returns another. It’s a trivial demo, but that’s the whole pattern.
It also works with native code you already have. On iOS, Kotlin/Native compiles the shared module into a framework that Swift and Objective-C call directly. Android and the JVM are simpler, since Kotlin already compiles to JVM bytecode there and ordinary Java interop handles it.
Compile speed used to be a fair complaint. JetBrains reports that K2, the compiler that became Kotlin’s default with the Kotlin 2.0 release in 2024, cut compilation time by more than 40% across its own IntelliJ monorepo once K2 mode became the default for code analysis in IntelliJ IDEA 2025.1 (JetBrains, KotlinConf 2025).
What you end up with is one shared codebase for logic, with platform code kept thin.
What Platforms and Targets Does Kotlin Multiplatform Support?
Each runtime gets its own compiler backend. Kotlin/JVM produces bytecode for Android and backend services, while Kotlin/Native goes through LLVM to produce native machine code for iOS, macOS, Linux, and Windows.
| Backend | Compiles To | Typical Targets |
|---|---|---|
| Kotlin/JVM | JVM bytecode | Android, backend servers |
| Kotlin/Native | Native machine code | iOS, macOS, Linux, Windows |
| Kotlin/JS | JavaScript | Browser, Node.js |
| Kotlin/Wasm | WebAssembly | Modern browsers |
For iOS development, Kotlin/Native wraps the compiled logic into an XCFramework that a Swift project links against directly.
There’s no extra wrapping step for Android development. The app already runs on the JVM.
A target hierarchy template groups related targets, like every Apple target or every native target. Shared code inside that group doesn’t get duplicated per platform.
Who Develops and Maintains Kotlin Multiplatform?
JetBrains builds and ships it. Google backs it as an officially supported option for sharing logic between Android and iOS and contributes through Jetpack library support.
Then there’s the Kotlin Foundation, funded jointly by JetBrains and Google. It sets the direction for the Kotlin language and funds independent library authors.
Most roadmap news lands at KotlinConf, JetBrains’ annual conference, where new stable releases usually get their first public walkthrough.
Google Workspace already runs Kotlin Multiplatform in production inside the Google Docs iOS app. That’s a decent sign the technology is well past the experimental stage.
It reached stable status in Kotlin 1.9.20, released November 2023, roughly six years after its experimental introduction in Kotlin 1.2 (2017). By 2025, Kotlin itself had about 2.5 million developers worldwide (JetBrains, KotlinConf 2025).
“Stable” means the API contract won’t break between minor releases. It doesn’t mean every corner of the ecosystem is finished.
JetBrains is known across the wider software development world for IntelliJ IDEA and PyCharm, and it’s now betting a large part of its roadmap on this working out.
Does Kotlin Multiplatform Share the User Interface Too?
By default, no. Only logic gets shared. The interface stays with Jetpack Compose on Android and SwiftUI or UIKit on iOS.
Compose Multiplatform changes that if a team opts in. It’s a separate JetBrains framework, built on Jetpack Compose, that extends UI sharing to iOS, desktop, and web.
Sticking with logic only is the gentler route. Every platform keeps its native UI, teams already fluent in SwiftUI or Jetpack Compose barely have to learn anything new, and you can drop it into an existing native app without much disruption.
Adding Compose Multiplatform gets you more, at a price:
- One UI codebase for Android, iOS, desktop, and web
- Fewer places for visual inconsistency to creep in
- A steeper start, because the team now owns a shared rendering layer as well as shared logic
Compose Multiplatform for iOS reached stable status in May 2025 with the 1.8.0 release, and over 96% of teams reported no major performance concerns after adopting it, per a JetBrains survey cited in that release.
You don’t have to decide up front. Start with logic sharing, add Compose Multiplatform later, and the shared business logic underneath stays as it is.
What Libraries and Tools Make Up the Kotlin Multiplatform Ecosystem?
Once the core went stable, the library count took off. JetBrains reports that the number of multiplatform libraries grew by 35% in 2024 alone, enough that the company launched klibs.io as a dedicated catalog just to make them searchable.
| Category | Common Choice | Handles |
|---|---|---|
| Networking | Ktor | Shared HTTP calls |
| Local storage | SQLDelight | Shared database access |
| Dependency injection | Koin | Wiring shared components together |
| Async and data | kotlinx.coroutines, kotlinx.serialization | Concurrency and data parsing |
Koin handles dependency injection the same way on every target, so a shared component gets wired up once.
Ktor covers most of the networking layer, including calls to a RESTful API your backend team already runs.
Navigation and state management took longer to catch up. Decompose and Ballast fill those gaps now. And Touchlab’s SKIE tool cleans up how the generated Swift API reads on the iOS side, which iOS developers tend to appreciate more than anyone expects.
Who Should Use Kotlin Multiplatform?
If you already maintain separate Android and iOS codebases, you’ll see the payoff fastest.
Duplicated business logic is exactly what it removes, and nobody has to give up native performance for it. The typical trigger is an app that’s already on both stores, where pricing, validation, or data models keep drifting apart between the two versions. It helps a lot that you can add a shared module to one part of the app and leave the rest alone for now.
Cash App, owned by Block, is one of the most cited production users. It shares Kotlin code between Android and iOS for data and business logic while keeping each platform’s UI fully native.
Duolingo ships weekly on Android and iOS to more than 40 million daily active users, using Kotlin Multiplatform for shared logic across its apps, according to JetBrains’ reporting.
A solo developer building for one platform won’t get much from it. Same for a small team shipping only a web app. There’s nothing to share code with.
If you’re deciding where to put money in mobile application development and a full rewrite is on the table, incremental adoption is usually the safer place to start.
How Does Kotlin Multiplatform Compare to Flutter and React Native?
All three promise less duplicated work across Android and iOS. They go about it differently.
Flutter and React Native each ship their own rendering layer. Kotlin Multiplatform ships none by default, and native UI stays in place unless you add Compose Multiplatform.
| Dimension | Kotlin Multiplatform | Flutter | React Native |
|---|---|---|---|
| Default UI approach | Native per platform | Custom rendering engine | Native components via a JS bridge |
| Primary language | Kotlin | Dart | JavaScript or TypeScript |
| Compiles to | Native binaries, JVM bytecode, JS, Wasm | Native binaries through Dart AOT | Native components at runtime |
| Best fit | Sharing logic, keeping native UI | One pixel-identical UI everywhere | Teams already fluent in React |
On raw usage, Stack Overflow’s 2024 Developer Survey found Flutter used by 9.4% of more than 65,000 developers polled, just ahead of React Native at 8.4 percent (Stack Overflow, 2024).
KMP doesn’t show up in those numbers. The survey lumps it in with Kotlin instead of giving it its own cross-platform category.
Choosing between Flutter or React Native mostly comes down to which rendering engine you’re willing to hand your entire UI to.
Forbes took a different path. By sharing more than 80% of its logic between iOS and Android through Kotlin Multiplatform, it kept two separate, fully native apps instead of one cross-platform UI (JetBrains case study, 2023).
What Are the Benefits and Drawbacks of Kotlin Multiplatform?
You get native performance and shared logic. You also take on a second compiler backend and a new set of debugging habits.
The good part is easy to list. Nothing runs through a bridge, so performance stays native on every platform. Business logic, networking, and data models get written once, and so do the tests: shared unit testing means you stop testing the same rule twice. You can also adopt it piece by piece inside an app that already exists.
The downsides are the ones I’d actually plan around:
- iOS tooling still leans on Xcode and CocoaPods quirks that Android developers rarely run into, and those quirks eat afternoons
- There are fewer battle tested libraries than in Flutter’s plugin catalog
- Hiring gets harder. You need people comfortable with Kotlin and with native iOS conventions
McDonald’s shares complex logic like in-app payments through Kotlin Multiplatform. After expanding it across the full app, the team reports fewer crashes and better performance on both platforms, simpler testing, and a move from separate Android and iOS teams to one unified mobile team (JetBrains case study).
Most of the benefit still sits with one platform pairing. JetBrains’ own multiplatform surveys have repeatedly found Android and iOS to be the single most common target combination among Kotlin Multiplatform users, well ahead of any other target mix.
Snapp Mobile’s 2024 Kotlin Multiplatform Developer Survey found that 46.7% of surveyed teams have considered Kotlin Multiplatform and plan to explore it further. Given how quickly the drawbacks list has been shrinking, that makes sense.
When Does Kotlin Multiplatform Not Apply?
It solves one problem, duplicated logic across more than one platform. Take away the second platform and there’s nothing left for it to do.
It’s a poor fit if:
- The app ships on a single platform, with no Android, iOS, desktop, or web counterpart planned
- You need one pixel identical UI from day one (a self rendering framework handles that more directly)
- The team has no Kotlin or Swift experience and no time budgeted to build it
- Core functionality depends on a native SDK, like certain AR or camera hardware kits, that needs platform specific wrapping no matter what gets shared underneath
One technical constraint to know before committing: an iOS app can only load one Kotlin/Native runtime at a time.
Two separately built Kotlin Multiplatform frameworks inside the same iOS app can conflict at runtime. The limitation comes from Kotlin/Native’s closed world compilation model, and JetBrains engineers have discussed it directly in the Kotlin community’s own Slack channel.
None of this makes it a bad choice. It’s built for a specific shape of problem, and it doesn’t replace platform expertise.
How Do You Set Up a Kotlin Multiplatform Project?
Most of this only needs doing once per project.
- Install the Kotlin Multiplatform plugin for Android Studio
- Create a new multiplatform project through the wizard, or add a shared module to an existing Android app
- Define common code in the shared source set and mark platform dependent pieces with expect declarations
- Fill in actual implementations for each target
- Link the generated iOS framework into an Xcode project, directly or through CocoaPods
- Run the app on each target to confirm the shared module compiles and behaves the same way everywhere
Build System and Gradle Configuration
Every module still gets configured through Gradle, and most new projects use the Kotlin DSL rather than Groovy.
Gradle is where you declare which targets a module compiles for and wire up dependencies separately for the common, Android, and iOS source sets. It also kicks off the actual Kotlin/Native compilation for iOS output, which is the slow step you’ll notice.
JetBrains also maintains Amper, an experimental alternative to Gradle. Most production projects still stick with Gradle for now.
IDE and Platform Tooling
You’ll be working in two IDEs. Android Studio covers the Android side once the Kotlin Multiplatform plugin is installed, including run configurations for both platforms.
Xcode still owns the final iOS build, since Apple’s signing and simulator tooling lives there.
If you’re comparing broader cross-platform app development tools with a Kotlin Multiplatform setup, this is one of the few approaches that keeps both native IDEs in the loop instead of replacing them.
As for Swift or Objective-C, generated interop code reads more naturally in Swift. Most teams treat Objective-C compatibility as a fallback.
What Problems Come Up When Adopting Kotlin Multiplatform?
Most of them show up early, before a team has built enough shared modules to know better.
| Problem | Where It Shows Up | What Usually Fixes It |
|---|---|---|
| Gradle version mismatch | Adding a shared module to an existing Android app | Aligning Gradle and Kotlin plugin versions before the first sync |
| CocoaPods breakage | After an Xcode update | Rebuilding the exported framework, not just rerunning pod install |
| Thin iOS debugging support | Stepping through shared code from the Swift side | Swift export, still maturing, or print based debugging as a fallback |
| Overloaded common module | Teams that share platform specific concerns by accident | Stricter expect and actual boundaries from the start |
That last row gets worse faster than people expect. A 2024 survey of 138 Kotlin developers found technical debt named as the single biggest challenge by 25% of respondents, more than any other category (Kotzilla, 2024).
Sharing code makes that risk bigger. One badly designed common class now breaks three platforms instead of one.
Things usually calm down after the team does one full code refactoring pass on the shared layer and moves the platform specific leftovers back out of common code.
None of these problems are unique to KMP. Any shared codebase runs into them eventually. Here they just show up sooner, because the code is shared from day one.
FAQ on What Is Kotlin Multiplatform
Is Kotlin Multiplatform free to use, and what license does it carry?
Yes, it’s free. The code is open source under the Apache 2.0 license. JetBrains’ IDE plugins for IntelliJ IDEA and Android Studio don’t cost anything either, apart from any paid JetBrains subscriptions you might already have.
Do you need to learn Swift or Objective-C to use Kotlin Multiplatform?
Not for the shared logic, which stays in Kotlin. Someone on the team still needs basic Swift familiarity to pull the generated framework into an Xcode project and hook it up to SwiftUI or UIKit screens.
Does Kotlin Multiplatform work directly with SwiftUI or UIKit?
It does. Shared state holders written in Kotlin expose StateFlow, and iOS code observes it and turns it into SwiftUI bindings or UIKit callbacks. There’s no bridge layer, since the shared module compiles straight into a native framework.
Is Kotlin Multiplatform a reasonable choice for a solo developer or a small team?
Rarely, unless the app already targets two platforms. For a single Android app, a shared module buys you nothing, and the extra Gradle and Kotlin/Native setup costs more than any logic reuse until a second platform comes along.
What Should You Move to Kotlin Multiplatform First?
Start with networking and data models. Those layers carry the most duplicated logic and the fewest platform specific dependencies, so they pay off fastest. Persistence and navigation can wait.
An order that works for most teams:
- Networking and data models
- Business rules and validation
- Persistence
- Navigation, last
Navigation goes last because it touches platform specific lifecycle behavior on both Android and iOS. Share it too early and the line between common and platform code gets blurry.
The catch is a slower first win on iOS. Networking and data code rarely changes what a user sees on screen, so the visible payoff only shows up once a second feature ships through the shared module.
It also helps to look at this choice next to the wider split between native, hybrid, and cross-platform apps. That makes it clearer whether KMP is up against a full rewrite or a smaller change.
- MySQL Cheat Sheet - September 30, 2026
- How to Remove Duplicate Lines in Notepad++ (Sorted or Unsorted) - September 29, 2026
- Should Your Engineering Team Still Own the Marketing Website? - September 29, 2026
