• Language: Stable context parameters, explicit backing fields, and multiple features for annotation use-site targets.
• Standard library: Stabilized support for the UUID API and support for checking sorted order.
• Kotlin/JVM: Support for Java 26 and annotations in metadata enabled by default.
• Kotlin/Native: Support for Swift packages as dependencies, updates on Swift export, and the CMS GC enabled by default.
• Kotlin/Wasm: Incremental compilation enabled by default and support for WebAssembly Component Model.
• Kotlin/JS: Support for value class export and ES2015 features in JS code inlining.
• Gradle: Compatibility with Gradle 9.5.0.
• Maven: Automatic alignment between Java and JVM target versions.
• Kotlin compiler: More consistent inline function behavior during .klib compilation.

For the complete list of changes, refer to What’s new in Kotlin 2.4.0 or the release notes on GitHub.

How to install Kotlin 2.4.0

The latest version of Kotlin is included in the latest versions of IntelliJ IDEA and Android Studio.

To update to the new Kotlin version, change the Kotlin version to 2.4.0 in your build scripts.

If you need the command-line compiler, download it from the GitHub release page.

If you run into any problems:

• Find help on Slack (get an invite).
• Report issues to our issue tracker, YouTrack.

Top issue reporters from YouTrack

Andreas Malik (21 issues), Ryan Nett (20 issues), Julien Dramaix (18 issues), Youssef Shoaib (17 issues), Jinseong Jeon (14 issues), Zac Sweers (11 issues), Ivan Canet (10 issues), Jose Enrique Estremadoyro Fort (9 issues), Łukasz Wasylkowski (8 issues), calebbrandt77 (8 issues), Edoardo Luppi (8 issues), Vadim Shabanov (7 issues), Asapha (6 issues), Louis CAD (6 issues), Niklas Baudy (6 issues), Rick Clephas (6 issues), rlnt (5 issues), marc (5 issues), Victor Turansky (5 issues), and Dirk Lattermann (5 issues).

External contributors

We’d like to thank all of our contributors whose pull requests were included in this release:

AndreyBozhko, ArseniySukhanov, bennyhuo, BraisGabin, dmaclach, kralliv, loadkrnis, migmacdev, NeonMika, nyksans, oscarArismendi, rickclephas, stefanhaustein, Stream29, tcmulcahy, and ZacSweers.

Special thanks to our EAP Champions

• Alexander Nozik
• Anderson Lameck
• Benoit Lubek
• Bernd Prünster
• David Lopez
• Dayan Ruben
• Florian Schreiber
• Ivan Canet
• Jake Wharton
• Johannes Svensson
• Łukasz Wasylkowski
• Mohamed Rejeb
• Olaf Gottschalk
• Rick Clephas
• Sechaba Mofokeng
• Sergey Chernov
• Sterling Albury
• Yang
• Yuri Geronimus
• Zac Sweers

Further reading

• What’s new in Kotlin 2.4.0 documentation
• Kotlin 2.4.0 compatibility guide
• Kotlin EAP Champions

Koog is JetBrains’ open-source framework for building AI agents in Kotlin and Java. It provides the core building blocks for agentic applications: tools, workflows, persistence, memory, observability, and integrations with existing JVM and Kotlin Multiplatform projects.

We introduced Koog at KotlinConf last year. Since then, the framework has evolved through community feedback, internal use, and several public releases. Koog 1.0 is the next step: a more stable foundation for building reliable enterprise-ready agents.

What’s new in Koog 1.0

The biggest change in 1.0 is a strict commitment to stability. To give you a solid foundation for production, we guarantee no breaking changes for stable modules for at least one year.

This release also brings several major improvements across the framework:

• Local Android AI: New provider integrations, featuring support for running LiteRT models locally on Android devices.
• A redesigned Java interop layer with a cleaner and more consistent API.
• Decoupled HTTP transport, which makes it easier to integrate Koog into existing infrastructure and use different HTTP clients.
• OpenTelemetry support across Koog targets, including Kotlin Multiplatform environments.
• Improved persistence and memory support for long-running agents.
• Anthropic prompt caching support to help reduce latency and token costs for repeated prompts.

Koog 1.0 also includes many fixes, API cleanups, and migration improvements that prepare the framework for a more stable long-term evolution. For the full list of changes, see the Koog 1.0 release notes.

Try Koog 1.0

Koog 1.0 marks the framework’s move to a stable core API.

If you’re building agents that need tools, structured workflows, persistence, memory, observability, or integration with existing Kotlin and JVM applications, this release gives you a sturdier foundation to build on.

Explore the docs, update your dependencies, and start with the stable core modules. Add Beta modules only where you need functionality that is still evolving.

Thank you

We’d like to thank everyone who tried Koog, submitted issues, shared feedback, and contributed to the project over the past year. Koog 1.0 reflects a lot of that input, and we’re excited to keep building it with the community.

At KotlinConf’26, the JetBrains team and industry partners shared how Kotlin continues to evolve for developers at every scale. The keynote highlighted advances in language design, tooling, AI-driven workflows, and multiplatform development – all aimed at improving the Kotlin development experience for building modern applications everywhere.

Evolving Kotlin

As AI-driven development raises the level of abstraction, trust in the programming language is more important than ever. Kotlin Lead Language Designer Michail Zarečenskij mentioned that with Kotlin, the team aims to provide that trust at every level. Ergonomics and safety are principles that guide the language at its very core.

Michail previewed Kotlin 2.4.0 – the next step in Kotlin’s evolution toward safer and more ergonomic code. Among the features being stabilized are context parameters, designed to make APIs more expressive and focused on core logic, and explicit backing fields, which simplify common backing property patterns while reducing boilerplate and improving safety.

The presentation also covered several experimental language features, including multi-field value classes for modeling domain-specific data such as money or colors. Key aspects of value classes include:

• The compiler automatically generates functions like equals(), hashCode(), and toString().
• Value classes use safer name-based destructuring by default.
• Value classes have no identity semantics – they are fully defined by their properties.

These changes are designed to make working with data safer, more expressive, and more efficient over time.

The presentation also highlighted future plans, such as locality as a first-class language concept, and rich errors, a new approach to representing and handling recoverable failures.

Kotlin ecosystem

Tooling has been part of Kotlin’s story from the beginning. As Kotlin expands into new workflows, including agents and integrations, the ecosystem continues to apply the same core principles of ergonomics and safety. The goal is to ensure a consistent development experience with any editor, build tool, or agentic framework.

One of the major announcements was the Kotlin Toolchain – a unified entry point into the Kotlin ecosystem. Available through a single command, Kotlin Toolchain brings together everything from creating, building, running, and testing applications to formatting code, generating documentation, and integrating with agents.

Starting today, you can already use Kotlin Toolchain in your JVM and multiplatform projects to build, run, and test your apps, with Amper now serving as the core part of the Kotlin Toolchain. In the future, Kotlin Toolchain will expand with LSP integrations, AI skills, native dependency provisioning, and much more. As always, JetBrains is also bringing deep IDE integrations for the best possible out-of-the-box experience.

