Is Kotlin Multiplatform production-ready in 2026?

Deciding whether Kotlin Multiplatform (KMP) is ready for production isn’t really a technical question anymore. It’s a strategic one.

“Is KMP stable” is no longer the key question here.

The tooling is stable. Google officially recommends KMP for sharing business logic between Android and iOS. JetBrains Developer Ecosystem Survey reveals that adoption jumped from 7% to 18% among Kotlin developers in a single year. So the question now is not whether Kotlin Multiplatform works. The real question is whether it fits your product, team, and timeline. 

This article breaks down what’s actually stable, what’s still maturing, and where KMP creates real advantages – based on patterns we’ve seen across multiple cross-platform projects, including one where this decision had to be revisited mid-build.

What is Kotlin Multiplatform and How Does it Work?

Kotlin Multiplatform is a code-sharing framework from JetBrains, recommended by Android developer guidelines for Android and iOS projects. Unlike full-stack frameworks, it does not replace native UI or try to remove platform developers from the process.

KHere’s how it works in practice:

• A shared Kotlin module handles business logic – API integrations, caching, background tasks, domain rules – and compiles to JVM for Android and native binaries for iOS.
• Separate native UI modules (Jetpack Compose, SwiftUI, UIKit) deliver platform-specific experiences.
• Kotlin’s expect/actual mechanism bridges platform APIs like file storage, sensors, or encryption.

Teams can also go with Compose Multiplatform and share UI between Android and iOS. This UI framework speeds things up, but you lose some of the native feel. On iOS in particular, that comes with design compromises – we’ll get into those below.

One common misconception: KMP won’t eliminate your iOS or Android team. It complements them by removing logic duplication. Even Swift-focused teams benefit from consistent cross-platform behavior without rewriting business rules twice.

What’s Stable and What’s Still Maturing in KMP?

JetBrains announced that the KMP core became stable and production-ready in November 2023 with Kotlin 1.9.20. Later, Compose Multiplatform for iOS reached stable status in May 2025 with version 1.8.0. But “stable” doesn’t mean everything is equally polished across all platforms yet.

The practical takeaway: if you’re building mobile apps with shared business logic, the core technology is production-ready. If you need a shared UI on iOS, Kotlin Multiplatform’s Compose Multiplatform is now stable. Web and Wasm targets still need more time.

How Fast Is KMP Adoption Growing?

According to the JetBrains Developer Ecosystem Survey, KMP adoption among Kotlin developers jumped from 7% to 18% between 2024 and 2025 – more than doubling in a single year.  The table illustrates key numbers about the growing KMP adoption.

So what actually pushed this forward? A few things landed close together. Google backed KMP for sharing Android and iOS logic. Compose Multiplatform for iOS finally became stable. And JetBrains shipped proper tooling for KMP inside IntelliJ IDEA and Android Studio. 

Put together, it stopped feeling experimental.

So is this just early-adopter hype? Not likely. When Google recommends a technology for their own platform, it tends to stick. Google Workspace already runs KMP in production in the Google Docs iOS app.

Kotlin Multiplatform vs. Flutter vs. React Native

According to the article from Java Code Geeks, Flutter holds roughly 46% of the cross-platform market in 2026, React Native sits at 35-42%, and KMP has climbed to 23%. But market share alone doesn’t tell you which framework fits your product.

For a deeper dive on the Flutter side, check out our recent article with a comprehensive Flutter vs. Kotlin Multiplatform comparison. 

What are the Remaining Challenges in KMP?

KMP has come a long way since 2023, but it’s not without friction. Here are the areas where teams still hit real-world problems – and what to expect in each.

Kotlin/Native and iOS integration

KMP’s Kotlin/Native layer compiles shared code for iOS, but the integration isn’t seamless yet:

• Memory management can be tricky with large iOS objects like UIImage or real-time camera frames. Recent improvements to the memory model have addressed many pain points, but edge cases remain.
• Interop for Kotlin Multiplatform iOS development is limited to Objective-C. You can’t call Swift-only APIs (SwiftUI views, native closures, protocol extensions) directly from Kotlin.
• You’re limited to a single Kotlin/Native framework per iOS app, which forces monolithic packaging and can complicate modular architectures.

You’ll need someone on the team who understands iOS internals – not just Kotlin developers.

Build tooling and debugging

Development still feels like managing two toolchains and two build systems:

• iOS targets must be compiled on macOS, adding complexity to CI/CD pipelines and requiring dedicated Mac runners.
• Gradle configurations for multiple platforms are non-trivial, especially with platform-specific dependencies.
• CocoaPods and Swift Package Manager support exists, but can be brittle. External pods may break builds unexpectedly.
• Build performance still lags for iOS targets. The K2 compiler has cut compile times roughly in half, but shared code compilation remains slower than equivalent JVM builds.

