What Is Kotlin Multiplatform and How It Works

Kotlin Multiplatform usage more than doubled in a single year, jumping from 7% to 18% among developers surveyed by JetBrains. That kind of growth doesn’t happen quietly.

So what is Kotlin Multiplatform, and why are companies like Netflix, Google, and Forbes betting on it? KMP is a technology by JetBrains that lets teams share Kotlin code across Android, iOS, desktop, and web while keeping each platform’s native UI intact.

This article covers how KMP works under the hood, where it fits compared to Flutter and React Native, what you can realistically share between platforms, and when it’s the right (or wrong) choice for your team. Whether you’re evaluating it for a new project or considering adding it to an existing tech stack for app development, you’ll walk away with a clear picture.

What is Kotlin Multiplatform

Kotlin Multiplatform is a technology built by JetBrains that lets developers write shared code in Kotlin and run it across Android, iOS, desktop, web, and server platforms. It reached stable status in November 2023.

But here’s the thing most people get wrong about it. KMP is not a cross-platform UI framework. It doesn’t try to replace your native interface layer. Your iOS app still uses SwiftUI or UIKit. Your Android app keeps Jetpack Compose or XML layouts. What KMP actually does is let you share the stuff underneath: business logic, networking, data handling, validation.

The Kotlin compiler handles the heavy lifting. It takes your shared Kotlin code and compiles it to platform-native binaries. On Android, that means JVM bytecode. On iOS, it produces native frameworks through LLVM. No JavaScript bridges. No interpreted bytecode running on top of something else.

JetBrains Developer Ecosystem survey data shows KMP usage among respondents jumped from 7% in 2024 to 18% in 2025, more than doubling in a single year.

Google made it official at I/O 2024: Kotlin Multiplatform has first-class support for sharing business logic between Android and iOS. That endorsement changed the conversation for a lot of teams who were on the fence.

Companies like Google, Forbes, Netflix, McDonald’s, Philips, and Duolingo already run KMP in production. According to JetBrains, KMP is used by over 20,000 companies worldwide across sectors like finance, e-commerce, and social media.

If you’re coming from the broader software development world and wondering where KMP fits, think of it as a code-sharing layer that sits between fully native development and full cross-platform frameworks like Flutter.

How Kotlin Multiplatform Works

KMP uses a project structure built around source sets. You write common code in a shared module (called commonMain), and the Kotlin compiler produces platform-specific output for each target you configure.

The compilation path depends on the platform:

• Android and JVM targets: Kotlin compiles to standard JVM bytecode, just like regular Kotlin code in any Android project
• iOS, macOS, and Linux targets: Kotlin/Native uses the LLVM backend to produce native binaries. No virtual machine involved
• Web targets: Kotlin/JS compiles to JavaScript, and Kotlin/Wasm (currently in beta) compiles to WebAssembly for browser-based apps

The Gradle multiplatform plugin manages all of this. You declare your targets in the build script, and the build system handles compilation for each one.

What makes the whole thing practical is the expect/actual mechanism. You define an expect declaration in your common code (a function, class, or property), and then provide actual implementations in each platform source set. The compiler enforces this contract at build time. Miss an implementation? It won’t compile.

During compilation, the Kotlin compiler merges expected and actual declarations into a single output per platform. Every call to an expect function in common code gets routed to the correct actual implementation in the final binary.

Took me a while to realize this, but the expect/actual pattern isn’t meant for everything. JetBrains recommends using it only where you genuinely need platform-specific APIs. For most abstraction needs, regular Kotlin interfaces and dependency injection work better and are easier to test.

Kotlin/Native and Kotlin/JVM Compilation

Kotlin/JVM is the straightforward path. Your code compiles down to bytecode and runs on the Java Virtual Machine, same as any Kotlin or Java application. Full interoperability with Java libraries comes built in.

Kotlin/Native is where things get more interesting. It uses LLVM to compile Kotlin directly into platform-native machine code. On iOS, that means producing Objective-C compatible frameworks that Swift code can call directly.

Memory management also differs between the two. Kotlin/JVM relies on the JVM’s garbage collector. Kotlin/Native now uses a modern garbage collector (introduced in Kotlin 1.7.20 and the default since 1.9.0), replacing the earlier memory model that caused headaches with concurrency and frozen objects.