The presentation also introduced the Kotlin Documentation Model, a core part of Kotlin that represents machine-readable documentation in the form of a kdoc.jar. This specified, backward-compatible format will be published alongside libraries and consumed by IDEs, web tools like Dokka, and AI agents.

Another major announcement was the promotion of the Kotlin Language Server to Alpha. Backed by the full power of the IntelliJ engine, LSP provides a more consistent experience across diagnostics, code completion, and tooling support. The official Kotlin extension for Visual Studio Code is now also available on the Visual Studio Marketplace.

Learn more

As part of Kotlin Foundation’s efforts, JetBrains and Meta have started the process of standardizing ktfmt and making it a core part of Kotlin.

The team also announced ongoing collaboration with the open-source community to bring first-class Kotlin support to official Bazel rules_kotlin, making it easier to use Kotlin in large-scale codebases with thousands of modules.

Kotlin at Google

Google has been using Kotlin in production for over a decade, and 92% of professional Android developers now use Kotlin for Android applications.

The keynote also highlighted Google’s ongoing collaboration with JetBrains on the K2 compiler. Since launching stable K2 support in Android Studio, the Google team has seen near-universal adoption. In Kotlin Symbol Processing, Kotlin’s solution to Java annotation processes, which Google built and maintains, a 17% reduction in execution time for complex builds was achieved. In R8, Android’s whole-program optimization tool, the team has been able to add a new optimization to remove reflection use from logs in the coroutines library, and this has shown 50% improvement on Compose performance benchmarks.

AI tooling for Kotlin

The keynote also focused on the next generation of AI tools for Kotlin development. We want you to be able to use any agent directly inside JetBrains IDEs. To support these efforts, JetBrains is co-leading the development of an open standard, the Agent Client Protocol (ACP), which specifies how IDEs and coding agents communicate. You can read more about it in our dedicated blog post: Our 2026 Direction: AI and Classic Workflows in JetBrains IDEs.

Junie

Junie, JetBrains’ coding agent, is deeply integrated with JetBrains IDEs, and even the Junie CLI version can connect to the IDE to get full project context. Junie also works with different LLM providers, allowing you to choose the best model for a specific task. While Junie already works in Kotlin projects, it now also includes dedicated Android support. 

JetBrains Air

As developers are becoming more productive with agents, the keynote also explored how to scale agent-based development workflows. JetBrains Air is an agentic development environment for working effectively with multiple agents.

OpenAI Codex, Claude Agent, Gemini CLI, and Junie can execute independent task loops without conflicting with one another. You can start agents in separate Git worktrees or Docker containers, and to share progress with your entire team, you’ll soon be able to use cloud agents and even start and guide them directly from the browser.

Anthropic and JetBrains

Christian Ryan, who leads applied AI engineering at Anthropic in Europe, joined the keynote to highlight the growing collaboration between Anthropic and JetBrains across AI tooling, libraries, and developer workflows. When Anthropic built their official JVM SDK, they used Kotlin, which allowed them to create the SDK in an ergonomic, concise, null-safe language. The collaboration also includes the official Kotlin MCP SDK.

On the tooling side, Claude is now native in IntelliJ IDEA and Android Studio. Claude is also a first-party model in Junie and JetBrains Air. For CLI users, there’s a plugin for Claude Code that integrates JetBrains’ official Kotlin LSP for deeper project understanding.

A new Kotlin SWE-bench based on 110 real engineering tasks from Kotlin repositories was introduced during the keynote. Using identical prompts and agent configurations, Claude Code with Opus 4.7 achieved the highest resolution rate at 86.4%.

Koog 1.0

Vadim Briliantov, Technical Lead and author of Koog, continued the keynote with a talk about the Kotlin AI agent framework that allows you to build fault-tolerant, scalable, and enterprise-ready AI agents in fully idiomatic Kotlin. Vadim announced the stable release of Koog 1.0, a major milestone for production-ready agent development in Kotlin across backend, mobile, and multiplatform applications.

The presentation focused on Koog’s approach to building reliable AI systems through type-safe workflow DSLs, persistence and recovery for long-running agents, and deep integrations with existing Kotlin ecosystems, including Spring AI, Ktor, and observability tooling. One of the featured case studies came from Mercedes-Benz, whose team uses Koog to build vehicle maintenance support agents with structured workflows and carefully controlled execution logic. Read the full case study.

Vadim also showcased multiplatform support and on-device AI capabilities on Android using Google’s Gemma models, reinforcing Kotlin’s growing position as a unified language for building modern AI-powered applications – from backend services to mobile experiences – all in Kotlin.

View on GitHub

Kotlin for backend development

The keynote continued with updates on Kotlin for backend development, including new capabilities across Ktor, kotlinx-rpc, and Exposed. The team showcased Koog integration for building AI-powered services with Ktor, experimental first-party gRPC support in kotlinx-rpc, and the stable release of Exposed, which introduces vector types for AI-powered similarity search alongside a new Gradle plugin for simplified migration script generation. A new agent skill is also available to help developers migrate existing projects to Exposed 1.0.

Beyond tooling, the presentation focused on Kotlin’s growing adoption in enterprise and compliance-driven environments, where reliability and long-term support are critical.

Starting with Kotlin 2.4, the Kotlin standard library will include an 18-month security support policy, with security fixes backported to all release lines within an active support window.

Explore more

The keynote also highlighted Kotlin’s productivity benefits for backend teams, referencing data showing 15–20% faster development cycles as projects grow in complexity. 

The presentation emphasized Kotlin’s deep integration with the JVM ecosystem through ongoing collaboration with Spring, improved Kotlin representation in Spring and JUnit documentation, updates to the kotlin-maven-plugin and Maven onboarding experience, improved coroutine support in Micrometer, and continued stabilization of the Lombok compiler plugin for mixed Kotlin-Java projects.

Kotlin Multiplatform

Kotlin Multiplatform continues to see rapid adoption, with the number of top apps using KMP more than doubling over the past year. Companies such as PayPal, Booking.com, Sony, and Duolingo are already using it in production, and more teams are adopting Compose Multiplatform to share UI across platforms. 

For example, Sony uses KMP in their Sound Connect app for headphones to work with platform APIs like sensors and background processing while sharing the UI through Compose Multiplatform. Across Kotlin Multiplatform case studies overall, applications built with KMP now serve hundreds of millions of users daily.

Getting started with KMP is now easier with the KMP IDE plugin available on all operating systems for both IntelliJ IDEA and Android Studio. The plugin offers everything you need to build great KMP apps with convenient run configurations, tools for working with Compose code, integrations with Swift and cross-language features, and AGP 9.0 support.

You can also create new projects right in the IDE with the KMP project wizard, which now uses our new default structure, where each module has a single clear responsibility.

