Two years after Google made its support official, Kotlin Multiplatform arrived at KotlinConf 2026 in Munich as a full-stack, AI-aware platform rather than “the Android language with an iOS attachment.”
Due to agentic engineering, I often think of code as just an abstraction layer. Agents will take care of it while I make decisions on higher levels. Still, native vs. cross-platform is a question that keeps coming up when talking about mobile development, and even though this article is about KMP, let’s start with a case for native.
We believe in it because it allows the use of platform-authentic UX, has day-one access to new OS features, on-device AI, and overall fewer compromises. And since code is just an abstraction layer, why wouldn’t you just write high-quality, professional code, right?
The KotlinConf keynote was not just a mobile update, but from a mobile dev perspective, I appreciate that we can count on end-to-end support from the Kotlin stack when choosing KMP. JetBrains framed Kotlin as a delivery platform across mobile, backend, web, AI agents, typed contracts, and tooling. The KMP-specific news mostly targets iOS, which makes sense: Android has been a first-class Kotlin platform since 2017, so the work that remained was on the other side.
The pieces now line up: a stable core (language, Ktor, Exposed, klibs.io) with the newest iOS and AI parts still in Alpha or Beta. The point is that they all aim in the same direction.
Koog 1.0: AI agents in idiomatic Kotlin
The headline AI announcement was Koog 1.0 being marked generally available. This framework for fault-tolerant, enterprise-ready agents matters because it keeps agent work inside the Kotlin ecosystem instead of forcing teams to stand up a parallel Python service for every AI feature. The agents run across backend, mobile, and the browser, with the things production teams expect: observability, the freedom to switch LLM providers, and support for the emerging protocols that let tools and agents talk to each other.
Durable execution and running offline are the icing on the cake. Agents can checkpoint a workflow node and resume from the same step after a crash so that even heavily regulated clients’ expectations are met, while Google’s Gemma models allow on-device, offline workflows on Android.
Python and Node.js are still first-class citizens for us when it comes to AI agents, but with an end-to-end Kotlin stack, these capabilities will be important. We’ll see how Koog turns out, but from the look of things, observability and persistence are the parts we would want to lean on first.
Junie, Air, ACP, and Claude: AI tooling moves into the workflow
Cross-platform work carries real plumbing: build configuration, Xcode setup, wiring Kotlin and Swift together, and keeping tests in sync. AI tooling is starting to absorb the repetitive parts.
KotlinConf covered the Agent Client Protocol (ACP), an open IDE-to-agent protocol with around ten launch agents; Junie, JetBrains' coding agent, positioned with no vendor lock-in; Air at air.dev for running agents in parallel inside isolated worktrees; and deeper Claude integration in IntelliJ and Android Studio.
This is an interesting angle, because the initial value proposition of both cross-platform frameworks and agentic engineering (on a certain level of abstraction) was to reduce workload and automate whatever we can. If you can generate high-quality native code, the incentive of writing lower-quality “shared-everything” code to save effort gets smaller, even if you automate it.
On a JetBrains-run Kotlin coding-agent benchmark (SWE-Bench) of 110 real engineering tasks, the best Claude configuration resolved 86.4%. It is a vendor-run number, best read as "this gets most everyday Kotlin tasks done" rather than a precise score.
For KMP specifically, agents are useful on the boring parts: generating expect / actual scaffolding, explaining a shared module, writing test doubles, and building DTOs from a contract.
I recently built a fairly serious iOS app with heavy AI assistance in a very short time. The honest takeaway was not "anyone can vibe-code any app." It needed an engineering mindset and years of iOS experience to steer. The pattern I keep seeing: the people who can mechanize their accumulated experience get the work done, increasingly on behalf of the people who cannot. Architectural judgment and domain knowledge are being revalued upward, not down.
Kotlin Toolchain, LSP, and the KMP plugin: a less fragmented setup
KMP's historical weak point has always been the environment, from Gradle configuration to source sets, Xcode integration, and IDE setup. The conference addressed that directly.
They announced the Kotlin Toolchain (Alpha) as a single entry point for creating, building, running, testing, formatting, and documenting Kotlin projects; promoted the Kotlin Language Server to Alpha; published an official Kotlin extension for VS Code; and described standardizing ktfmt as the default formatter through the Kotlin Foundation. The KMP IDE plugin now runs on every OS for IntelliJ IDEA and Android Studio, with Compose tooling, Swift and cross-language features, and AGP 9.0 support, and the project wizard ships a cleaner default module structure.
As build discipline and foundational decisions affect every app you develop down the line, stable, predictable tooling matters more for multiplatform than for single-platform work. Each framework has its benefits and drawbacks—even with all its advantages in shared logic and allowing longer product lifecycles, iOS compatibility is still a key issue when it comes to KMP, for example. I’ll share a detailed comparison of the most popular frameworks very soon.
Ktor, kotlinx-rpc, and .proto: the backend joins the story
KMP gets more compelling when the backend is also Kotlin. Ktor 3.5.0 shipped in May 2026 with the usual round of authentication and networking improvements. More interesting is kotlinx-rpc, whose developer preview adds experimental first-party gRPC and Protocol Buffers support. You point it at a service definition (a .proto file) and it generates ready-to-use Kotlin clients across every supported platform, including async calls and streaming.
If you have used tRPC in the TypeScript world, this is the same end-to-end developer experience: define the contract once and get typed clients without hand-written glue. A Kotlin stack can now carry shared models and typed contracts from the backend through to Android and an iOS shared module.
Kotlin 2.4 speaks better Swift
I've worked more with iOS than Android, and perhaps this is KMP's weakest point, which is why I was really looking forward to the following announcements.
Kotlin 2.4.0-RC firmed up several language features, but the interop work is what closes old objections. It improved Swift package import, added Swift Export for coroutine Flow types, and improved TypeScript/JavaScript interop. The iOS pieces are the ones that matter most:
- Swift Export (Alpha): suspend functions map to Swift async functions and Flow maps to AsyncSequence, so Kotlin no longer has to bridge through an older Objective-C translation layer that produced un-Swift-like APIs.
- SPM import (Alpha): you can add a Swift Package Manager dependency from build.gradle.kts and call it from iOS-specific Kotlin; the keynote demo pulled in the Google Maps iOS SDK without a community shim.
This does not mean Swift interop is "done." It is Alpha, and for production iOS interop today, established tools such as SKIE remain the safer bet. But one of the oldest KMP complaints is finally being reduced by first-party tooling.
Performance, structure, and native capabilities
Fast iterations in building and validation is an important factor for both manual and agentic engineering, which is why this kind of improvement carries more weight than it looks: JetBrains reported that Kotlin/Native builds on the Google Docs codebase are 25% faster while using less than half the RAM compared with a year earlier.
JetBrains' new default project structure, which splits the old monolithic composeApp module into a shared library module plus separate platform app modules (androidApp, iosApp, desktopApp, webApp). It’s definitely a cleaner architecture and way better in terms of DX (unified @Preview, Navigation 3, stable Compose Hot Reload).
Compose Multiplatform is stable on mobile and desktop and in Beta on web.
klibs.io and ecosystem maturity
Library maturity was a fair criticism in earlier KMP conversations. JetBrains reported more than 3,600 community libraries on klibs.io, the search-and-discovery service that indexes GitHub and Maven Central and adds metadata about platform support, up from a few hundred in 2022.
Adoption and productivity signals
Four figures JetBrains presented in Munich. No single one proves much; together they explain why the 2026 conversation feels different.
Trust from flagship products is a frequent question when pitching a certain platform to clients. And let’s face it, it’s an important factor to consider. I, personally, wouldn’t put all my eggs in a basket that hasn’t already proved itself. KotlinConf was convincing in this aspect. These are JetBrains-reported numbers, though, so read them as direction rather than independent measurement.
KMP use in top 10k apps roughly doubled in a year from March 2025, with brands such as McDonalds, Booking, Duolingo, Sony, and Google using it in production (Docs on web and iOS runs on KMP, too!). Discoverability is improving with 3600+ libraries on klibs.io, while development cycles are up to 20% shorter compared to Java.
On top of this, other parts of the stack are also in use in several industries. Mercedes-Benz and Anthropic use Kotlin’s AI and agent capabilities, while Amazon and Google Search use Kotlin as backend and server-side systems.
Not every brand uses KMP the same way. Some share business logic, some use Compose Multiplatform, some use Kotlin only on the backend, and a few are AI or tooling signals rather than mobile-architecture ones. The point is that Kotlin is no longer confined to Android, and the production proof now spans mobile, backend, AI, and tooling.
Mature enough, but iOS needs some work
In the second part of this article, I’ll take a deeper look at how KMP compares to other cross-platform frameworks. One thing is certain: KMP is mature enough to build a production app on.
However, it still has rough edges, mostly stemming from the iOS side. When building multi-platform, you still need iOS expertise, build discipline and deliberation, and Swift interop is still a WIP. If you’re iOS only, KMP might still be overhead you don’t need.
Overall, the conference left me with the impression that not only is Kotlin in full swing and that they intend for KMP to go big this year, the community is also with them on the ride. People are optimistic for good reason; there’s a bunch of challenges ahead, but from AI capabilities to tooling, end-to-end integration of development, and lightning-fast prototyping, we’ll have what we need to leave a mark.
