Is Kotlin Multiplatform production-ready? Every status, dated

Yes, for an app that ships on Android and iOS. JetBrains declared Kotlin Multiplatform Stable on 1 November 2023, Google has officially supported it for sharing business logic between Android and iOS since 14 May 2024, and Compose Multiplatform for iOS went Stable with version 1.8.0 on 6 May 2025. What is not production-ready yet is narrower than most older answers suggest: Swift export is Alpha, and the web target built on Kotlin/Wasm is Beta, as are watchOS and tvOS.

Most of what turns up when you search this question was written before one or more of those dates, so this post puts a date and a primary source next to every status. Each one was re-checked on 3 October 2026. It closes with how the studio, which builds Kotlin Multiplatform apps for iOS and Android for clients, would start one today.

Every status on one page

The latest Kotlin release is 2.4.20, released 7 September 2026, according to the Kotlin releases page. The latest Compose Multiplatform is 1.12.1, listed on the compatibility page (modified 22 September 2026) and tagged on GitHub the same day.

What JetBrains means by Stable, Beta and Alpha

These words have exact meanings in Kotlin, and the gap between them is the whole answer. The stability levels page defines them:

• Stable: "use it even in most conservative scenarios". JetBrains will evolve it "according to our strict backward compatibility rules".
• Beta: "you can use it, we'll do our best to minimize migration issues for you". It is "not 100% finished, so changes are possible".
• Alpha: "use at your own risk, expect migration issues".
• Experimental: "try it only in toy projects".

So "production-ready" in this post means Stable. Beta can go into a product if you accept a migration later. Alpha belongs behind a decision someone has written down.

Core Kotlin Multiplatform: Stable since November 2023

JetBrains' announcement of 1 November 2023 says Kotlin Multiplatform "has become Stable and is now 100% ready for use in production", and that the common code-sharing use cases "are stable in Kotlin 1.9.20" (source).

On today's stability page, Android, iOS, desktop (JVM), server-side (JVM) and the Kotlin/JS web target are Stable. The Kotlin/Wasm web target, watchOS and tvOS are Beta.

One change from this year affects iOS apps directly. What's new in Kotlin 2.4.0 raises the default minimum iOS and tvOS version from 14.0 to 15.0, macOS from 11.0 to 12.0 and watchOS from 7.0 to 8.0. If your app still supports iOS 14, you have to override that in the build file. The same page shows how.

Google's position: officially supported for business logic

On 14 May 2024 the Android Developers Blog announced that Google was supporting Kotlin Multiplatform on Android, with the focus on "sharing business logic (the parts that are most agnostic to the user interfaces)" (source). At the time, Room, Lifecycle and ViewModel had multiplatform support only in alpha. Answers written then still say so, and they are out of date.

Google's Kotlin Multiplatform page, last updated 23 September 2026, now says KMP "is officially supported by Google for sharing business logic between Android and iOS" and that it "is stable and production-ready". It lists the Jetpack libraries that ship iOS targets. A selection from that table:

Room is the only library in Google's table without a web target. For Compose, viewModel-compose and the three navigation libraries, the table credits the iOS, desktop and web builds to JetBrains rather than Google.

In practice, the persistence, lifecycle and state layers most Android teams already use now compile for iOS from the same source. That is usually the largest share of an app's logic.

Shared UI: Compose Multiplatform for iOS has been Stable since May 2025

Compose Multiplatform 1.8.0 was published on 6 May 2025. JetBrains' release post says it "brings Compose for iOS to Stable" and that "all major APIs are now officially stable". It lists VoiceOver, AssistiveTouch and Full Keyboard Access under accessibility support.

The post also gives a size figure, and the figure is JetBrains' own: Compose Multiplatform "adds only ~9 MB to the size of an iOS app compared to a fully native SwiftUI app with the same UI logic and assets". It applies to apps that draw their UI with Compose. It says nothing about an app that shares only logic.

The KMP FAQ (modified 1 October 2026) answers the production question directly: "The Android, iOS, and desktop targets of Compose Multiplatform are Stable. You can use them in production." The Wasm-based web version is Beta, which JetBrains' KotlinConf'26 keynote highlights (21 May 2026) say it reached in September 2025.

Two answers in the same FAQ matter when you choose shared UI on iOS:

• Compose screens can go into an existing iOS app, and UIKit or SwiftUI views can go inside a Compose screen. You do not have to choose one or the other for the whole app.
• On OS updates, the FAQ says "your UI will stay the same after the OS updates because all of the components are drawn on a canvas". That is stable, but it also means a Compose screen will not take on a new iOS system look on its own. Native views you embed will.

What is not stable yet: Swift export

