← All release notes
Kotlin MultiplatformCompose MPMay 13, 2025 · 5 min read

Compose Multiplatform: iOS Support Matures

Compose Multiplatform 1.8 makes iOS a stable, production-ready target for sharing UI code, not just business logic, from Kotlin.

Kotlin Multiplatform went stable for sharing business logic in November 2023. UI stayed native on both platforms.

Compose Multiplatform 1.8.0, released in May 2025, moves that boundary. iOS support is now stable and production-ready, which means you can genuinely choose to share UI code between Android and iOS in Kotlin, not just the logic underneath it. That's a bigger claim than a version bump. Worth being precise about what "stable" covers.

#What stable actually covers

1.8.0 finalizes the core API surface for the iOS target, with targeted work on accessibility and navigation plus the usual round of bug fixes and performance improvements. JetBrains is explicit that this covers feature parity with Jetpack Compose "for popular use cases." Not every Jetpack Compose API has an iOS-ready equivalent. The common set most screens actually use does.

#It renders through Skia, not through UIKit

Compose Multiplatform doesn't translate your Kotlin UI into UIKit views. It renders through Skia, the same 2D graphics library backing Jetpack Compose on Android, onto a native surface on iOS.

That's why a Compose Multiplatform screen looks pixel-identical across platforms. Same renderer, same drawing instructions, rather than two different UI toolkits trying to agree.

@Composable
fun WeatherCard(weather: Weather) {
    Column(modifier = Modifier.padding(16.dp)) {
        Text(weather.city, style = MaterialTheme.typography.titleLarge)
        Text("${weather.tempC}°C")
    }
}

That composable compiles and renders unmodified on both platforms. No platform branch, no expect/actual needed for the UI itself.

#Type-safe navigation, with deep linking

1.8.0 brings type-safe navigation with deep link support to the iOS target, matching what Jetpack Compose's navigation library already offered on Android. If your app's navigation graph was a reason to keep iOS UI native, that reason is weaker now. Compile-time-checked destinations and deep linking on both platforms, from the same navigation code.

#Accessibility gets real platform support

VoiceOver, AssistiveTouch, and Full Keyboard Access support land in this release.

Shared UI code has historically been where accessibility lagged, because it's exactly the kind of platform-idiom detail that's easy to skip when you're focused on getting pixels to match. First-class support for iOS's actual assistive technologies, rather than a lowest-common-denominator abstraction, is what makes "stable" a credible claim here rather than a marketing label.

#UIKit interop for incremental adoption

You don't have to rewrite an existing iOS app's UI in one move. The interop APIs let you embed a Compose screen inside an existing UIKit view hierarchy, or drop a UIKit view into a Compose layout. A team can convert screen by screen instead of committing the whole app up front.

#What to adopt first

  1. Already have a KMP module sharing business logic? Pilot Compose Multiplatform on one net-new screen before touching anything existing, and pick something without heavy platform-specific chrome.
  2. Use the UIKit interop APIs to convert an existing app incrementally. Don't attempt a big-bang UI rewrite even though the target is now stable.
  3. Test with VoiceOver on real iOS hardware before shipping any converted screen. "Supported" doesn't mean "identical to what your accessibility QA process already expects from native UIKit."
  4. Keep an eye on which specific Jetpack Compose APIs you depend on. "Feature parity for popular use cases" is not full parity, and an exotic API might still be Android-only.
  5. On a team that's already fast and happy in native SwiftUI, this is no reason to abandon it. Compose Multiplatform is now a legitimate choice for shared UI, not the only defensible one.