The practical result: shared Kotlin code runs with native performance on every target. There’s no runtime overhead from interpretation or bridging layers.

Kotlin Multiplatform vs. Kotlin Multiplatform Mobile

If you’ve searched for KMP content before 2023, you probably ran into “KMM” everywhere. Kotlin Multiplatform Mobile was JetBrains’ mobile-specific branding that focused only on Android and iOS code sharing.

JetBrains dropped the KMM label in 2023 and unified everything under “Kotlin Multiplatform.” KMM was always a subset of KMP, not a separate product. The rebranding made sense because KMP targets way more than mobile: desktop, server, web, and embedded platforms all fall under the same umbrella.

The confusion still lingers, though. Older blog posts, Stack Overflow answers, and tutorials reference KMM extensively. Some libraries still carry the KMM naming in their package structure. If you’re following a guide from 2022 or earlier, just mentally replace “KMM” with “KMP” and you’re fine.

One thing that actually changed alongside the rebrand: JetBrains shifted tooling focus. The Fleet IDE, which was initially positioned as the KMP development environment, was discontinued for KMP support in early 2025. JetBrains now focuses KMP tooling efforts on IntelliJ IDEA and Android Studio, where most developers already work.

Kotlin Multiplatform vs. Flutter and React Native

This is the comparison everybody makes. And it’s a fair one, but the frameworks solve different problems.

Flutter and React Native replace your native UI entirely. You write the interface once, and the framework renders it on both platforms. KMP takes the opposite approach: keep your native UI, share only the logic layer.

According to Appfigures, roughly 46% of developers chose Flutter in 2025, making it the most popular cross-platform framework by usage. React Native’s market share grew from 4.73% in 2022 to 6.75% in 2024 on iOS. KMP is still the newer player here, but its growth rate is hard to ignore.

When does KMP make more sense? If you already have separate native apps and want to reduce duplicated logic. If your team has platform-specific UI/UX design requirements that can’t compromise on native look and feel. If your Android development team already writes Kotlin daily.

When do Flutter or React Native make more sense? Small teams that need maximum code sharing including the UI. Design-uniform apps where both platforms should look identical. Rapid prototyping when speed to market matters more than platform-native feel.

The cross-platform framework market overall is projected to grow from $15.67 billion in 2025 to $42.60 billion by 2034 at an 11.75% CAGR, according to Market Research Future. All three frameworks are riding this wave.

What You Can Share with Kotlin Multiplatform

The practical question every team asks: what exactly goes into the shared module?

Networking and API calls are the most common starting point. Ktor, JetBrains’ HTTP client library, runs on all KMP targets. You write your API integration once, and it works across Android, iOS, desktop, and web.

Data persistence comes next. SQLDelight generates type-safe Kotlin APIs from SQL statements and supports Android, iOS, JVM, and JavaScript targets. Your database schema and queries live in common code.

Serialization is handled by kotlinx.serialization, which converts between Kotlin objects and formats like JSON across all platforms. No platform-specific parsing needed.

Business logic, validation, and state management sit naturally in the shared layer. These are pure Kotlin computations with no platform dependencies. Forbes shares over 80% of its business logic across iOS and Android through KMP, shipping features simultaneously on both platforms.

Kotlin coroutines work in multiplatform projects too. Async operations, flows, and structured concurrency all function in common code, which matters a lot for networking and data layer work.

What you typically don’t share (at least not without extra work): direct camera or Bluetooth access, platform-specific UI components, and system-level APIs that have no common abstraction. Those stay in your platform source sets with actual implementations or native code.

The KMP Survey Q2 2024 found that 55% of users reported improved team collaboration after adopting KMP, and 65% said performance and code quality got better. That tracks. When Android and iOS developers work from the same shared logic, the “it works differently on iOS” problem goes away.

Compose Multiplatform and Its Relationship to KMP

Compose Multiplatform is JetBrains’ answer to the “what about sharing UI?” question. It extends Google’s Jetpack Compose to work on iOS, desktop, and web, on top of the Kotlin Multiplatform foundation.