This is the one piece most likely to shape how the iOS team experiences the project.

By default, Kotlin reaches Swift through an Objective-C header. That works, but the FAQ says calling suspend functions and Flows from Swift "requires a little more work". Swift export is the replacement. It exports Kotlin directly to Swift, maps suspend functions to async and Flows to AsyncSequence, and drops the Objective-C name mangling.

Its status, from the docs page last modified 28 August 2026: "Swift export is currently in Alpha and still incomplete, so breaking changes are expected." It reached Alpha in Kotlin 2.4.0, which the releases page and the GitHub release both date to 3 June 2026. If you check this yourself: the "What's new in Kotlin 2.4.0" page currently shows 14 July 2026, which is the date the releases page gives for the 2.4.10 bug-fix release.

JetBrains' August 2025 roadmap update said: "In 2026, we aim for a stable release covering most features essential for idiomatic interoperability between Swift and Kotlin." As of 3 October 2026, that has not happened.

Until it does, the KMP FAQ still recommends libraries for calling coroutines from Swift: KMP-NativeCoroutines as "the more tried-and-tested solution", and SKIE as easier to set up, mapping Flow to AsyncSequence directly.

From the studio: The Swift side of a shared module, coroutines and Flows included, is part of the Kotlin Multiplatform work the studio takes on. If your iOS team is weighing this choice, describe the app through the contact form.

Tooling: what the iOS side still needs

• IDE. JetBrains recommends IntelliJ IDEA or Android Studio. The KotlinConf'26 post says the KMP IDE plugin is "available on all operating systems for both IntelliJ IDEA and Android Studio". If you install them through JetBrains Toolbox and the download crawls, this post explains why.
• A Mac. The FAQ is explicit: to write iOS-specific code and run an iOS app on a simulator or device, you need a Mac. The quickstart (modified 2 October 2026) adds that "to create iOS applications, you need a macOS machine with Xcode installed". That applies to CI too: any job that builds the iOS app needs a macOS runner. If Xcode's build phase cannot find a JDK that SDKMAN installed, this one-line fix makes /usr/libexec/java_home see it.
• Build speed. The August 2025 roadmap lists "Make the iOS target a pleasure to work with" as a key priority and says "build speed remains a common Kotlin/Native concern". JetBrains reported in May 2026 that Kotlin/Native builds measured on the Google Docs codebase are 25% faster than a year earlier while using less than half the RAM. That is JetBrains' measurement on one codebase, not a promise about yours.

Who uses it in production

The KotlinConf'26 keynote highlights name PayPal, Booking.com, Sony and Duolingo as companies "already using it in production", and say Sony shares the UI of its Sound Connect headphones app through Compose Multiplatform. Google's KMP page lists Blinkit, Cash App, Duolingo, Forbes, Google Docs, JioHotstar, Stone, Swiggy, Ultrahuman, Wrike and Zomato. For more examples, the KMP FAQ links JetBrains' own list of case studies.

What we would do with this today

None of the dates above require a rewrite. Our approach in October 2026:

1. Share logic first. Data, networking and business rules go into a shared module. This is the part Google supports and the part the Jetpack table above covers. The existing native apps keep shipping while it happens.
2. Use Compose Multiplatform screen by screen, where it pays off. It is Stable on iOS, and the interop runs both ways. A settings screen or an onboarding flow is a different decision from a screen built around a system component that changes with every iOS release.
3. Treat Swift export as Alpha. For a production app, keep the Objective-C export and choose one of the libraries the FAQ recommends. Try Swift export on a branch, and plan the move for when it goes Stable.
4. Pin versions and record why. A version catalog for a project started today, using only versions confirmed above:

[versions]
kotlin = "2.4.20"
compose-multiplatform = "1.12.1"
room = "2.8.5"
lifecycle = "2.11.0"
datastore = "1.2.1"

Check each one against its own release notes before you adopt it, rather than copying versions from a blog post, including this one.

Last checked

Every status, version and date in this post was checked against its linked source on 3 October 2026. Statuses move. Swift export is the one most likely to change next. If anything here disagrees with the page it links to, the linked page is correct.

Working with the studio

Abdelraouf Studios takes on Kotlin client work: Kotlin Multiplatform apps for iOS and Android, Compose Multiplatform for the UI, SDK development, and the release engineering underneath. That means one Kotlin codebase for two native apps, public Kotlin APIs and integration docs for teams embedding an SDK, and GitHub Actions, signing and staged rollouts. Work lands in your repository from the first commit, alongside your existing native code, so the app keeps shipping throughout.

If you are deciding whether KMP fits your app, send a short description of what you are building through the contact form. The reply comes from the person who would do the work.