We are working to enhance the iOS development experience, notably through Swift Export features that make calling Kotlin from Swift more natural. In Kotlin 2.4, Swift Export is officially moving to Alpha. We also introduced SPM import, which lets you add dependencies on Objective-C-compatible code using Swift Package Manager and call into those APIs directly from Kotlin code.

Kotlin/Native has seen significant performance improvements over the last year. Measured on the Google Docs codebase, build times are now 25% faster while using less than half the RAM during builds compared to a year ago.

Compose Multiplatform

Compose Multiplatform is fully stable and production-ready on mobile and desktop. The web platform also reached Beta status in September 2025, marking another major step forward for multiplatform UI development. For all these platforms, the team continues to bring you the latest improvements and APIs from Jetpack Compose. One of the biggest highlights over the past year is the new Navigation 3 library, a flexible, Compose-first solution that gives you full control over your back stack – and it’s already stable for multiplatform use.

On iOS, new interop APIs now make it possible to combine native Liquid Glass components with Compose UI, allowing native views to dynamically interact with Compose content underneath.

Beyond the framework itself, the Kotlin Multiplatform ecosystem continues to expand rapidly. There are now more than 3,500 community libraries listed on klibs.io, giving you a growing set of tools and integrations for building multiplatform applications across mobile, desktop, backend, and web.

Conclusion 

KotlinConf’26 highlighted how Kotlin continues to evolve beyond a programming language into a complete ecosystem for backend, mobile, web, AI, and multiplatform development. From language and tooling improvements to growing industry adoption, the announcements reflected the shared goal of helping developers build modern software with greater clarity, safety, and productivity.

Among all of these audiences, Kotlin’s adoption on the JVM keeps growing. Around half of Kotlin developers today write server-side applications, including in segments like payment infrastructure and banking, where some teams have been running Kotlin in production for years. A large portion of teams in segments like these work in environments where every production dependency goes through a formal security review.

In environments like these, platform teams run into a deceptively simple question: “Which Kotlin versions are supported?” Until today, we didn’t have a clean answer. This post introduces one.

Growing adoption means stronger compatibility and security guarantees

As more code depends on Kotlin, the language becomes more useful – and more constrained. People building on it expect that what they wrote yesterday will keep working tomorrow, that changes will be predictable, and that the team behind Kotlin will treat compatibility as a deliberate choice rather than an afterthought.

A few aspects of Kotlin already work this way. Source-level language stability means code written today keeps compiling on new releases. A documented deprecation cycle replaces silent breaking changes, so anything we remove is announced, and developers are given time to adapt. The Language Committee is the formal body that approves significant changes to the language. And the standard library carries its own backward-compatibility contract for public APIs across versions.

These commitments grew naturally as Kotlin became a load-bearing part of large codebases. Each one was added when it became clear we owed our users that guarantee.

But one key thing has been missing from that list, namely an answer to the question, “How long is a Kotlin release supported for security fixes?” For most teams, the gap is invisible. But there are organizations whose dependency reviews depend on the answer – and for them, this gap is everything.

Why the lack of a support policy was a problem

Kotlin’s release model is built around a steady cadence of stable releases. The latest stable release, whether it’s a language or tooling release, is the recommended baseline. Bug fixes and language development flow forward into the next release rather than backward through patches. For most teams, this works out perfectly – upgrading is straightforward, and there is little need to think about “support” as a separate concept.

For organizations that need a documented support signal, the consequences are concrete:

• Compliance teams cannot list Kotlin as a supported dependency in their standard process, because there is no formal end-of-support date to record.
• Each new Kotlin version in production triggers an individual security review instead of inheriting a documented support status.
• Procurement and vendor assessment frameworks ask for supplier documentation that doesn’t exist in this form.
• In the event of platform freezes, the absence of a policy means “upgrade immediately or lose support”. This approach doesn’t fit the way organizations like this actually manage dependencies.

Kotlin’s user base continues to grow, and that growth includes environments where the absence of a documented answer carries real cost. Addressing that absence is the next step.

Introducing a security support policy for Kotlin

• Each Kotlin release line (e.g., 2.4.x) is supported for security fixes for 18 months from the release date of its .0 version.
• Security fixes are backported to all release lines within an active support window and released as the latest patch in each line.
• Scope: the JVM kotlin-stdlib runtime artifact.

Why the JVM standard library specifically? The concern this policy primarily addresses is code running in production on the JVM – the runtime component every JVM Kotlin application links against and ships to its servers. That’s the layer compliance and security review processes focus on when assessing dependency freshness, and that’s where documented support actually unblocks decisions. Compile-time tooling – the compiler, Gradle and Maven plugins – sit in build infrastructure, not in the production runtime, and are governed differently. This policy targets exactly where the support is needed.

How patches are released. When a security issue is found and fixed, the fix is first added to a release based on the latest Kotlin release line and is then backported to every other release line still in support. Patches go out as the next patch release in each affected line – for example, if 2.4.20 is the current stable release in the 2.4 release line, the next patch release is 2.4.21. Each release line keeps its own version numbering, so a team that has qualified 2.4 for production can stay on 2.4 to receive the fix, without crossing into a new release line.

Releases ship together. Each security patch is a full Kotlin release – it goes through the standard release pipeline and ships the complete set of artifacts. You update one Kotlin version in your build and get the patched standard library. Patches for all affected supported lines are published simultaneously.

CVE and advisory. Security issues are assigned CVE identifiers where applicable and published on the JetBrains Fixed Security Issues page through the established JetBrains Security advisory process.

The policy applies to Kotlin lines released from launch onward (2.4 and later). Earlier lines remain on the previous model and are not retroactively covered.

The current list of supported release lines, their end-of-support dates, and the latest patch version in each line is maintained on a dedicated support page on kotlinlang.org. That page is the canonical reference for which versions are currently supported.

How a release line evolves

The policy is easier to follow if you watch one release line evolve from the first release (.0) until the end of support. Below is an example of what this looks like for 2.4 (with an approximate timeline; the exact dates do not matter for this example).

1. 2.4.0 ships. The 2.4 line enters its 18-month security support window.
2. A security report comes in shortly after release. The security fix is added to the release line and is shipped as 2.4.10. (Note: the x.x.10 slot follows the established Kotlin convention for the first bug fix on x.x.0.)
3. Months later, 2.4.20 ships as the next regular release in the 2.4 line. It includes all prior security fixes.
4. A new security report comes in after 2.4.20. The security fix goes out as 2.4.21. The latest patch in the 2.4 line is now 2.4.21 – the version supported teams should be on.
5. 2.5.0 ships, opening its own 18-month window. The 2.4 line is still in support; both lines now receive security backports.
6. 2.6.0 ships, opening the 2.6 line. By this point, 2.5 has had its own regular cycle and is on 2.5.20; 2.4 is still in support at 2.4.21. A new security issue is reported and confirmed. The fix is added to the latest stable release  as 2.6.10, and is simultaneously backported to the still-supported 2.5 and 2.4 lines as 2.5.21 and 2.4.22 – all three releases on the same day.
7. The 2.4 line reaches the end of support 18 months after 2.4.0. Security fixes stop for that line.

