KotlinConf 2026: Kotlin Toolchain, Koog 1.0, LSP Alpha, Swift Export and Everything New in Kotlin 2.4

KotlinConf 2026 keynote just dropped, and this year it actually delivered. Not the usual “we’re working on it, stay tuned” kind of conference — real stuff landed, some of it available today. If you work with Kotlin for Android, KMP, backend, or you’re flirting with AI agents, this is worth 10 minutes of your time. Let’s go through it without the fluff.

Kotlin Toolchain: One CLI to Rule Them All

This is probably the most quietly impactful thing announced. JetBrains introduced the Kotlin Toolchain — a unified command-line interface that covers the full development cycle: project creation, building, testing, formatting, and generating documentation. All in one place. Amper is now its core.

Why the Kotlin build tool fragmentation was a real problem

If you’ve been doing Kotlin for a while, you know the drill. Gradle for builds, ktlint or detekt for formatting, Dokka for docs, some custom scripts for the rest — and every project has its own slightly different setup. Onboarding a new dev meant an hour of “wait, which command do I run?” It wasn’t unworkable, but it was messy in a way that other ecosystems solved years ago.

Go has go build, go test, go fmt. Rust has cargo. Kotlin had… a patchwork. Not anymore.

What Kotlin Toolchain actually gives you today

The toolchain is available right now for JVM and Kotlin Multiplatform projects. That means you can create a new KMP project, build it, run tests, format code, and publish docs through one consistent interface. Amper acting as the core also means the configuration story gets simpler — less Gradle DSL gymnastics, more declarative setup that does what you expect.

This is one of those changes that doesn’t sound flashy but will make day-to-day Kotlin development noticeably less annoying. Sometimes that’s more valuable than a shiny new language feature.

Koog 1.0 Stable: A Serious Kotlin AI Agent Framework

Koog hit 1.0 stable and it’s in production. Mercedes-Benz is running it in prod. That’s not a toy project or a proof of concept — that’s a signal that the framework is ready for real work.

What is Koog and how does it differ from Python AI frameworks

Koog is a Kotlin-native AI agent framework. Not a wrapper around LangChain. Not a thin Kotlin layer over some Python tooling. It’s built from the ground up with Kotlin idioms — type-safe DSL for defining agent workflows, proper coroutine support, and first-class integration with Ktor and Spring AI.

The type-safe DSL part matters more than it might seem at first. If you’ve used LangChain in Python, you know how easy it is to wire things together in a way that blows up at runtime with cryptic errors. When your workflow is defined with Kotlin’s type system backing it, a whole category of those mistakes becomes a compile-time error instead. That’s not a minor quality-of-life thing — it’s the difference between “it works on my machine” and “it works.”

Persistence for long-running agents — why this is a big deal

Koog 1.0 ships with persistence for long-running agents. This sounds like an implementation detail but it’s actually a fundamental requirement for any agent that does real work. An agent that processes documents, calls external APIs, and needs to pick up where it left off after a restart or failure is not a weekend experiment — it’s a production system. Koog treats it like one.

For Kotlin shops that have been waiting for a reason to build AI features without switching to Python, Koog 1.0 stable is that reason. The ecosystem now has a real, production-grade AI framework that fits naturally into existing Kotlin and Spring codebases. That’s a genuine gap closed.

Kotlin LSP Alpha and the Official VS Code Extension

Kotlin has an official Language Server Protocol implementation, and it’s now in Alpha. There’s also an official Kotlin extension on the VS Code Marketplace. This is a bigger deal than the “Alpha” label might suggest.

Kotlin LSP vs IntelliJ IDEA — what’s actually changing

Before this, if you wanted a good Kotlin experience, you were using IntelliJ IDEA or Android Studio. Full stop. There were community attempts at VS Code extensions, but the experience was always a bit rough around the edges — autocomplete that sometimes worked, error highlighting that lagged, imports that didn’t resolve cleanly. Good enough for a quick edit, not good enough for serious development.

