Compose Multiplatform: sharing Kotlin UI code across iOS, Android, desktop and web

The duplication problem Compose Multiplatform is aimed at

A product that ships on Android, iOS and desktop usually carries three UI codebases with three rendering models. Compose Multiplatform attacks that by making the UI layer itself shareable. The README describes it as "a declarative framework for sharing UI code across multiple platforms with Kotlin", based on Jetpack Compose and developed by JetBrains with open-source contributors.

The audience is therefore narrow and specific: Kotlin teams that already accept Kotlin Multiplatform for non-UI code and now want the screens to travel too. If your app is a single-platform Android product, the framework adds a layer of indirection you do not need, because on Android the README says you get the same experience as developing with Jetpack Compose directly. The value only appears once a second target exists.

How the sharing actually works across targets

The mechanism is API-level reuse rather than a cross-compiled widget toolkit. The README states that Compose Multiplatform shares most of its API with Jetpack Compose, so the same APIs build interfaces for both Android and iOS. Underneath, the project sits on Kotlin Multiplatform, which is what lets you call native APIs such as the Camera API and embed native views such as MKMapView inside a Compose screen.

Each target is rendered differently. Desktop targets the JVM and the README describes hardware-accelerated rendering on macOS, Windows and Linux, plus desktop extensions for menus, keyboard shortcuts, window manipulation and notification management. Web is a separate path: it is based on Kotlin/Wasm, which the README presents as giving predictable performance in the browser. That is three rendering stories behind one API surface, and it explains why platform behaviour differs even when your composables do not.

There is also a library that breaks the pattern. Compose HTML targets Kotlin/JS and provides composable building blocks for HTML and CSS, but the README states plainly that it is not a multiplatform library and can only be used with Kotlin/JS. Treat it as a separate tool that happens to live in the same repository.

Getting started with Compose Multiplatform

The README does not spell out Gradle coordinates. Every platform section ends with the same pointer, a "Get started with Compose Multiplatform" link to jb.gg/start-cmp, and the repository keeps tutorials in tutorials/ and runnable projects in examples/. Rather than guess at versions, use the wizard path the project links to and then read the example that matches your target.

The examples are organised by scenario. The repository lists them under examples/, including examples/imageviewer for a desktop-style app, examples/nav_cupcake for navigation, examples/interop for embedding native views and examples/html for the Kotlin/JS library.

The repository also ships validation scripts that show how each example is expected to build. The example directory contains examples/validateExamples.sh, examples/validateExamplesAndroid.sh, examples/validateExamplesIos.sh and examples/validateExamplesWithJs.sh. Reading the one that matches your target is a faster way to learn the supported invocation than reverse-engineering a build file.

If you are adding Compose Multiplatform to an existing Kotlin Multiplatform project instead of starting from a sample, follow the compatibility page the README links as jb.gg/cmp-versioning before editing your version catalog, because the framework version and the Kotlin version are not independent choices. For the release you build against, the README points at the releases page and the CHANGELOG.md at the repository root.

Where the framework is genuinely not ready

Web is the weak target, and the README says so without hedging. It carries a Beta label, framed as "a great time to give it a try", with feedback directed to the public Slack channel #compose-web and issues to YouTrack under project CMP. Beta is not a synonym for unsupported, but it does mean you should not plan a production browser release around it without checking the current state yourself.

The second limitation is structural. Compose Multiplatform shares UI code, not platform behaviour. The README's own examples of going native, the Camera API and MKMapView, exist precisely because the shared layer does not cover everything. Anything touching platform services, permissions or deeply native widgets will need per-platform work, and that work does not shrink as the shared portion grows.

The third is versioning. The repository carries a VERSIONING.md and a compatibility page, which is a signal that the version matrix matters. The recent release list shows v1.13.0-alpha01, v1.12.0 and v1.12.0-rc01 within weeks of each other, so a team that pins loosely will absorb prerelease churn. If you need a predictable upgrade cadence, this is a framework you pin deliberately.

Compose Multiplatform against Flutter and React Native

The obvious comparison, and one people search for directly, is Flutter. Flutter ships its own rendering engine and its own widget set, so the UI looks the same everywhere and the framework owns the pixels. Compose Multiplatform takes the opposite route: it reuses Jetpack Compose's API surface and renders per platform, with desktop on the JVM and web on Kotlin/Wasm. The practical difference is that Flutter asks you to adopt Dart and a Flutter-shaped mental model, while Compose Multiplatform asks you to adopt Kotlin and, on Android, gives you what is effectively stock Jetpack Compose.

React Native differs again. It drives native platform views from JavaScript, which keeps the platform look but makes the bridge the centre of gravity. Compose Multiplatform does not route through a JavaScript bridge; it compiles Kotlin to each target and renders through its own stack per platform, with Kotlin Multiplatform as the mechanism for reaching native APIs when the shared layer runs out.

The honest framing: if your team is not already invested in Kotlin, the switching cost of Compose Multiplatform is higher than the alternatives, because you are buying into the Kotlin ecosystem, not just a UI library. If your team is Kotlin-first, the calculation inverts, since the shared UI sits on top of a language and toolchain you already run.

Maintenance, licensing and what an upgrade costs

The repository is not archived and the last push was on 2026-09-19, so the project is under current development. The release cadence is visible in the tags: v1.12.0 shipped on 2026-08-25, its release candidate on 2026-08-11, and v1.13.0-alpha01 on 2026-09-10. That is a stable line, a prerelease line and an alpha line running in parallel, which is normal for a framework with this many targets but does mean you must decide which line you track.

Licensing is Apache-2.0, with the licence text at LICENSE.txt and a license/ directory at the repository root. Apache-2.0 is a permissive licence that permits commercial use and modification, but this is not legal advice and the terms that matter to you depend on how you distribute the application, so read LICENSE.txt and any notices in license/ before shipping.

Upgrade cost is the part teams underestimate. Because the framework shares APIs with Jetpack Compose and depends on Kotlin Multiplatform, a version bump can move three things at once: the Compose Multiplatform version, the Kotlin version, and the platform toolchains behind each target. VERSIONING.md and the jb.gg/cmp-versioning page exist to describe that relationship. Budget the upgrade as a coordinated change across targets, not a single dependency bump.

Editorial conclusion

Adopt Compose Multiplatform when your team already writes Kotlin and wants one declarative UI layer over Android, iOS and desktop; the iOS and desktop targets are the mature part of the story. Do not adopt it to share a single UI across web, since the README labels web support Beta and points feedback at #compose-web. Before committing, read VERSIONING.md and the compatibility page linked as jb.gg/cmp-versioning, because the release line already includes v1.13.0-alpha01 alongside the stable v1.12.0.

Frequently asked questions

Official sources

1. JetBrains/compose-multiplatform on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases