Artikkeli
Nitor’s Senior Software Developer Huining Deng and Principal Software Architect Johan Paul spent two days in Munich for KotlinConf 2026. Two days later, they came back with a clearer picture of where Kotlin is heading. Here's what they each took away.
Johan: Four shifts worth watching
It was interesting days at the conference, and we left convinced of something. Kotlin is not 'the Java alternative' anymore, nor just 'the Android language' either. It's become a serious choice for AI-native, backend, and multiplatform work.
Four shifts stood out to me, and I think they'll reshape how a lot of us work.
1. Kotlin Multiplatform: The iOS experience matures
Kotlin Multiplatform (KMP) has evolved significantly since its 2017 debut. Within the last year alone, the presence of KMP-powered applications in app stores has doubled. While the 1.0 release in 2023 established stable tooling, this year marks KMP's arrival on the main stage through the maturation of its iOS integration. Between JetBrains and Google, the message was hard to miss: KMP is ready for production at real scale.
Google leaned in hard: they brought KMP into Google Workspace to share business logic across the Android and iOS versions of Google Docs. Following this migration, build processes for Google Docs have seen a 25% reduction in duration and a 58% decrease in memory consumption.
Sergio Carrilho, Tech Lead on Sony's Sound Connect, told a similar story. They adopted KMP back in its alpha days (not without pain) and now ship a single shared codebase to millions of users on both platforms.
Mobile UI performance has also been notably boosted over the last year by a new rendering pipeline for iOS. By leveraging a background thread for UI rendering, the main thread remains unblocked, resulting in a more fluid user experience. This is the kind of thing that used to be the asterisk on every KMP pitch, so it was satisfying to see it just… handled.
When developing a multiplatform application, it is also important to keep in mind platform-specific aesthetics. The gap between shared code and a native aesthetic has narrowed sharply thanks to KMP's effortless integration of native components, such as iOS Liquid Glass components or Apple Map components.
JetBrains continues to prioritise the developer experience. While currently in the experimental stage, the features highlighted below are set to fundamentally enhance iOS development within the Kotlin Multiplatform ecosystem once they reach maturity.
Streamlined iOS interaction with Swift export: Designed to replace Touchlab’s SKIE, Swift Export offers first-party support for a more integrated experience. This allows iOS developers to engage with Kotlin code using native and idiomatic patterns.
Native dependency management via SPM: In response to the transition from CocoaPods to Swift Package Manager (SPM) in the iOS ecosystem, Kotlin Multiplatform now includes official SPM support for KMP modules. This improvement simplifies the process of incorporating third-party iOS dependencies into KMP projects.
2. Ergonomics of the language: immutability and stability
Kotlin keeps getting more ergonomic. While features like explicit nullability and data classes are already widely appreciated, JetBrains remains focused on further language refinements.
Two upcoming features in particular caught my attention. With the release of Kotlin 2.4, both explicit backing fields and context parameters will reach a stable state.
Marat Akhin highlighted the advantages of value semantics, explaining how making data structures immutable by default enables highly efficient change evaluation, which isa significant benefit for those using Compose. Kotlin 2.5 will introduce multi-field value classes as an experimental feature, bringing value semantics to Kotlin. This move aims to replace cumbersome nested .copy() calls with clean, in-place, immutable-first logic. Honestly, this is the update I'm most likely to reach for first. Those nested .copy() chains have been a quiet papercut for years.
3. Koog and the agentic direction
AI ran through everything at this year's conference, and the narrative was clear: Kotlin isn't a language for humans anymore, but shaped for AI agents too.
This was the part of the conference Huining and I diverged on most. She found the OkHttp and terminal talks more memorable than the agent frameworks.
The headline here is Koog, JetBrains' Kotlin framework for building AI agents, which reached stable 1.0. The core idea is deterministic state management, so agents are fault-tolerant rather than prone to drifting mid-task. That's a real problem worth solving, and worth watching.
Quieter but just as interesting is the proposed Kotlin Documentation Model, a backwards-compatible format that makes KDoc and API surfaces machine-readable. Ship it alongside a library and your IDE, Dokka, and any AI agent can all read the same source of truth. It's the kind of unglamorous plumbing that matters a lot once agents are reading your code as often as you are.
Junie, JetBrains' in-IDE coding agent, has matured enough to handle complex engineering tasks without breaking flow. And they're not just building their own agent, they want any coding agent to work well inside IntelliJ. To that end, they're co-leading the Agent Client Protocol (ACP), an open effort to standardise how IDEs and coding agents communicate.
4. A universal toolchain
Beyond IntelliJ, JetBrains shipped an alpha Kotlin language server for VS Code. A small thing, but a real signal that the ecosystem is no longer IntelliJ-or-nothing. The bigger news is the Kotlin toolchain: a unified system covering project management through build execution, making Kotlin significantly easier to slot into CI/CD pipelines and, not coincidentally, easier for AI agents to work with too.
Final Thoughts
Kotlin has outgrown the "Android language" label. It is a serious full-stack option ready for the AI era. The focus on multi-field value classes and Swift export for iOS KMP development shows a commitment to the fundamentals, while Junie and ACP show a language ready for the next decade of AI-assisted engineering.
If I had to pick one thing to try first, it would be the multi-field value classes when they stabilise. The Koog story is compelling, but it's still early days for production agent work at most companies.
Huining: First-time experience
This year, I made it to KotlinConf in person for the first time. I've been using Kotlin professionally for years, but there's a difference between watching recordings and being in the room. Kotlin has grown into an ecosystem spanning mobile, backend, web, desktop, and increasingly AI tooling, and the conference reflected that breadth.
My main focus going in was Kotlin Multiplatform. The KMP sessions delivered: production adoption stories, concrete iOS interoperability improvements, and an honest look at the pitfalls teams run into. I came back with more ideas than I have time for, which is probably the best outcome a conference can offer.
OkHttp: the behind-the-scenes cut
Jesse Wilson's "Deconstructing OkHttp" was the talk I really enjoyed. OkHttp is a library I've used for years without thinking much about, and Jesse managed to fit around twenty topics into 45 minutes without losing the thread.
What made it stick wasn't the pace but the framing: engineering decisions, dead ends, lessons learned. Less a technical presentation, more a behind-the-scenes look at how a successful open-source project actually evolves.
Metro: dependency injection, reconsidered
Zac Sweers' "Metro Under the Hood" was the most immediately practical session for us. We're working on a project with a complicated Dagger dependency graph, and Metro has been on our radar as a potential replacement.
After the talk, Johan ended up in a conversation with Zac about how teams actually make the case for switching. The answer wasn't simple, but the direction Metro is heading, with a clear focus on build performance and developer experience, made it feel worth the effort.
Terminals: the joy of understanding how things actually work
Jake Wharton's "Talking to Terminals" was the odd one out — and the one I keep thinking about. Not because of a framework or a library, but because of what it reminded me. A terminal window looks simple. Behind it are decades of engineering, standards, and decisions most of us have never thought to question.
Jake pulled back the curtain, and somewhere in that 45 minutes I remembered why I got into programming in the first place.
The best part
We spend our days discussing business logic, implementation details, tickets and deadlines. Then, occasionally, someone opens a window into a hidden corner of computing and reminds us that computers are still magical.
KotlinConf gave me plenty of practical knowledge to bring back to work. But perhaps the most valuable takeaway was something less tangible. I was reminded why I became a software developer in the first place: curiosity. The desire to understand how things work, to keep learning, and to keep exploring. And that feeling alone made the trip worthwhile.