Two practical takeaways: first, you can stay on the release line you’ve qualified for production and still receive security fixes – you do not need to skip releases. Second, when a fix is published, it becomes available on all supported lines at the same time. There is no “the latest line is patched, your older line will get it eventually” gap.

What is not changing

• Kotlin’s release process is unchanged. Bug fixes, language and library features, and performance improvements continue to ship in new releases the way they always have. Older still-supported lines receive only security backports.
• Each new Kotlin release is still the recommended baseline for new projects. The security support window exists for organizations that need to stay on a specific minor line for compliance reasons – we still do not recommend delaying upgrades.

FAQ and where to go next

Q: What counts as a security fix under this policy? A: Issues with confirmed security impact – vulnerabilities of the kind tracked by CVE, where the documented and correct use of an API leads to security impact. Application-level misuse and issues caused by passing unvalidated user input into stdlib APIs are not covered.

Q: Will I have to upgrade to get a security fix? A: Only within your release line. The fix is shipped as the next patch in that line – for example, 2.4.20 → 2.4.21. You do not need to jump to a newer release to receive it.

Q: Where do I see which lines are currently supported? A: The dedicated support page on kotlinlang.org. You can find the link below.

Q: My team uses libraries that depend on a different standard library version. Does that matter? A: Yes. Only one version of kotlin-stdlib ends up on the classpath after dependency resolution, and which specific version that is depends on your build tool. Gradle’s default resolution picks the highest version requested among all your direct and transitive dependencies – so if a transitive dependency pulls in a newer standard library, that newer version is the one running, not the patched one you set in your build. Maven uses “nearest wins” by default. In either case, pin the resolved standard library explicitly (via a BOM, version constraints, or strict-version rules) to make sure the patched version you want is the one that runs.

Where to go next:

• Support page (current supported lines, end-of-support dates, latest patches): kotl.in/stdlib-security
• Security policy: kotlinlang.org/docs/security.html

IntelliJ IDEA and Android Studio remain the most complete environments for Kotlin development. But not every Kotlin developer uses either IDE – some prefer VS Code. Kotlin by JetBrains is an extension for those developers, providing official Kotlin language support in VS Code, powered by the Kotlin Language Server, and offering core features for reading, writing, and navigating Kotlin code.

What you get

The Kotlin by JetBrains extension connects VS Code to the Kotlin Language Server built on IntelliJ IDEA’s code-insight infrastructure and the Kotlin plugin implementation.

In practice, this means Kotlin-aware features in VS Code are backed by the same foundation we use for Kotlin support in IntelliJ IDEA. The Alpha release includes core editor support such as code completion, diagnostics, navigation, quick-fixes, formatting, and project import.

For the full list of supported features, see the Kotlin by JetBrains extension page on the VS Marketplace.

To get started, install the extension from the Visual Studio Marketplace, open a Kotlin project, and start coding.

Part of a broader Kotlin tooling effort

This release is part of our ongoing work to support Kotlin developers across different tools and workflows.

Earlier this year, we introduced the Java to Kotlin Converter extension for VS Code, which helps developers convert Java files to Kotlin without leaving their editor. Kotlin by JetBrains continues that effort by bringing language-aware Kotlin editing support to VS Code.

Developers using other editors that support the Language Server Protocol can also try the Kotlin Language Server, but setup is manual and requires an editor with pull-based diagnostics support.

Help shape Kotlin support in VS Code

This is an Alpha release, so your feedback is especially important at this stage. Try it in your own projects and let us know what works well, what breaks, and what’s missing from your workflow.

Please report any issues or share your feedback in our GitHub repository.

Pragmatism has been central to Kotlin’s design from day one. The language prioritizes the developer’s convenience and productivity over academic purity or feature ambition.

Developers describe working in Kotlin in a fairly consistent way: more time spent on what you’re trying to build, less time on ceremony. There are fewer rituals to satisfy the compiler, and less boilerplate to write before getting to the part that matters. For years, the interesting question was whether that effect would also be visible at scale.

Now there is data. A recent JetBrains Research study measured the wall-clock cycle from first edit to push across roughly 28 million examples. On comparable work, Kotlin developers spent about 15%–20% less time than developers working in Java.

That gap matters even more right now, as more code is written by AI agents and developers spend more of their time reading, reviewing, and verifying code. We’ll come back to this at the end.

Productivity by design: A short history

Pragmatism becomes concrete when you look at the features it produces. Here are five examples from more than a decade of language and ecosystem design decisions.

Data classes

Some patterns repeat in every codebase. Value objects, DTOs, message envelopes, and configuration records – Kotlin captures these shapes in a single declaration.

data class User(val id: Long, val name: String, val email: String)

There’s one line, value-like behavior, and minimal boilerplate. You get equality, hashing, structural destructuring, toString(), and a copy() constructor automatically. Adding a field doesn’t mean rewriting six methods by hand.

Null safety

Kotlin’s type system tracks whether a value can be absent, and the compiler refuses to let you ignore the question. A whole category of runtime failures becomes compile-time feedback.

val length: Int = user?.profile?.email?.length ?: 0

A nullable chain is expressed in one line, and the compiler verifies every step. Missing values surface at compile time, not later in production.

The small wins

A handful of features quietly remove friction at every call site. Smart casts eliminate redundant typing once a type check has already happened. Named arguments with defaults make configuration readable without builder ceremony. Trailing lambdas turn block-based APIs into something that reads like ordinary control flow.

Each one is small. Together, they shape what a typical function looks like:

fun createUser(
    name: String,
    role: Role = Role.MEMBER,
    email: String? = null,
) = transaction {                       // trailing lambda
    val user = Users.insert(name, role, email)
    if (email != null) {                // smart cast: email is now String
        sendWelcome(email.lowercase())
    }
    user
}

createUser(name = "Anton", role = Role.ADMIN)   // named args + default

Three features compound into one short, readable function.

Coroutines and structured concurrency

Async work in Kotlin reads like ordinary code. suspend functions look sequential but execute concurrently, and structured concurrency ties every async operation to the scope that started it – so nothing escapes and runs in the background unnoticed.

DSLs as a first-class idiom

Productivity didn’t stop at the language. The same syntactic decisions – trailing lambdas, extension functions, type-safe builders – also enable a culture of IDE-aware DSLs across the ecosystem: Gradle build scripts, Compose UI, Ktor routing, Exposed SQL, and HTML and JSON builders. Each is a configuration surface the compiler understands as native code, not a separate format to memorize. 

None of these is an isolated win. Each is the product of the same commitment to pragmatism. The rest of this post examines what that commitment looks like in aggregate.

The question stories couldn’t answer

