Kotlin 2.2.20 introduced direct Swift export, removing a long-standing friction point in Kotlin Multiplatform (KMP): until now, Kotlin code calling into Swift, or Swift calling into Kotlin, had to pass through an Objective-C bridging layer that Apple’s own tooling never fully embraced. JetBrains is targeting stable Swift interoperability within 2026, and pairing it with recent Compose Multiplatform improvements — roughly 25% faster builds, less than half the memory usage, and a default garbage collector switch for Kotlin/Native.
We flagged KMP back in June as it tripled its share of cross-platform mobile projects from 7% to 23% in eighteen months. This release addresses the specific complaint that held teams back from adopting it fully: the Objective-C bridge added real friction to shipping native SwiftUI screens against a shared Kotlin logic layer, and made the tooling feel less mature than the numbers suggested. Removing it doesn’t change who KMP is for — it’s still the framework for teams with an existing Kotlin or Java backend who want native UI on both platforms rather than one shared UI codebase — but it closes the gap between KMP’s adoption growth and its day-to-day developer experience.
It’s a small technical change with a real commercial consequence: fewer build errors and bridging workarounds mean less engineering time spent on plumbing rather than features, which shows up directly in delivery cost for any project built on the framework.
So what
If you’re weighing Flutter, React Native, or Kotlin Multiplatform for a new build — or you already have a KMP project that’s been fighting the Objective-C bridge — this is the kind of tooling maturity signal that should factor into the decision or the roadmap conversation. Framework selection isn’t a one-time choice; it’s worth revisiting as the tooling changes under a project. Our iOS & Android development services cover how we approach that evaluation, or get in touch if you’re at the point of choosing a stack.