But here’s the key distinction. KMP and Compose Multiplatform are separate projects. KMP is the code-sharing technology. Compose Multiplatform is an optional UI framework that builds on it. You can use KMP without Compose Multiplatform (and many production apps do exactly that).

Compose Multiplatform for iOS hitting stable status was a big deal. It supports native-like scrolling, iOS text selection, drag-and-drop, variable fonts, and native gestures. Over 96% of teams using Compose Multiplatform on iOS report no major performance issues, according to JetBrains data.

This changes the KMP pitch significantly. Before, KMP was “share your logic, keep UI native.” Now teams can optionally share the UI too, moving closer to what Flutter and React Native offer while still compiling to actual native code.

Bitkey by Block shares 95% of its mobile codebase using KMP and Compose Multiplatform. That kind of sharing ratio used to be exclusive to Flutter and React Native territory.

Still, I’d recommend starting with shared logic first. Prove the pattern works for your team before adding UI sharing. Compose Multiplatform adds complexity to your build setup and debugging workflow, especially on iOS where the tooling is newer. Get comfortable with cross-platform app development fundamentals before going all-in on shared UI.

Companies and Projects Using Kotlin Multiplatform

The list of production KMP adopters isn’t short anymore. And it’s not just startups experimenting either. Fortune 500 companies and billion-dollar products run shared Kotlin modules in apps used by millions of people daily.

According to JetBrains, Kotlin Multiplatform is used by over 20,000 companies worldwide across finance, e-commerce, social media, and other sectors.

Here’s what some of the bigger names are doing with it:

• Forbes shares over 80% of business logic across iOS and Android, shipping features simultaneously on both platforms
• Netflix reported a 40% reduction in feature development time after moving shared logic to KMP
• Google Workspace (Gmail, Docs, Calendar) adopted KMP across Android, iOS, and web to keep experiences consistent
• McDonald’s uses KMP to eliminate code redundancy across hundreds of markets worldwide
• Bitkey by Block shares 95% of its mobile code using KMP and Compose Multiplatform

Duolingo is another case worth watching. They accelerated development velocity after running six separate KMP initiatives and eventually adopted a “KMP-first” strategy for new features.

The pattern most companies follow is the same: start with a shared data layer, prove the approach works, then expand. H&M built a shared feature-toggle library first. Bolt started by revamping a single chat reconnect feature. Neither rewrote their entire app on day one.

JetBrains’ 2024 developer survey found that the majority of new KMP adopters are existing Android teams expanding their Kotlin knowledge into iOS, not teams rebuilding from scratch. That aligns with how most real-world adoption happens.

Open-Source KMP Libraries

The library ecosystem has grown fast enough that most common mobile application development needs are covered without writing platform-specific code.

Several Jetpack libraries now support KMP too. Room 2.8.3, DataStore 1.1.7, and ViewModel 2.9.4 all work in multiplatform projects, letting Android developers carry familiar tools into shared code.

How to Set Up a Kotlin Multiplatform Project

Getting a KMP project running is less complicated than it was two years ago. JetBrains has put real effort into reducing the friction, and it shows.

Two ways to start:

• The Kotlin Multiplatform Wizard at kmp.jetbrains.com generates a project with your chosen targets (Android, iOS, desktop, web, server) and downloads a ready-to-open project
• The New Project wizard built into IntelliJ IDEA or Android Studio, which does the same thing without leaving your IDE

You’ll need IntelliJ IDEA 2025.2.2 or Android Studio Otter 2025.2.1 at minimum. For iOS targets, a Mac with Xcode installed is required. Launch Xcode at least once before working with KMP so it finishes its initial setup.

The KMP IDE plugin runs preflight checks automatically when you open a project. It verifies your OS, Java setup, Android SDK, Xcode installation, and Gradle configuration. If something’s missing or outdated, you get clear recommendations.

If your team already uses source control management through Git, the generated project is ready to commit out of the box. Standard .gitignore files come included.

KMP Project Structure Breakdown

A generated project follows a predictable layout. The shared module contains your cross-platform code, split into source sets:

commonMain: where all shared Kotlin code lives. Business logic, data models, networking, anything that doesn’t touch platform-specific APIs goes here.

androidMain: Kotlin/JVM code for Android-specific implementations. Your actual declarations for Android live in this source set.