Developers have described Kotlin this way for years: less ceremony and more time on the actual work. But description is not measurement. Whether the same effect would also show up in numbers, at a scale where one team’s opinion doesn’t dominate, is a different question.

Stories don’t scale, and self-reporting has known biases, including the obvious one: People who choose Kotlin want that choice to be justified. A quieter bias is that developers who tried Kotlin briefly and then went back may never be sampled. That’s the gap a study can close.

What the study found

In a recent study, the JetBrains Research team analyzed telemetry from IntelliJ IDEA Ultimate over a 20-month window, from November 2023 to June 2025, covering roughly 320,000 developers and 28 million development cycles. A cycle in this study is the wall-clock time from the first edit of a source file after a push to the next push on that file.

For small tasks (about ten minutes of editing), Kotlin cycles were on average about 15.7% shorter than Java cycles. For medium tasks (around half an hour), they were about 20.3% shorter. For large tasks (one and a half to two hours), they were about 15.1% shorter. In absolute terms, that’s a minute or two off a short fix, five to seven minutes off a medium one, and 15–20 minutes off a long one – repeated many times across a workday and a quarter. The same pattern held across task sizes and throughout the 20-month window.

The obvious questions are fair. Aren’t Kotlin and Java projects different sizes? Aren’t the developers at different experience levels? Aren’t some Kotlin teams just newer or better resourced than the Java ones they’re being compared to?

Significant effort went into ruling these factors out. The study compared the same developers before and after their migration from Java to Kotlin, against developers who stayed on Java over the same period – a longitudinal design that isolates the language change from team or project differences. Work was bucketed by task size, so the comparison did not pit a one-line tweak against a feature build. JDK version was used as a proxy for engineering culture, with the comparison run both with and without that control. The pattern held.

The full methodology – the longitudinal design, the controls, the validity checks, and the boundaries of what the study can and can’t claim – is in the JetBrains Research post. Everything from here on is how we, on the Kotlin side, read those results.

The bigger finding: Kotlin projects don’t slow down

A 15%–20% gap on individual tasks is real, but it isn’t the headline. The larger finding is in the trajectory. Looking at how the same kind of work changes shape over the lifetime of a project, the data tells a different story than the point-in-time numbers do.

In the study sample, Java projects slowed down over the 20-month window. Cycles became 9%–17% longer as codebases grew – across small, medium, and large tasks. The same pattern shows up in independent slices of the data: The longer a Java project ages, the more time the same kind of work takes. Kotlin projects barely showed that slowdown. Some Kotlin migrants even improved over the same period, working faster on comparable tasks at the end of the window than at the start.

This lines up with what we have heard for years from the maintainability side of the conversation:
Kotlin code is easier to maintain. You can come back six months later and still understand what you wrote. 

Until now, those reports lived alongside the productivity reports as separate observations. They increasingly look like the same finding from two angles.

Here is our reading of why this happens – explicitly ours, not a conclusion the study set out to prove. Kotlin code expresses intent more clearly than the equivalent Java code does. Types carry more information. Idioms are more uniform across teams and over time. Less of the work is encoded in patterns that the next reader has to reconstruct. 

If that’s the right interpretation, the trajectory result makes sense. A codebase that stays readable doesn’t accumulate the kind of friction that slowly turns a 10-minute change into a 15-minute one. The difference may not be noticeable on day one. But at scale, the compounding effect is undeniable!

What this means in the age of AI

As AI-assisted authoring and agentic workflows become more common, developers are spending more time reviewing, integrating, rejecting, and adjusting code than writing it themselves. Even on teams that haven’t adopted agents wholesale, this shift is changing the distribution of daily activities. More of the developer’s job is deciding whether that code belongs.

Two well-established facts sit side by side. First, developers spend most of their time reading code rather than writing it. The 80/20 estimate is industry folklore for a reason – it shows up in studies, in retrospectives, in any honest accounting of how a workday is spent. Second, on comparable work, Kotlin developers move through their cycles meaningfully faster than Java developers do.

The reasonable interpretation is that the time saved is reading time. Reading is where most of the time goes, and Kotlin appears to make that faster.

In agentic workflows, this is more important. Code review of an AI-generated change is reading. Verifying that a proposed implementation does what it claims is reading. Integrating it into an existing system is reading. Rejecting a bad suggestion starts with reading. The proportion of a developer’s week spent typing has been falling for two decades, and it’s plummeting now. Time spent reading and understanding is doing the opposite.

Languages that let you read faster – and trust what you read – are far more compelling for modern software development.

Kotlin also carries more static guarantees out of the box. Non-nullability is enforced at the type level. Type narrowing happens automatically once you’ve checked a type. Sealed hierarchies plus exhaustive when expressions can answer “Did the agent miss a case?” questions at compile time. The same features that make Kotlin code faster to read also make it faster to verify mechanically, by the compiler before review, and by the human reviewer thereafter.

That kind of safety really pays off when you didn’t write the code yourself.

The productivity edge in the data was real before AI, and how software development is changing could make that edge more important than ever. The day-one gap, the trajectory advantage, and the agentic workflow case all point in the same direction.

Takeaway

For developers: The team conversation that’s been running on intuition for years now has numbers behind it. The next time the question comes up about whether Kotlin actually pays off for a Java team, you can ground your answer in concrete data.

For technical leaders: The quantitative case for a new JVM service is now visible. The smaller day-one effect and the larger trajectory effect both work in your favor. The second matters most for anything you expect to maintain beyond a year.

Pragmatism produced a language whose payoff compounds with time – and matters more, not less, as the developer’s role evolves.

Links:

• JetBrains Research post – full methodology and caveats
• Kotlin for backend – frameworks, deployment, and migration paths
• Try Kotlin online – Kotlin Playground

You’ll see this project structure in newly created projects generated by our tools, in the official documentation, and in samples for Kotlin Multiplatform.

These changes are already live in the KMP wizard, both in your IDE (with the Kotlin Multiplatform plugin installed) and on kmp.jetbrains.com. We’re also working on updating our sample projects and other learning materials to match this new structure. You can already check out kotlinconf-app, KMP-App-Template, or RSS Reader as a reference.

To get support for AGP 9.0 in IntelliJ IDEA, update to 2026.1.2 or newer, and use the latest version of the Android plugin.

This post explains the changes that we’re making, why we’re changing the structure, and how you can update existing projects.

What’s changing

With our previous structure, most projects had a single composeApp Gradle module that contained a Kotlin Multiplatform library and also acted as an application for one or more platforms, containing their entry points and other related configuration.

In the Project view, this looked like:

Our new default structure has a shared module with a single, clear responsibility: It’s a Kotlin Multiplatform library containing the shared code. Then, for each platform where you want to build a runnable application on top of the shared library code, you’ll have separate application modules such as androidApp, desktopApp, and webApp.

The new structure looks like this in the Project view:

Why we’re making changes