With an official LSP, the language intelligence is no longer tied to IntelliJ’s proprietary platform. Any editor that speaks LSP — VS Code, Neovim, Helix, Zed, whatever your weapon of choice is — can now have proper Kotlin support backed by JetBrains’ implementation. That’s a different category of tooling.

Why Kotlin in VS Code matters for the ecosystem

A lot of developers who work in backend or full-stack contexts live in VS Code. They know the language is good but the “you need a heavy JetBrains IDE” tax was a real barrier. Some teams standardize on VS Code for everything and weren’t about to spin up a second editor just for Kotlin services.

The LSP alpha removes that barrier. More developers can try Kotlin in their existing environment. More developers trying Kotlin means more contributors, more libraries, more Stack Overflow answers, more ecosystem growth. This is a long-term play, and it’s the right one.

kdoc.jar: Machine-Readable Documentation for the AI Age

This one flew under the radar in the keynote but it’s genuinely clever. Kotlin libraries can now publish a kdoc.jar alongside their regular artifact — a machine-readable version of the documentation that IDEs, Dokka, and AI agents can consume directly.

How kdoc.jar works and why it matters for developer tooling

Think of it like TypeScript’s .d.ts declaration files, but for the Kotlin ecosystem. When a library ships kdoc.jar, your IDE gets richer information about APIs. Dokka can do smarter things when generating documentation across your project. And AI coding assistants — GitHub Copilot, Koog agents, whatever comes next — can reason about library APIs with actual structured knowledge instead of guessing from training data or reading raw source.

The practical effect is that working with third-party Kotlin libraries gets better, and that improvement compounds over time as more libraries adopt the format. It’s not a feature you’ll notice immediately, but six months from now when you’re getting accurate autocomplete for a library that just shipped, you’ll be glad it exists.

What this means for AI-assisted Kotlin development

As AI coding tools get more integrated into development workflows, the quality of machine-readable metadata becomes a real competitive factor for languages. Kotlin is getting ahead of this. Libraries that ship kdoc.jar will be better understood by AI tools — fewer hallucinated APIs, more accurate suggestions, better context for code generation. It’s a quiet investment in the future of the tooling ecosystem.

Swift Export Alpha in Kotlin 2.4: KMP on iOS Gets Serious

Kotlin 2.4 ships Swift Export in Alpha, along with Swift Package Manager import support. The goal: calling Kotlin from Swift should feel normal, not like you’re fighting two different type systems with a wrench and some duct tape.

What is Swift Export and why KMP iOS interop was painful before

Kotlin Multiplatform on iOS has always had a rough edge: the interop with Swift. Objective-C bridging is functional but you end up with APIs that feel foreign in Swift code — awkward naming, types that don’t map cleanly, patterns that make Swift developers visibly uncomfortable. Swift Export aims to generate proper Swift-idiomatic APIs from Kotlin code, so the iOS side of a KMP project doesn’t feel like an integration layer bolted on as an afterthought.

SPM Import is the other half of the story. Swift Package Manager is how iOS developers manage dependencies. Being able to import SPM packages from Kotlin code means KMP projects can actually consume the iOS ecosystem’s libraries directly instead of reinventing wheels or wrapping things manually.

Swift Export Alpha timeline: what to expect in Kotlin 2.4 and beyond

It’s Alpha, so production use is a bit early. But Alpha in JetBrains terms usually means “real enough to try, not yet stable enough to bet the company on.” Given the trajectory — Experimental to Alpha is a meaningful step — Stable is a realistic expectation within a couple of Kotlin releases. If your team is evaluating KMP for a new iOS project, Swift Export is worth tracking closely right now even if you don’t adopt it immediately.

Kotlin/Native Performance: 25% Faster Builds, Half the RAM

Numbers: Kotlin/Native builds are 25% faster compared to last year, and memory usage during compilation dropped to less than half of what it was. These were measured on the Google Docs codebase, which is not a toy project. This is meaningful.