iosMain: Kotlin/Native code targeting iOS. This source set typically provides actual implementations using Apple framework APIs.

Dependencies are declared per source set in your Gradle build script. Common dependencies (like Ktor or Kotlin coroutines) go in commonMain. Platform-specific ones (like an OkHttp engine for Android) go in the appropriate platform source set.

The Gradle multiplatform plugin handles the rest. Declare your targets, configure your source sets, and the build automation takes care of compiling each target to its native format.

Limitations and Tradeoffs of Kotlin Multiplatform

KMP isn’t perfect. No technology is. And being honest about the rough spots matters more than pretending they don’t exist.

iOS Debugging and Tooling Gaps

Debugging shared Kotlin code on iOS is harder than on Android. That’s just the reality right now.

Android Studio handles Kotlin/JVM debugging with full breakpoint support and variable inspection. On the iOS side, you’re working across the Kotlin/Native boundary where Xcode’s debugger has less visibility into Kotlin internals. When something crashes, you often need to reproduce the issue in a shared unit test or Android scenario first, then fix it there.

The KMP IDE plugin now offers iOS debugging support in Android Studio and IntelliJ IDEA Ultimate, but it’s still catching up to what native Swift developers expect from Xcode.

Swift Interop Friction

Until very recently, all Kotlin-to-iOS communication went through Objective-C headers. Kotlin’s rich type information (generics, sealed classes, coroutines) got flattened during that translation. Swift developers had to work with APIs that felt clunky compared to native Swift code.

Kotlin 2.2.20 introduced direct Kotlin-to-Swift export (still experimental). JetBrains targets a stable release for this feature in 2026. Once that lands, the Objective-C bridge won’t be necessary, and the biggest iOS developer complaint about KMP goes away.

For now, libraries like SKIE and KMP-NativeCoroutines bridge the gap by mapping Kotlin flows to Swift’s async/await and AsyncSequence patterns.

Build Times and Configuration Complexity

Kotlin/Native compilation runs slower than equivalent JVM builds. It’s noticeable, especially on larger projects. The K2 compiler delivered over 40% faster compilation in real-world tests, but iOS target builds still take more time than Android ones.

Gradle configuration can get verbose too. Managing multiplatform dependencies, source sets, and target configurations across a growing project requires careful attention. Teams building production apps should invest in a solid build pipeline early.

Ecosystem Size

The KMP library ecosystem is growing, but it’s smaller than what Flutter or React Native offer for shared UI components. If you need a specific third-party SDK (analytics, payments, auth), check whether a KMP-compatible version exists before committing.

JetBrains launched Klibs.io as a library discovery tool, and more third-party SDKs are adding KMP support as adoption grows. But at this point, React Native’s npm ecosystem and Flutter’s pub.dev still have more packages available.

When Kotlin Multiplatform is the Right Choice

KMP isn’t for everyone. That’s by design. It solves a specific set of problems really well, and it’s the wrong tool for others.

Best Fit Scenarios

Existing native apps with duplicated logic. If your Android and iOS teams write the same networking, validation, or data handling code separately, KMP eliminates that redundancy without touching your UI. Organizations adopting this approach report up to a 30% reduction in development and maintenance costs, according to industry data.

Teams where native UI quality is non-negotiable. Apps in finance, healthcare, or any space where platform-specific iOS and Android design guidelines matter. Your UI stays fully native. Only the invisible layer underneath gets shared.

Android teams expanding to iOS. The JetBrains 2024 survey confirms this is the most common adoption path. Your developers already know Kotlin. The jump to writing shared modules is shorter than learning an entirely new framework.

Less Ideal Scenarios

Greenfield projects with small teams wanting maximum code sharing (including UI) might get more mileage from Flutter or React Native. Both offer higher sharing percentages out of the box with less architectural overhead.

Teams with zero Kotlin experience face a steeper ramp. iOS developers coming from Swift typically need 2 to 3 months to become productive in Kotlin, based on developer reports. If your entire team writes JavaScript, React Native is probably the faster path.

Apps that don’t need complex shared logic (simple CRUD apps, basic content readers) won’t see enough benefit to justify the multiplatform setup. Just build natively. Or pick whichever cross-platform tools your team already knows.