The composeApp module in the old structure had several different responsibilities. As a result, it contained a lot of configuration, including platform-specific packaging details for all platforms. This could make it difficult to tell which parts were setting up a Kotlin Multiplatform library and which parts were setting up the applications themselves.

If you chose not to share UI on a client platform (for example, to use SwiftUI for your iOS application), the old structure included an additional shared module besides composeApp. This was a significant change to the module structure, but it only happened in certain configurations.

There was also asymmetry when it came to iOS apps. Because they require an Xcode project that consumes the shared code, iOS applications were already in a separate iosApp folder, while the rest of the applications built on the shared code were all co-located in composeApp.

Android Gradle Plugin 9.0 requires the entry point of the Android application to be in a separate module from the shared code, as it no longer supports applying the Android application Gradle plugin in a multiplatform module.

Finally, we previously had a different structure for Gradle-based and Amper-based projects. While Gradle supports multiple applications configured in a single module, Amper allows only one product per module, so Amper-based projects already used separate modules for each application.

Goals of the new structure

Based on the points above, we created the new structure with these goals in mind:

• Providing an initial setup for projects where each module has a clear responsibility and single purpose. It should always be clear where a given piece of code or build configuration should be placed in the project.
• Keeping the structure as consistent as possible across the different configurations that the wizard allows: different sets of target platforms, having a server application or not, and choosing native or shared UI for clients.
• Making it easy to modularize the project further, to go from a single multiplatform module to several ones as desired.

Adapting to other configurations

The examples above show the new project structure for a Compose Multiplatform application that shares its UI across Android, iOS, desktop, and web platforms. In other configurations, the structure will adapt as required, with minimal changes.

Configurations with native UI

Kotlin Multiplatform supports using native UI on top of shared Kotlin code. For example, you can choose to use SwiftUI for your iOS app while using Compose Multiplatform for other platforms. In this case, you’ll write shared business logic code that’s used by all platforms, and shared UI code that’s only used by certain platforms.

In this configuration, the new structure will have two shared modules instead of one: sharedLogic and sharedUI. While sharedLogic is consumed by all applications and doesn’t have Compose dependencies, sharedUI is only consumed by those that use Compose Multiplatform for their UI.

It’s still easy to decide which module to write your shared code in: If all your platforms will use it, including those with native UI implementations, it should go in sharedLogic. If only platforms using Compose Multiplatform need that code, it should go in sharedUI.

Configurations with a server included

For projects that also target server-side Kotlin, the new structure adds a server module and moves all client-side modules into a nested app folder. An additional core module in the project root lets you share code between server-side and client-side code, such as models and validation logic.

Updating existing projects

While we’re changing the default structure for newly created projects, existing projects aren’t required to adopt the same exact structure. If you want to migrate an existing project to match this new default structure, you can use the migration guide, which shows you how to introduce new modules for each entry point.

Note that the changes related to Android Gradle Plugin 9.0, however, are mandatory for all existing multiplatform projects that target Android. You can learn more about these changes and how to update your projects in this blog post.

To get support for AGP 9.0 in IntelliJ IDEA, update to 2026.1.2 or newer, and use the latest version of the Android plugin.

Get started with KMP today

To create a new project with the updated structure, go to kmp.new or use the Kotlin Multiplatform wizard in your IDE (available in both IntelliJ IDEA and Android Studio with the Kotlin Multiplatform plugin installed).

If you’re looking for examples of the new structure in action, take a look at kotlinconf-app, KMP-App-Template, or RSS Reader.

But one important question remains:

How well do these tools actually work with Kotlin?

We want to better understand how Kotlin developers use AI today, what works well, where the friction points are, and what opportunities lie ahead. That’s why we’re launching a short community survey focused on AI-assisted development with Kotlin.

Share your perspective

AI is already reshaping software development. By participating, you can help ensure that the Kotlin community’s real experiences, expectations, and needs are part of that conversation.

Complete the survey to have the chance to win a prize of your choice:

• USD 50 Amazon Gift Card
• Six-month JetBrains All Products Pack subscription

We’re looking forward to hearing your thoughts.

Taking part in KotlinConf 2026?

If you’re attending KotlinConf 2026, make sure to visit the registration counter after completing the survey to chat with our team and receive a small thank-you gift.

Get Started with Compose Multiplatform

Native text input on iOS

If you’ve wanted text fields in your Compose iOS app to feel a little more native, this one’s for you. Compose Multiplatform 1.11.0 introduces an experimental native text input implementation built on top of UIView.

This makes caret movement more precise, offers native gestures and selection handles, and provides the familiar system context menu – including Autofill, Translate, and Search. The existing text input remains the stable, cross-platform choice, but if you want the most native feel on iOS, you can now opt in.

Another iOS improvement: Concurrent rendering, introduced as an opt-in feature in version 1.8.0, is now enabled by default. Rendering tasks are now offloaded to a dedicated render thread out of the box, so your apps get the performance benefits without any extra configuration.

Compose UI testing, v2

Testing on non-Android targets gets an upgrade with support for the v2 ComposeUiTest APIs. The default dispatcher is now StandardTestDispatcher, so coroutines run in the order in which they’re queued. This makes tests more predictable and brings them closer to production behavior.

The v2 APIs also accept an effectContext parameter for passing a custom coroutine context into your compositions – useful for things like overriding the motion duration scale or supplying your own test dispatcher:

@OptIn(ExperimentalTestApi::class)
@Test
fun myTest() = runComposeUiTest(
    effectContext = motionDurationScale + StandardTestDispatcher()
) {
    setContent {
        MyComposable()
    }
    // assertions
}

The previous APIs (runComposeUiTest, runSkikoComposeUiTest, and runDesktopComposeUiTest) are now deprecated in favor of their v2 counterparts.

Smoother scrolling on web targets

Scrolling performance on Compose web has been trailing that of native targets for a while. With 1.11.0, touch processing has been substantially reworked, and scrolling in Compose web apps now feels much closer to what you get on other platforms.

You can see it in action in the latest web version of the KotlinConf App. For all the gritty details, as well as demos and the list of fixes, head over to CMP-9727.

That’s the overview of 1.11.0. Update your dependencies, try out the new APIs, and let us know what you think. For everything that didn’t make it into this post, check out the full release notes or What’s New.

TL;DR

• New “val inside parentheses” syntax is being introduced to allow for name-based destructuring. Additionally, new syntax with square brackets is being introduced for positional destructuring.
  • Both are currently Experimental (enabled using the -Xname-based-destructuring=only-syntax compiler argument) and will become Stable in a future release.
• In the distant future, the behavior of the “val outside parentheses” syntax for destructuring will change from being position-based to name-based.
  • There will be a long migration period before the default changes, and tooling is already in place to help with migration.
  • You can already make the switch to the new behavior (-Xname-based-destructuring=complete), but note its Experimental status.
• The compiler ships with migration helpers that will be enabled by default for a few versions, and it will be some time before the new behavior becomes the default.
  • You can enable these helpers now by using -Xname-based-destructuring=name-mismatch.