Debugging is possible, but uneven. Android Studio handles Android targets well. Shared code debugging on iOS works with a proper Xcode setup. UI testing with Compose on iOS is still weak – Compose views are opaque to XCTest.

Compose Multiplatform for iOS

In May 2025, JetBrains stabilized Compose Multiplatform for iOS. With version 1.10.0, it also introduced things like shared @Preview support and built-in Compose Hot Reload. But some friction points remain:

• The platform still lacks iOS components out of the box. Everything defaults to Material Design unless you build custom Cupertino-style components.
• Accessibility has improved a lot (VoiceOver, AssistiveTouch, Full Keyboard Access now supported), but edge cases still exist.
• SwiftUI/UIKit integration requires workarounds, not first-class interop.

Library and tooling support

Core libraries are solid: Ktor, kotlinx.serialization, SQLDelight, and coroutines are widely adopted and production-ready. But the library landscape isn’t Flutter-level yet:

• Gaps remain for Bluetooth/BLE, Camera/AR, sensors, payments, and native media.
• Version mismatches between Kotlin and third-party KMP libraries are common, breaking builds during upgrades.
• No centralized plugin system like Flutter’s pub.dev or React Native’s npm. This means more expect/actual boilerplate and manual SDK bridging.

You can always drop to native for these gaps, but that flexibility comes at the cost of added complexity.

When Does KMP Deliver a Strategic Advantage?

KMP isn’t a shortcut. But when applied to the right kind of product, it delivers long-term value that compounds. The key factor is complexity in the logic layer, not the UI.

Kotlin Multiplatform is not a shortcut. But when applied to the right kind of product, it provides long-term leverage. The key is Choose KMP if:

• Your app has business rules that need to behave the same everywhere – no matter the platform. Things like syncing, geofencing, data transformations, real-time updates, rule engines. 
• UI/UX consistency is critical. Finance apps, logistics systems, collaboration tools – even small mismatches can turn into bugs, confusion, or worse, security issues. 
• You need native UI quality but want to avoid writing business logic twice.
• Your cross-platform product is built to scale and evolve over time, not just reach the market quickly.

When Should You Avoid or Delay KMP?

There are clear signals that KMP is the wrong fit for your current situation:

• You’re building a short-term MVP, and speed matters more than architecture. Consider Flutter for startups instead.
• Your app is 90% UI-focused with minimal logic to share.
• Your teams are siloed, and collaboration between iOS and Android is weak.
• You rely heavily on native SDKs or low-level platform integrations (ARKit, HealthKit, GPS).
• You lack the time or appetite to troubleshoot edge-case build or CI issues.

In those cases, a well-executed native build or Flutter prototype may serve you better for now. KMP isn’t going anywhere – you can adopt it incrementally when the time is right.

Which Production Apps Use Kotlin Multiplatform?

KMP runs in production at some of the largest companies in the world. These aren’t experiments – they’re shipping to millions of users daily.

Forbes

Forbes shares over 80% of business logic, such as networking, data models, and serialization, between Android and iOS apps using KMP, according to the case study on Kotlin’s website. This lets their teams ship feature updates simultaneously on both platforms while keeping platform-specific customization where it matters.

Netflix

In their recent article, JetBrains emphasizes that Netflix uses KMP in their Studio apps to share core business logic, such as media processing, user workflows, and content management, across platforms. The shared codebase reduces duplication and speeds up their internal tool development cycle.

McDonald’s

McDonald’s expanded KMP from an initial sharing of business logic for payments to their entire global mobile app. Now, all non-UI app logic, such as networking, ordering, and promotional rules, is shared through KMP. According to insights from the KotlinConf 2025, the app processes 6.5 million monthly purchases and serves 69 million daily customers.

Cash App

According to the JetBrains case study, Cash App has run KMP in production since 2018, making them one of the longest-running adopters. As the top financial app in the United States, they handle critical financial transactions, key business rules, and networking with KMP-powered shared code across platforms. 

The Bottom Line

By 2026, Kotlin Multiplatform has moved past the “maybe later” stage for a lot of teams. It is already a solid, production-ready framework, backed by Google and JetBrains, and running in production at scale. The key question here is whether KMP fits your product. 

Even though the framework still has some drawbacks and limitations, it is maturing at a solid pace. Since the 1.8.0 release, Compose Multiplatform has rapidly evolved the framework’s capabilities for building a solid shared UI. Moreover, JetBrains is currently working on Swift Export that would give KMP direct access to Swift-only APIs without any Objective-C breaches. 

Think of KMP as a scalable architecture for logic-heavy products that demand consistency across platforms. It won’t replace your native teams. It will help them move faster, reduce duplication, and ship cleaner code – when the app demands it. At Volpis, we’ve used Kotlin Multiplatform in production on several real projects. One example is our Purple ConneX case study, where we built a community-driven app for quick access to verified public Wi-Fi hotspots. These projects gave us enough real-world experience to be confident that KMP is solid and production-ready.

FAQs