Why Kotlin/Native build performance was the main argument against KMP on iOS

If you talked to iOS developers who had tried KMP and decided against it, build time was almost always in the top three complaints. Android builds are already famously slow — adding a Kotlin/Native compilation step for iOS made full builds feel like you were compiling the Linux kernel on a Raspberry Pi. It was a real practical problem that affected daily developer experience.

A 25% improvement in build time isn’t “we made it slightly better.” On long builds, that’s meaningful minutes saved per cycle. Multiply that by every build every developer runs every day and it adds up fast. Less RAM usage also means the builds stop competing with your browser and IDE for memory on a 16GB machine, which is still a very common developer configuration.

KMP on iOS in 2026: is it production-ready now?

The honest answer is: more than it was, and getting closer every release cycle. The compilation improvements remove one of the core objections. Swift Export in Alpha addresses the interop friction. The Kotlin Toolchain handles the build orchestration. The remaining rough edges are getting smoothed down at a steady pace.

Teams that started KMP projects 18 months ago and ran into native performance walls should take another look. The stack is in a meaningfully better place.

What KotlinConf 2026 Means for the Kotlin Ecosystem in 2026 and Beyond

Stepping back from the individual announcements, there’s a clear strategic picture here. JetBrains is attacking Kotlin’s remaining weak spots in a coordinated way: tooling fragmentation, IDE lock-in, iOS interop, AI ecosystem presence, and native performance. These aren’t random features — they’re the specific reasons developers who liked the language stayed on the fence or walked away.

Kotlin vs Python for AI development: does Koog change the calculus?

For a long time, the answer to “I want to build AI agents” was Python. Not because Python is especially good at it, but because that’s where all the frameworks, tutorials, and community knowledge accumulated. Koog 1.0 stable is the first serious attempt to change that calculus for Kotlin developers. Type safety, coroutines, and native JVM/Spring integration are genuine advantages for production AI systems. Python’s head start in the AI space is real, but it’s not permanent.

Kotlin Multiplatform 2026: the case for sharing business logic across platforms

With the toolchain unified, iOS interop improving, and native build times dropping, the practical case for KMP on a new cross-platform project is stronger than it’s ever been. The conversation has shifted from “can we do this” to “is this the right call for our team.” That’s a different kind of conversation, and it’s the right kind.

What developers should actually do with these announcements

If you’re a Kotlin developer: update to 2.4 when it lands, try the Kotlin Toolchain on a side project, and look at Koog if you’re building anything AI-adjacent. If you’re an iOS developer evaluating KMP: the timing for a serious evaluation is now better than six months ago. If you’re a VS Code user who avoided Kotlin because of IDE requirements: install the official extension and give it a real try.

Not everything announced today will be stable by next quarter. Swift Export and the LSP are Alpha for a reason. But the direction is clear, the pace is consistent, and the language is in a better position than it was at this time last year. That’s what a healthy ecosystem looks like.

Quick Reference: What’s Available Now vs What’s Coming

Available today

Kotlin Toolchain with Amper — works for JVM and KMP projects right now. Koog 1.0 stable — production-ready, integrate with Ktor and Spring AI. Official Kotlin VS Code extension — on the Marketplace, install and use immediately. Kotlin/Native build improvements — you get these automatically when you update.

Alpha — use with caution in production

Kotlin LSP — solid enough for daily development in non-IntelliJ editors, but expect rough edges. Swift Export in Kotlin 2.4 — worth experimenting with for iOS interop, not yet stable for production reliance.

Keep watching

kdoc.jar adoption — the format is defined, but the ecosystem needs library authors to start shipping it. Watch the major libraries for updates. Swift Export Stable — probably two to three Kotlin releases away based on current trajectory, but the Alpha landing means it’s on the clock.

KotlinConf 2026 was one of the better JetBrains keynotes in recent memory. Concrete deliverables, clear roadmap, real production use cases. The ecosystem is moving. Time to move with it.