Kotlin is changing, with names set to become central in destructuring. In the future, val (name, age) = person will extract the name and age properties from the person value, regardless of the way and order in which they were defined. This marks a change from the current approach to destructuring, in which the position is the key element. This blog post explains the reasoning behind this change, the migration strategy, and how Kotlin’s tooling supports it.

Why destructure by name instead of position?

Destructuring is most commonly used to access properties from data classes. For example, we can define a Person class as follows:

data class Person(val name: String, val age: Int)

Then we can extract several of the primary properties in a single go. This is what we call destructuring the value into its components.

fun isValidPerson(p: Person) {
  val (name, age) = p
  return name.isNotEmpty() && age >= 0
}

Currently, destructuring is done by position. The variables we introduce in a destructuring declaration often follow the names of the properties in the data class, but there’s no such requirement in the language.

// this is exactly the same function as above
fun isValidPerson(p: Person) {
  val (foo, bar) = p
  return foo.isNotEmpty() && bar >= 0
}

This lack of connection can cause problems, as it is very easy to inadvertently swap the order of two properties. This mistake may be caught later because of non-matching types, but it appears far from the actual origin.

The way in which components relate to primary properties also hinders refactoring. For example, we cannot move the age property to be computed and still retain the nice data class syntax. Imagine we make the following change:

data class Person(val name: String, val birthdate: Date) {
  val age = (Date.now() - birthdate).years
}

Now every destructuring declaration suddenly changes from age to birthdate! To be clear, source compatibility is still possible, but you need to do a lot more work.

The current approach to destructuring is also at odds with abstraction. If we turned Person into an interface, previous instances of destructuring would no longer be valid. We could work around this by introducing our own component functions, but this is usually seen as advanced. As a result, most interfaces do not provide such facilities.

interface Person {
  val name: String
  val age: Int

  operator fun component1(): String = name
  operator fun component2(): Int    = age
}

These problems go away if destructuring depends on names instead of positions. It doesn’t matter if you rearrange the order, change a computed property into a primary one or vice versa, or define a property in a class, interface, or object. The property’s name is a stable characteristic, which means that the source does not require any changes.

The new syntax

You can enable the new syntax by passing -Xname-based-destructuring=only-syntax as a compiler argument.

Without further ado, let’s look at the new syntax, which uses names for destructuring. Instead of a single val outside of the parentheses, you use val for each property inside the parentheses.

fun isValidPerson(p: Person): Boolean {
  (val name, val age) = p
  return name.isNotEmpty() && age >= 0
}

As expected, the order in which we write val name and val age in the example above doesn’t matter. This new syntax also supports renaming for cases in which the new variable you want to define is not the same as the property you want to access.

fun isValidPerson(p: Person): Boolean {
  (val age, val theName = name) = p
  return theName.isNotEmpty() && age >= 0
}

Destructuring based on position is still important for a few use cases. Pairs and triples, for example, don’t have names for their components at a conceptual level, and there’s no intention to require littering code that uses them with first and second. Position-based destructuring can also be used for collections, and in that case, there are no available properties. The new syntax for position-based destructuring uses square brackets – mirroring the syntax of upcoming collection literals. You can choose whether to put val inside or outside the brackets.

fun isZero(point: Pair<Int, Int>): Boolean {
  val [x, y] = point      // one way
  [val x, val y] = point  // or another
  return x == 0 && y == 0
}

All of this new syntax is available anywhere you can destructure, including lambda expressions and loops.

// suggested new syntax for iterating through a map
for ([key, value] in map) {
  // work with each entry
}

person?.let { (val name, val years = age) -> "$name is $years years old" }

To reiterate: This is all new syntax. As of version 2.3.20, the compiler knows what it means, and we intend to keep this syntax once the feature reaches Stable status.

Repurposing parentheses

At some point in the future, we intend for all destructuring using parentheses to be name-based. You can actually experience this future now by using the -Xname-based-destructuring=complete compiler argument.

If you already have a project, though, making the switch could have a major impact. The most visible issue would be if destructuring stops working, and the code needs to be updated. A more dangerous one would be destructuring declarations that remain valid but change the meaning.

For that reason, the compiler ships a migration helper under the -Xname-based-destructuring=name-mismatch compiler argument. When enabled, the compiler gives a warning in cases where the behavior is inconsistent between position-based and name-based destructuring or where the code won’t be accepted once destructuring with parentheses is no longer positional.

// accepted by both with the same behavior 
val (name, age) = person

// warning: accepted by both, but the behavior changes
val (age, name) = person

// warning: accepted only by position-based destructuring
val (personName, personAge) = person
// the IDE suggests potential fixes
// - renaming: (val personName = name, val personAge = age) = person
// - square brackets: val [personName, personAge] = person

The future

As hinted in this post, there will be ample time to migrate to the new name-based destructuring. Our current timeline looks as follows:

• As of version 2.3.20, name-based destructuring is Experimental, meaning that you need a special compiler argument to use it.
  • Support in IntelliJ IDEA may be lacking, especially for migration.
    
• With version 2.5.0 (at the end of 2026), the feature will become Stable.
  • The new syntax will be available without additional configuration.
  • The compiler will start reporting migration hints, and IntelliJ IDEA will include inspections and quick-fixes to help with the process.
  • This stage roughly corresponds to name-mismatch in compiler arguments, although we may make some adjustments to reporting depending on user feedback.
    
• By version 2.7.0 (at the end of 2027), destructuring with parentheses will be name-based.
  • You can migrate to this stage earlier by using complete in compiler arguments.
    

This is a big change, and we don’t want to rush it. If at any point during 2027 it becomes clear that the ecosystem is not ready, we may postpone the change until another major version.

At no point are we deprecating the generation of component functions for data classes. Data classes will still generate the same bytecode – name-based destructuring is a feature for use sites. However, we plan to introduce multi-field value classes without component functions. That means that destructuring for value classes will only be name-based.

References

• Release notes for Kotlin 2.3.20, the first version to offer name-based destructuring.
• Design document (KEEP) for the feature and corresponding public discussion.

Congratulations to the winners:

• Mentor: Ruslan (yet300)
• Mentee: Clare Kinery (kinerycl)
• Project: bitchat-android

Ruslan’s and Clare’s collaboration focused on the Android client of BitChat, where Clare contributed UI and UX improvements that brought the Android experience closer to platform conventions and enhanced overall polish and accessibility.

Clare submitted and merged two pull requests: PR #680 and PR #682. Her work improved BitChat’s voice note styling, camera and audio controls, dark/light theme support, visual hierarchy, and press interaction feedback.

Ruslan shared that Clare adapted quickly to the codebase and was able to work independently after the initial alignment. Their collaboration started with a kickoff call and continued asynchronously through chat and GitHub.

“Clare demonstrated strong problem-solving skills, attention to detail, and a solid understanding of UI/UX principles”, said Ruslan.

