JetBrains just shipped Compose Multiplatform 1.11.0, and buried in the release notes is a quiet admission: cross-platform UI toolkits have a credibility problem on iOS, and they’re finally doing something about it. Native UIView-backed text input, concurrent rendering on by default, and a rewritten touch pipeline for the web aren’t headline features — they’re the unsexy plumbing that decides whether a Kotlin codebase can actually replace a Swift one. This release is less a feature drop and more a maturity statement.
Why Native iOS Text Input Is a Bigger Deal Than It Sounds
According to JetBrains, Compose Multiplatform 1.11.0 introduces an experimental native text input implementation built on top of UIView, bringing precise caret movement, native gestures and selection handles, and the system context menu — including Autofill, Translate, and Search. The existing cross-platform text input stays as the stable default; the native variant is opt-in.
This matters because text input is the single most-touched interaction on a phone, and it’s also where cross-platform toolkits get publicly humiliated. Users don’t file bugs that say “the magnifying glass loupe is missing” — they just feel that the app is off, and they trust it less. Autofill, in particular, is a conversion killer: if a login or checkout form doesn’t surface saved credentials or a one-time SMS code, completion rates suffer. Hooking into UIView means Compose apps inherit those behaviors instead of trying to reimplement them poorly.
If you’re a fintech team that has been forced to keep a native Swift module just for the login and KYC flows because the cross-platform text field couldn’t surface Autofill or the iOS system context menu, you can finally consider collapsing that back into a single Kotlin codebase. The prediction here is straightforward: within two releases, the native text input gets promoted out of experimental and becomes the recommended default on iOS, because once teams try it, going back will feel like a regression. Teams evaluating a cross-platform mobile stack now have one fewer reason to default to Swift-only for serious consumer apps.
Concurrent Rendering On By Default — and the Performance Story It Tells
The second iOS change is less flashy but more strategic. Concurrent rendering, introduced as an opt-in feature in version 1.8.0, is now enabled by default in 1.11.0. Rendering tasks are offloaded to a dedicated render thread out of the box, which means apps get the performance benefits without any extra configuration.
Flipping a perf flag from opt-in to default isn’t a small decision. It means JetBrains has enough telemetry and field data to claim the feature is safe for the median app — and it means new teams adopting Compose Multiplatform get the better default without having to know the feature exists. That’s how a toolkit graduates from “interesting experiment” to “reasonable production choice.” React Native spent years making its new architecture the default; JetBrains is doing the same, faster.
Picture a team shipping a media-heavy iOS app — a video catalog, a social feed, a maps view. Previously they had to know to opt into concurrent rendering and reason about thread safety in their composables. With 1.11.0, that performance ceiling moves up by default. Expect JetBrains to use this release as the foundation for a broader pitch at the next KotlinConf: Compose Multiplatform is no longer the “Android-first toolkit that also runs on iOS,” it’s the cross-platform toolkit that takes iOS seriously.
The v2 Testing API Is the Real Developer-Experience Upgrade
The headline-grabbing changes are on iOS, but the v2 ComposeUiTest APIs are what will save engineers hours of debugging. Per JetBrains, the v2 APIs change the default dispatcher to StandardTestDispatcher, so coroutines run in the order they’re queued — making tests more predictable and closer to production behavior. The APIs also accept an effectContext parameter for passing a custom coroutine context, useful for overriding the motion duration scale or supplying a test dispatcher. The previous runComposeUiTest, runSkikoComposeUiTest, and runDesktopComposeUiTest APIs are now deprecated.
If you’ve ever spent an afternoon staring at a flaky UI test that passes locally and fails in CI, you know exactly why this matters. Non-deterministic coroutine ordering is the classic culprit, and the previous default dispatcher made it too easy to write tests that depended on timing accidents. StandardTestDispatcher forces you to advance the clock explicitly, which is annoying for about a week and then makes your test suite an order of magnitude more trustworthy.
A team migrating a 500-test Compose UI suite will need a sprint to update assertions and clock-advancement logic, but the payoff is a CI pipeline that stops randomly failing on Mondays. The prediction: expect a wave of “migrating to Compose UI test v2” blog posts over the next quarter, and expect JetBrains to remove the deprecated APIs within two minor versions to force the issue.
Compose Web Finally Catches Up on Scrolling
The web target has historically been the weakest leg of the Compose Multiplatform stool, and scrolling was the most obvious gap. JetBrains says touch processing was overhauled in 1.11.0, and scrolling on Compose web now feels much closer to other platforms — with the new KotlinConf web app cited as a live demo, and CMP-9727 tracking the details.
Scrolling jank is the single most damning evidence that a web app isn’t really a web app. If you’re a SaaS team that wants to ship a Compose-based admin console alongside your Android and iOS apps — a tempting prospect for anyone running a multi-platform product — bad scrolling has been the disqualifier in stakeholder demos. With 1.11.0, Compose web moves from “interesting tech demo” to “plausible internal-tool target.” It’s still not going to replace React for marketing sites, but for authenticated dashboards where you already have a Kotlin backend and Kotlin mobile clients, the calculus shifts.
FAQ
Q: Should I switch my existing Compose iOS app to the new native text input? A: Not blindly. It’s experimental in 1.11.0, which means the API surface can change. Test it in a feature branch on your most input-heavy screens — login, search, forms — and ship it behind a flag if you depend on Autofill or the iOS system context menu. The stable cross-platform text input isn’t going anywhere.
Q: Do I need to migrate to the v2 Compose UI testing APIs immediately?
A: Yes, but plan for it. The old runComposeUiTest, runSkikoComposeUiTest, and runDesktopComposeUiTest are deprecated, and the StandardTestDispatcher change will surface latent timing bugs in your existing tests. Better to do that migration on your terms than during a forced upgrade later.
Q: Is Compose Multiplatform now a serious alternative to Flutter or React Native? A: For Kotlin-first teams, yes. For teams without existing Kotlin investment, it’s still a harder sell than Flutter or React Native because of the smaller talent pool. But the iOS gap that historically made the answer “no” is closing quickly with each release.
Key Takeaways
- Native
UIView-backed text input on iOS is the change that unlocks fintech, productivity, and any app where Autofill and the system context menu are non-negotiable — try it on a feature branch now. - Concurrent rendering being default-on is a maturity signal worth paying attention to when evaluating Compose Multiplatform for production use.
- The v2
ComposeUiTestAPIs will expose timing bugs that the old dispatcher hid — budget a sprint for the migration before the deprecated APIs are removed. - Compose web scrolling parity makes internal dashboards and admin consoles a realistic third target for Kotlin-first teams, not just a checkbox feature.
- Expect JetBrains to keep tightening the iOS story release by release; teams that wrote off Compose Multiplatform a year ago should re-evaluate against their current Swift-only baseline.