Compose Multiplatform's iOS target left beta with JetBrains' 1.8.0 release in May 2025, and the project has kept shipping since: version 1.12.1 went out on September 22, 2026, with an early-access 1.13.0-alpha01 build already out on September 10. iOS carries JetBrains' Stable badge, and JetBrains calls the framework production ready for mobile and desktop. Web is still Beta. That split matters more than a single yes-or-no verdict, because whether Compose Multiplatform is ready for you depends entirely on which platform you're shipping to first.
What Compose Multiplatform actually is
Compose Multiplatform is JetBrains' UI framework, built on Google's Jetpack Compose, for writing a UI once in Kotlin and targeting Android, iOS, desktop, and web from that single codebase. It sits on top of Kotlin Multiplatform, which already lets teams share business logic across platforms; Compose Multiplatform extends that sharing up into the UI layer itself, instead of stopping at the logic underneath it. For the full picture of how Kotlin Multiplatform shares code beneath the UI, the full Kotlin Multiplatform guide covers that layer in depth.
Platform stability in September 2026: iOS, desktop, web
JetBrains' Compose Multiplatform product page badges iOS "Stable," badges desktop for Windows, macOS, and Linux, and calls the framework production ready for mobile and desktop. Web carries a "Beta" badge on the same page.
iOS reached that Stable badge with the 1.8.0 release. JetBrains' Compose Multiplatform 1.8.0 announcement states that all major APIs are now officially stable, with strong compatibility guarantees.
The Compose Multiplatform release history on GitHub shows a steady cadence rather than a one-off push: 1.12.0 shipped August 25, 2026, 1.12.1 followed September 22, and 1.13.0-alpha01 is already out for testing. The latest stable release added more than bug fixes. JetBrains' Compose Multiplatform 1.12.0 release notes describe an experimental Model Context Protocol server shipping with Compose Hot Reload, which connects AI coding agents to a running app, plus a web update that downloads matching Noto font subsets on demand so Japanese, Arabic, Devanagari, and emoji render correctly without bundling fonts by hand.
What's shared vs what stays native
Compose Multiplatform doesn't force a rewrite to get started. JetBrains' interoperability notes for existing native code describe keeping existing SwiftUI, Android Views, or Swing code in place rather than replacing it, and reaching native APIs for things like maps, camera, and video directly from the shared codebase without giving up performance or user experience.
That's a different starting point than a full rewrite of the UI layer. A team can adopt Compose Multiplatform screen by screen, next to native code that already works, rather than committing the whole app on day one.
Performance and interop with SwiftUI and UIKit
The 1.8.0 release notes carry most of the performance data JetBrains has published. In that same release's performance and production figures, JetBrains reports startup time comparable to native apps, scrolling performance on par with SwiftUI even on high-refresh-rate devices, and a size overhead of roughly 9 MB added to an iOS app compared with a fully native SwiftUI build with the same UI logic and assets. JetBrains' own survey found over 96% of teams running Compose Multiplatform on iOS reported no major performance concerns.
The same release also improved interop with SwiftUI and UIKit, making it easier to embed Compose views inside an existing app or drop native views into a Compose screen. JetBrains names four production users in the same post, Markaz, Wrike, Feres, and Physics Wallah, and notes that Respawn's iOS app is built with Compose Multiplatform while sharing 96% of its code with the Android version.
Compose Multiplatform vs Flutter: the actual differences
Both frameworks solve for shared UI, but the mechanics diverge. JetBrains' own comparison of Kotlin Multiplatform and Flutter lays out three: Flutter renders widgets through its own Impeller engine, talking directly to the GPU via Metal, Vulkan, or OpenGL depending on platform. Compose Multiplatform renders through Skia instead, compatible with the same set of graphics APIs plus ANGLE. On code sharing, Flutter is built around sharing 100% of the codebase and controlling every pixel; Kotlin Multiplatform and Compose Multiplatform let a team share anywhere from 1% to 100%, business logic only, UI only, or both. And native API access differs structurally: Kotlin code reaches native APIs directly through expect/actual declarations, where Flutter routes that communication through platform channels.
None of that makes one framework strictly better. It's the same tradeoff HighCircl's broader comparison across SwiftUI, Jetpack Compose, Flutter, and React Native walks through for the wider framework decision, and the case for Flutter instead still holds if a single, consistent look across every platform matters more to you than native-feeling UI on each one.
What this changes for staffing
Because Compose Multiplatform shares the UI layer and not just business logic, an Android engineer who already writes Jetpack Compose can extend directly into iOS UI work. The component model, state handling, and most of the API surface carry over between platforms. That's a different staffing shape than plain Kotlin Multiplatform, where business logic is shared but each platform still gets its own UI written by hand, twice.
HighCircl doesn't run a separate hiring line for Kotlin Multiplatform or Compose Multiplatform. Teams hire HighCircl's Android and iOS engineers, the same engineers who'd be writing the shared UI day to day, rather than hiring for a framework name that doesn't map to a distinct job title. HighCircl's own KMP developer, in an earlier interview, put it plainly: Android developers pick up Compose fast because they already work in Kotlin and Compose day to day, while iOS developers face a steeper climb but benefit from Swift and Kotlin's syntactic similarity.
If shared UI matters more to you than native-feeling UI on each platform, hiring a Flutter engineer instead covers the competing staffing path, one engineer, one codebase, one UI layer built in Dart rather than Kotlin.
How to decide if Compose Multiplatform fits your team
1. Audit your current UI stack
Check what you're actually starting from. A team with existing native SwiftUI or Jetpack Compose screens can adopt Compose Multiplatform incrementally, screen by screen. A team starting from scratch has more freedom but less to lean on while ramping up.
2. Check whether your web/desktop targets can tolerate Beta
Web carries a Beta badge on JetBrains' own product page, while iOS is badged Stable and JetBrains describes mobile and desktop as production ready. If a web target is on your roadmap this year, decide now whether Beta status is acceptable for your launch date or whether it pushes web out to a later phase.
3. Pilot one screen with interop before a full migration
Compose Multiplatform's interop model lets existing SwiftUI, Android Views, or Swing code sit alongside new Compose screens. Pick one real screen, build it in Compose, and ship it next to the native code that's already working before committing the rest of the app.
4. Reassess the hiring plan
Decide whether the pilot is a job for your existing Android and iOS engineers or a reason to bring in additional help. Because the UI layer is shared, the same engineers who'd write native Android and iOS screens can usually take this on directly, which changes what the hiring plan needs to solve for.
Frequently asked questions
Is Compose Multiplatform stable for iOS?
Yes. JetBrains marked iOS Stable starting with the 1.8.0 release in May 2025, stating that all major APIs are officially stable with strong compatibility guarantees. The framework has shipped multiple releases since, most recently 1.12.1 on September 22, 2026.
Is Compose Multiplatform ready for production on the web?
Not yet by JetBrains' own labeling. The web target carries a Beta badge on JetBrains' product page as of September 2026, while iOS is badged Stable and JetBrains describes mobile and desktop as production ready.
How is Compose Multiplatform different from Flutter?
Compose Multiplatform renders through Skia and shares a scalable slice of the codebase, from 1% up to 100%, letting a team choose what to share. Flutter renders through its own Impeller engine and is built around sharing 100% of the UI. Compose Multiplatform reaches native APIs directly through Kotlin's expect/actual declarations; Flutter routes that through platform channels.
Can an Android developer write Compose Multiplatform code for iOS?
Largely, yes. Because Compose Multiplatform shares the UI layer built on Jetpack Compose, an Android developer who already knows Compose carries most of that knowledge into iOS UI work. iOS developers coming from Swift face more of a learning curve, though Swift and Kotlin's similar syntax, and SwiftUI and Compose's shared declarative model, shorten it.