For Clare, the biggest takeaway was not just the code itself, but understanding the realities of open-source collaboration.

“As a developer who had never contributed to open source before, the biggest thing I learned was how open-source collaboration actually works. This program made it feel approachable and far less intimidating than I ever expected. I genuinely don’t think I would have taken that leap without it”, she commented.

Other participants

We received 80 mentee applications and 29 mentor applications – a clear sign of strong community interest in this kind of initiative, so we plan to continue the program.

For this pilot, we selected ten pairs. Eight remained active through the middle of the program, and four completed it successfully. These successful pairs contributed across different parts of the Kotlin ecosystem and Kotlin-related projects, including the Android UI, developer tooling, documentation, CI/CD, and multiplatform libraries.

We also want to recognize the other pairs who successfully completed the program:

Mentor: Mohamed Rejeb

Mentee: Kaustubh Deshpande

Project: Calf

Kaustubh contributed across several areas of the project, including dependency updates and CI/CD automation.

Mentor: Nikita Vaizin

Mentee: Anshul Vyas

Project: FlowMVI

Anshul fixed a bug in the metrics module and contributed to the migration guide that helps developers move from MVVM to FlowMVI.

Mentor: Adetunji Dahunsi

Mentee: Yu Jin

Project: heron

Yu Jin worked on improvements related to input handling and developer-facing issues, with a focus on making the project easier to use and maintain.

What we learned

Here are a few valuable takeaways from the participants’ feedback:

• Clear task scoping matters. Start with work that is concrete, manageable, and reviewable within the program timeline.
• Asynchronous mentorship can work well, but only when expectations are explicit, and collaborators align early on communication style, task size, and review cycles.
• The program creates value on both sides. Mentees gain confidence, workflow knowledge, and real experience. Mentors get fresh contributions, a chance to improve onboarding in their own projects, and a reminder that open source becomes healthier when maintainers make room for new contributors.

Thank you to all mentors and mentees who joined the first Kotlin Ecosystem Mentorship cohort! We’re especially grateful to the maintainers who opened their projects to newcomers and invested time in guidance, reviews, and support.

Congratulations again to Ruslan and Clare, who were selected in the KotlinConf trip prize drawing, and to all four pairs who successfully completed the program.

To stay updated on future programs, join the KEMP Slack channel. See you there!

Kodee-Approved Spotlight

KotlinConf 2026 is almost here

KotlinConf 2026 is just around the corner, and the excitement is definitely building. On May 20–22, more than 2,000 Kotlin developers from around the world will gather in Munich to share ideas, learn from each other, and connect. If you cannot make it in person, you can still join online – the conference will be livestreamed on the Kotlin YouTube channel. I’ll be there in Munich, but I definitely recommend tuning in to catch the key announcements and talks as they happen.

Join KotlinConf

Golden Kodee finalists

The Golden Kodee finalists have been announced! The top three nominees in each category will be invited to KotlinConf in Munich, where one winner in each category will receive a Golden Kodee award. It is a great way to celebrate people who share knowledge, organize events, inspire others, and help grow the Kotlin community.

Meet the finalists

Kotlin release updates

April brought two Kotlin release updates. Kotlin 2.4.0-Beta2 offers an early look at what’s coming next across the language, the standard library, the JVM, Kotlin/Native, and the compiler. Kotlin 2.3.21 focuses on performance improvements and bug fixes for the 2.3 release.

See what’s new in Kotlin 2.4.0-Beta2

IntelliJ IDEA 2026.1

IntelliJ IDEA 2026.1 brings improvements that many Kotlin developers will notice in their daily work. From general performance enhancements to better language and framework support, this release is a strong ecosystem update and an important part of the Kotlin developer experience.

Explore the release

Helping Decision-Makers Say Yes to Kotlin Multiplatform (KMP)

Adopting Kotlin Multiplatform is easier when the business value is clear. I found this guest post from Touchlab useful because it explains how KMP can improve delivery speed, reduce risk, and support long-term product strategy.

Read the post

KotlinConf’26 Speakers: In Conversation With Lena Reinhard

Ahead of KotlinConf’26, I found this interview with Lena Reinhard interesting because it explores what it means to build a career in tech today, especially when old promises no longer feel certain. It covers leadership, uncertainty, the productivity debate in the age of AI, and the human side of our industry.

Read the interview

Kotlin Professional Certificate by JetBrains on LinkedIn Learning

Looking to build your Kotlin skills? The Kotlin Professional Certificate by JetBrains is now available on LinkedIn Learning. In less than 12 hours, you can go through four courses, pass the final exam, and earn a certificate you can share on your LinkedIn profile.

Start learning

Koog updates for the JVM ecosystem

Koog had a busy month, and I found these two updates useful for JVM developers. First, Koog now offers an idiomatic Java API, making it easier for Java teams to build agent workflows. Second, Koog integrates with Spring AI, helping Kotlin and Spring-based projects use Koog in a familiar setup.

Explore Koog’s Java API

Kotlin + WebAssembly: `wasi:http` sample

I like this sample because it shows how to run a minimal HTTP server with Kotlin and WebAssembly using `wasi:http`. It highlights practical progress in Kotlin’s WebAssembly story and future backend possibilities.

See the sample

Amper 0.10.0

Amper keeps evolving quickly, and this update brings several useful improvements. Version 0.10.0 introduces automatic JDK provisioning, a Maven-to-Amper converter, support for custom Kotlin compiler plugins, and an improved IDE experience.

See what’s new in Amper 0.10.0

Spring Data JPA with Kotlin

I found this practical post worthwhile because it shows how Spring Data JPA works with Kotlin across entities, repositories, custom queries, and DTOs. It is useful for teams already using Spring.

Read the post

Spring guide: Uploading Files

This guide is helpful if you want to compare Kotlin and Java side by side. It makes it easier to see how Kotlin fits into existing backend workflows.

View the guide

Coroutines Guesser Game

Created by kt.academy, Coroutines Races Guesser Game offers an interactive approach to learning coroutine behavior by predicting what happens and when. It is a fun way to test your intuition.

Play the game

Where you can learn more

• Workshops – KotlinConf 2026, May 20–22, Munich
• Introducing the Skill Manager and Skill Repository
• Give AI Something Worth Amplifying: Three Priorities for Technical Leaders
• Using ACP + Deep Agents to Demystify Modern Software Engineering
• Prototype LLM calls on the JVM using Kotlin Notebook and LangChain4j in IntelliJ IDEA
• Next-Level Observability with OpenTelemetry
• Exposed now supports array types out of the box for PostgreSQL
• Using Spring Data JDBC With Kotlin
• Ktor 3.4.3 has been released
• Dokka 2.2.0 is out

YouTube highlights

• How KMP Helped a 378-Year-Old Company
• How Uber Uses AI to Move from Java to Kotlin
• Exposed 1.0 and Beyond | Talking Kotlin
• Best KMP libraries with Klibs.io