The Gradual Adoption Advantage

Here’s what makes KMP different from most cross-platform decisions: you don’t have to go all-in.

You can add a single shared Kotlin module to an existing native app today. That module compiles into a regular Android library and an iOS framework. Your current development process barely changes.

JetBrains’ 2024 survey found that 47% of mobile teams using KMP reported faster delivery times, and 73% said they’d recommend it to other teams.

Start with one shared layer. Maybe networking. Maybe data models. If it works, expand. If it doesn’t, you’ve only invested in one module, not a full rewrite. That’s the lowest-risk entry point into choosing between native, hybrid, or cross-platform approaches.

FAQ on What Is Kotlin Multiplatform

What is Kotlin Multiplatform used for?

KMP is used to share business logic, networking, and data handling code across Android, iOS, desktop, and web platforms. Teams write shared Kotlin modules once and compile them to native binaries for each target.

Is Kotlin Multiplatform the same as Flutter?

No. Flutter replaces your native UI with its own rendering engine. Kotlin Multiplatform shares logic while keeping native UI on each platform. They solve different problems, and KMP gives you more control over platform-specific design.

Is Kotlin Multiplatform production ready?

Yes. JetBrains declared KMP stable in November 2023. Companies like Netflix, Forbes, and McDonald’s run it in production apps serving millions of users. Google officially supports it for sharing logic between Android and iOS.

Do I need to know Swift to use KMP on iOS?

Not for shared code. You write everything in Kotlin. But your iOS-specific UI layer still uses SwiftUI or UIKit, so basic Swift knowledge helps when integrating the shared module into your custom app.

What is the expect/actual mechanism in KMP?

It’s how KMP handles platform-specific code. You declare an expect function in common code, then provide actual implementations per platform. The Kotlin compiler enforces this contract at build time.

Can Kotlin Multiplatform share UI code?

Compose Multiplatform lets you share UI across Android, iOS, and desktop. It reached stable status for iOS in May 2025. It’s optional though. Many production apps share only logic and keep UI fully native.

What companies use Kotlin Multiplatform?

Google Workspace, Netflix, Forbes, McDonald’s, Philips, Cash App, Duolingo, H&M, and Shopify all use KMP in production. JetBrains reports over 20,000 companies worldwide have adopted the technology.

How does KMP compile code for iOS?

Kotlin/Native uses the LLVM compiler backend to produce native iOS binaries. The output is an Objective-C compatible framework that Swift can call directly. No virtual machine or interpreter runs at runtime.

What is the difference between KMP and KMM?

KMM (Kotlin Multiplatform Mobile) was the old branding for mobile-only code sharing. JetBrains retired the KMM label in 2023 and unified everything under “Kotlin Multiplatform,” which covers mobile, desktop, web, and server.

Can I add Kotlin Multiplatform to an existing app?

Yes, and that’s actually the recommended approach. You add a shared Kotlin module to your existing project without rewriting anything. Start with one layer like networking or data models, then expand gradually over time.

Conclusion

Understanding what is Kotlin Multiplatform comes down to one idea: share the logic, keep the native experience. KMP gives development teams a practical way to eliminate duplicated code across Android, iOS, desktop, and web without forcing a single UI framework on every platform.

With Google’s official backing, Compose Multiplatform reaching stable on iOS, and production adoption from companies like Duolingo, Shopify, and Cash App, the ecosystem has matured past the experimental stage.

The expect/actual mechanism, Gradle-based project structure, and growing library support (Ktor, SQLDelight, kotlinx.serialization) make gradual adoption realistic for most teams. Start with a single shared module. Test it. Expand from there.

If your team already writes Kotlin for Android, KMP is the shortest path to mobile app best practices across both platforms.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu specializes in web design, focusing on creating user-friendly websites, and innovative UI kits.

Many of his resources are available on various design marketplaces and for free on Codepen.

Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, and Speckyboy, and Slider Revolution among others.

Latest posts by Bogdan Sandu (see all)

• What Is Agentic Coding? The Next AI Dev Workflow - April 10, 2026
• From Setup To Monitoring: Why A DMARC Service Matters - April 10, 2026
• 4 Scalable Hosting Providers for Growing Small Business Websites - April 9, 2026