From creating educational content and building engaging online communities to organizing events, fostering connections, and driving positive societal impact, the Golden Kodee Awards shine a spotlight on the many ways people contribute to Kotlin. Open to active members of the Kotlin community who have made notable contributions over the past two years, the awards honor those who share knowledge, mentor others, and inspire developers around the world.

Getting to know the Golden Kodee winners

This year’s winners represent the diversity and strength of the Kotlin community: Matheus Leandro Ferreira (Education), Jaewoong Eum (Online Presence), Nicole Terc (Creativity), Eeva-Jonna Panula (Positive Societal Impact), and Yinlong Liu (In-Person Presence).

In the days following KotlinConf, we caught up with each of the winners to learn more about their projects and initiatives.

Which of your projects do you think stood out the most in helping you win a Golden Kodee?

Matheus Leandro Ferreira: Since my category is focused on education, I believe my experience teaching at the university and working with Kotlin over the years may have been an important factor. I’ve been teaching programming and mobile development with Kotlin for quite a long time, while also creating educational content for the developer community outside the classroom.

Jaewoong Eum: I’ve contributed to the open-source community for over nine years, so I believe most of my open-source projects have helped me win this award, such as Balloon, landscapist, and compose-stability-analyzer. But also, I’ve written lots of technical content on my personal blog, newsletters, and recently, I’ve published several books, so all these activities and projects helped me to win this award.

Nicole Terc: Composable Sheep talks.

Eeva-Jonna Panula: I think there might not have been one project that stood out the most; it was probably the whole body of work I’ve done in content creation on accessibility, disability, and inclusion.

Yinlong Liu

As one of the earliest developers to adopt KMP in China, I established a KMP WeChat community to connect developers, and I have been glad to see an increasing number of companies successfully adopt KMP.

What did winning a Golden Kodee feel like?

Matheus: It meant a lot to me. In many ways, it felt like a validation of my long journey in education. I’ve been working professionally in technology for more than 20 years and teaching for 13 years. It’s honestly very difficult to describe what I felt when I won. It was incredibly gratifying. Without a doubt, it was the biggest award of my career.

Jaewoong: I’m truly honored to have received the Golden Kodee Award. I’ve received so much appreciation and encouragement from the community about this win, and it has motivated me. I felt so many positive vibes from everyone throughout the experience. To be honest, even though I’ve been consistently contributing to the community over the years, I don’t often get an opportunity to directly hear words of appreciation from people. But through this award, I was able to feel that gratitude in a very real way, and it genuinely made my heart beat faster. It reminded me again why I love being part of this community and why I want to keep contributing.

Nicole: It was really surprising at first, then I felt really humbled and seen. We don’t get enough awards in the community, so having all the hard work recognized was a welcome change. 

Eeva-Jonna: Awesome. The reason I do what I do is that I enjoy it and want to share knowledge and help developers create more inclusive apps. In a sense, it’s a niche topic that doesn’t get much attention compared to many other topics, so being recognized with a Golden Kodee truly meant a lot.​

Yinlong: It feels truly joyful, honorable, and exciting. Having been a practitioner and advocate of KMP for about six years, I have integrated Kotlin and KMP into my work, life, and even my faith. I have grown my own influence through KMP. I also have a special connection to the color purple: it is not only the theme color of Kotlin but also the color of my favorite NBA team, the LA Lakers.

Jaewoong Eum

I’ve received so much appreciation and encouragement from the community about this win, and it has motivated me.

Can you take us back to the beginning: How did you first discover Kotlin? What initially attracted you to it, and what made you stick with it?

Matheus: I started using Kotlin practically from the moment it was introduced for mobile development. At that time, all of my company’s applications were built with Java. Gradually, we migrated all of them to Kotlin, without exception. I also updated the curriculum at the university where I teach, replacing the applications and teaching materials that were previously developed in Java with Kotlin. The language brings a huge range of opportunities. It’s less verbose, constantly evolving, and keeps up with the trends of the professional market. These days, using Kotlin is essential.

Jaewoong: The positive cycle of community keeps going around. Back in 2018, I first discovered Kotlin when well-known people in the open-source community began sharing their experiences using it for Android development. I heard great feedback about its impact on developer productivity, which led me to try it for the first time. At the time, I started using Kotlin because of its Java interoperability and various convenient features. But the more I used it, the more I began to see its true value. Today, Kotlin is undoubtedly my top-choice programming language.

Nicole: My story is similar to many: I was a Java Android developer and adopted it when it got announced as an official Android language. We had an early adopter on our team at the time, so the transition was not hard at all. I stuck with it because of all the goodies it brought into Android: less verbosity, null safety, no use of semicolons, coroutines, etc.

Eeva-Jonna: I was a web developer at a company that didn’t have much web development work in Finland at the time. I was also an accessibility specialist who had just conducted accessibility testing on our Android app, realizing that the situation wasn’t optimal. I spoke with the Android developers and realized no one would have time to fix the issues I found, so I decided to do it myself. This was pretty much what got me started with Kotlin – becoming an Android developer. As mentioned, I come from a JavaScript (okay, okay, TypeScript) background. When I started working on the Android app and Kotlin, I had these constant moments where I realized that a language can actually support so many things, instead of forcing you to build the functions from scratch every single time.

Yinlong: We started around 2020 with Kotlin 1.3.72/1.4.0. KMP’s option for shared business logic code is what initially attracted us. We have apps that cover the Android, Windows (Java-based), and iOS platforms, which require high performance and the handling of heavy business logic, all while having a team predominantly made up of Android developers. KMP perfectly matched our requirements for cross-platform technology. As it has become more stable and we’ve gained experience, we have been gradually expanding the scope of our KMP module.

Matheus Leandro Ferreira

The language brings a huge range of opportunities. It’s less verbose, constantly evolving, and keeps up with the trends of the professional market. These days, using Kotlin is essential.

What do you love most about working with Kotlin today?

Eeva-Jonna Panula

Being able to build once and distribute to different platforms is great, but what I especially enjoy is how KMP handles native implementations.

Matheus: My passion has always been backend development, so what I enjoy the most today is the combination of Kotlin with Spring Boot. It’s something truly fantastic. At the university, I teach the “Mobile Programming” course, and over time, I’ve also been enjoying working more and more with mobile frontend development.

Jaewoong: I first started using Kotlin because it was 100% compatible with the JVM ecosystem. Over time, it became my primary programming language. What I love most is that Kotlin has grown far beyond the JVM and Android. Today, it can be used actively across many multiplatform development scenarios, which makes it even more powerful and practical. Another thing I really appreciate about Kotlin is its ecosystem. The Kotlin Foundation is deeply committed to maintaining and growing the Kotlin ecosystem. Through initiatives like the Kotlin Evolution and Enhancement Process, they actively communicate with the community and listen closely to user feedback to improve the language. I think this is one of the biggest differences that sets Kotlin apart from many other language ecosystems. I’m also fascinated by the fact that Kotlin enables more advanced, low-level work through tools like Kotlin compiler plugins and KSP. These open the door for using the language at a much higher level, and they’re a big part of what makes Kotlin so compelling to me.

Nicole: Coroutines. The concurrency handling in Kotlin is pretty good.

Second place is KMP. I really appreciate the potential of porting Android apps to many other platforms.

Eeva-Jonna: From a language perspective, it’s the APIs and the way you can write code intuitively. Extension functions and collection APIs make my life so much easier, and even after years of happily being away from the JS world, I still appreciate these features every day. I also love working with Kotlin Multiplatform. Being able to build once and distribute to different platforms is great, but what I especially enjoy is how KMP handles native implementations. If there’s something I can’t do in Kotlin, I can just drop down to native code to get it done. That flexibility is really powerful.

Yinlong: I love ❤️ Kotlin. I just love everything about it.

What are you currently building or experimenting with in Kotlin?

Matheus: Currently, at the company, I’ve been exploring the backend side a lot with Ktor (and also Spring Boot with Kotlin). I’m building a REST API for our BI platform. The idea is to use Kotlin to improve performance, concurrency with Coroutines, and the overall expressiveness of the code compared to our Java legacy systems. The experience with the clean syntax and null safety in a microservices ecosystem has been fantastic. At the university, I’m focused on Kotlin Multiplatform (KMP). I’ve been experimenting with sharing business logic between Android and iOS in a project with my students. It’s amazing to see how much the technology has matured, allowing us to reuse almost the entire data and architecture layers without losing the native experience of each platform. I’m also keeping a close eye on Compose Multiplatform for UI development.

Jaewoong: I work on a variety of projects with Kotlin, like Compose Stability Analyzer, but the one I’ve been focusing on most recently is Compose HotSwan. HotSwan is a Hot Reload system for real Android devices. When you make changes in the editor, it applies those changes to the currently running app in under a second and immediately shows the result. Some parts are implemented at a lower level, including C++, but most of the system is written in Kotlin across multiple layers, including the Kotlin Compiler Plugin, Gradle plugin, and IntelliJ IDE plugin. Building a Hot Reload system itself requires a very complex workflow, but Kotlin’s broad language and tooling support made the process much more approachable. HotSwan is still in the early stages of adoption, and it is one of the first Hot Reload solutions for Android and Jetpack Compose. Looking ahead, I see it becoming a next-generation mobile client development solution, especially when combined with AI to create a much faster UI development feedback loop.

Nicole: I’m officially working with Kotlin as a professional Android engineer. In my personal time, I’m building a private boardgame-related app and playing with new ideas with my Filament project.

Eeva-Jonna: I’m building an app with Kotlin Multiplatform (currently for Android and iOS). It’s a planner app for women and anyone with cycles, combining cycle tracking, calendars, notes, tasks, and more into one app. Currently, we’re collecting waitlisters and have started testing rounds. I’ve enjoyed building the app with Kotlin Multiplatform. Everything is mostly written in Kotlin, but some things have required a native implementation, which has been easy to implement.

Yinlong: Nothing at the moment.

What advice would you give to developers who want to become more active in the Kotlin community?

Nicole Terc

In my opinion, the point of participating in a community should be to share and grow together, not to be famous.

Matheus: The best advice I could give is: learn in public. You don’t need to be an expert in the ecosystem to contribute. If you spent two hours struggling to configure Coroutines or to get a Kotlin Multiplatform (KMP) project running and finally figured it out, document it. Write a short article on Dev.to, make a LinkedIn post, or create a GitHub repository explaining the solution. What may seem simple to you could be a lifesaver for another developer.

Jaewoong: The community is always open to everyone, but it can take time to truly understand what “community” means. Contributing to a community is not something you do because you expect something in return. It is more about sharing what you have learned, helping others who are facing similar challenges, and slowly becoming part of a positive cycle where everyone learns from each other. My advice is to start small. You don’t need to be a famous speaker or an experienced open-source maintainer from day one. You can write about something you just learned, answer a question, report an issue, improve documentation, or share a small Kotlin example that helped you. Over time, those small contributions build trust, relationships, and confidence. And most importantly, they remind you that the Kotlin community is not just about the language itself, but about the people who keep learning, building, and helping each other grow.

Nicole: Reach out to local meetups. Be proactive with socializing and sharing what you are doing without worrying about the clout. In my opinion, the point of participating in a community should be to share and grow together, not to be famous.

Eeva-Jonna: I would say that the most important thing is to start. Whatever it is you want to do, start doing it. If you want to do public speaking, meetups are usually looking for speakers, and many conferences support first-time speakers. If you want to start creating content, just start. You won’t get it perfect the first time anyway, so better start practicing sooner rather than later. Also, find people who can help you. Reach out to others who are doing what you want to do and ask if they can help. Sometimes the answer might be “no” because, e.g. they don’t have enough time, but many times you get a “yes” and some help. 

Yinlong: My advice is to use Kotlin to implement your ideas and actively communicate and share your findings with others.

Where are you keeping your Golden Kodee?

The stories of this year’s Golden Kodee winners show that there are many ways to make a meaningful impact on the Kotlin community. We hope their journeys and advice have inspired you as much as they have inspired us.

For many students, programming begins in the classroom, where a teacher introduces basic concepts for the first time. Having reached more than 25 million unique learners worldwide, BlueJ is one of the most widely used environments for beginners. Its visual class diagram, object bench, and direct object interaction help students see programs as systems of objects they can create, inspect, and command.

When learning to program, students increasingly need to read, evaluate, debug, and maintain code, including code generated by AI. BlueJ helps beginners build the mental models that let them understand and trust the programs they work with by making program behavior visible and interactive – they can create objects, call methods, and observe how state changes. With Kotlin support, they can do this with less boilerplate and fewer syntactic distractions.

Why Kotlin in BlueJ

Java has played a central role in introductory OOP for many years. It is explicit, structured, and familiar to educators. At the same time, many teachers know the cost of that explicitness: students often need to write quite a lot of boilerplate before they grasp the concept.

Kotlin keeps the object-oriented model visible and surfaces a few important design choices from the beginning:

• Concise syntax reduces the amount of code students need to read and write.
• Null safety makes the possibility of missing values explicit.
• val and var help students distinguish what can change from what cannot.
• JVM interoperability keeps Kotlin close to the Java ecosystem educators already know.

What you can do with Kotlin in BlueJ

This first release focuses on the core classroom workflow. You can create, edit, compile, and run Kotlin files; define classes with properties and methods; and create objects and call their methods through the familiar BlueJ interface, including class diagrams and the object bench. 

Teaching materials

To help educators get started, we’ve prepared an onboarding guide for teaching OOP with Kotlin in BlueJ.

It’s written for teachers who already know how to teach introductory OOP and want to understand how those concepts map to Kotlin. It includes explanations, examples, and projects for classroom use. Each unit comes with example projects and practice materials that can be opened directly in BlueJ.

Thank you to the BlueJ community

Early builds of Kotlin support in BlueJ were shared with educators in the BlueJ community, and their feedback helped shape the release. Teachers tested classroom examples, reported issues, and shared how they think about Kotlin in an objects-first environment. We are especially grateful to everyone who tried the early builds and helped us understand what matters most in real teaching practice.

Try Kotlin in BlueJ

If you teach with BlueJ, we’d love for you to try Kotlin and tell us how it goes.

We are looking forward to your questions and feedback from your own classroom. Write to us at education@kotlinlang.org, and visit the Kotlin for Education page to explore more resources and join the community of Kotlin educators.

Let’s teach Kotlin – good luck, and have fun!

Kodee-approved spotlight

The Kotlin Effect in real life

What happens when Kotlin’s logic goes beyond code? For Kotlin’s anniversary, familiar language ideas were brought into everyday situations – making them more concise, efficient, and fun. I had a great time watching the Kotlin Effect come to life outside the IDE.

Watch the video

Kodee vs. Friction

I’ve been busy fighting bugs in Kodee vs. Friction, a browser arcade game where I take on enemies like Boilerplate Golem and Callback Hydra with Kotlin-inspired power-ups. It’s built with Kotlin, Compose Multiplatform for web, Kotlin/Wasm, and a Ktor backend, and the source code is public so you can see how everything works. For the best experience, I recommend playing on a desktop or laptop.

Play Kodee vs. Friction

Free Kotlin learning resources

An anniversary is a good reason to learn something new. To celebrate Kotlin’s turning 15, select Kotlin courses are available for free on Hyperskill. Whether you want to strengthen your foundations or continue into mobile and backend development, these project-based resources offer a practical way to keep progressing.

Keep learning Kotlin

Kotlin 2.4.0

Kotlin 2.4.0 is here! The release stabilizes context parameters and explicit backing fields, expands standard library and platform capabilities, and brings improvements across Kotlin/JVM, Kotlin/Native, Kotlin/Wasm, Kotlin/JS, Gradle, Maven, and the compiler. I recommend checking out the full overview to find the changes that matter most for your projects.

See what’s new in Kotlin 2.4.0

Kotlin Toolchain 0.11

The Kotlin Toolchain is your unified entry point for working with Kotlin projects. With a single `kotlin` command, you can create, build, run, test, and publish projects – without complex plugin configuration. Version 0.11 is now available as the official evolution of the Amper project. I’m excited to see this simpler workflow continue to grow across JVM and multiplatform development.

Explore Kotlin Toolchain 0.11

Koog 1.0

Koog has reached 1.0, marking a major milestone for building AI agents in idiomatic Kotlin. The stable core comes with a one-year compatibility guarantee, improved interoperability, multiplatform observability, and support for reliable agent workflows across backend, mobile, and multiplatform applications.

Discover Koog 1.0

Grants for Kotlin library authors

The 2026 Kotlin Foundation Grant Program is open for developers building or maintaining open-source Kotlin libraries, tools, and frameworks. Projects that strengthen the Kotlin ecosystem – including work related to Kotlin Multiplatform, AI, and large language models – can apply for financial support. Applications close July 14, 2026.

Learn more and apply

Compose Hot Reload experiments with AI agents

Compose Hot Reload 1.2.0-beta01 continues the work on the experimental MCP server, giving AI agents more ways to interact with running Compose applications in real time. The beta adds support for autonomous build mode, log access, UI error inspection, and lifecycle controls such as restart and reset. It is still experimental, but it offers an interesting glimpse into how AI-assisted development could become more visual, interactive, and connected to the running app.

Try the experimental update

Compose Multiplatform 1.12.0-beta01

Compose Multiplatform 1.12.0-beta01 is here, bringing updates for shared UIs across platforms, including new graphics capabilities, iOS accessibility improvements, UI test behavior updates, and fixes for iOS, desktop, web, resources, and the Gradle plugin. Check out the release notes for the full list of changes and migration details.

Explore the release notes

Three Kotlin Multiplatform libraries worth exploring

I found three useful additions to explore on Klibs.io: ComposeMediaPlayer for cross-platform video playback, NSExceptionKt for better Kotlin/Native crash reporting on Apple platforms, and multiplatform-settings for storing key-value data in shared code. They solve very different problems, which is exactly what makes browsing the KMP library ecosystem so interesting.

Discover more libraries on Klibs.io

Booking.com’s Kotlin Multiplatform journey

Booking.com adopted Kotlin Multiplatform for an experimentation library, and the results exceeded the team’s expectations. Their story shows how KMP can improve cross-platform consistency while fitting into an existing product and engineering environment – without asking teams to abandon platform-specific development.

Read the Booking.com story

Where you can learn more

• Build AI-powered apps with Kotlin and Spring AI
• Evaluate Kotlin adoption with the enterprise playbook
• Test Ktor REST APIs with the built-in test framework
• Bring iOS 26 Liquid Glass to a Compose Multiplatform app
• Connect shared business logic to UI with a multiplatform ViewModel
• Read The Road to Name-Based Destructuring
• Explore Compose Multiplatform 1.11.0
• Learn about the Kotlin Notebook plugin update

YouTube highlights

• Beyond LLMs: Kotlin Game AI
• Introducing the New KMP Project Structure
• KotlinConf’26 Keynote
• Jake Wharton | KotlinConfersations’26
• Dan Kim | KotlinConfersations’26
• Six Years, Zero Regrets: Sony’s Kotlin Multiplatform Success Story | KotlinConfersations’26
• What Nobody Told Us About KMP on iOS | KotlinConfersations’26
• Migrating 25-year-old legacy code to Kotlin
• A World of Kotlin – Animated Short Film (2026 KotlinConf Intro)

That’s all from me for this roundup. Happy 15th anniversary, Kotlin – and happy coding!

The plugin will remain available on an open-source model so the community can continue its development. 

Below, we explain why we’re making this change, how it affects current Kotlin Notebook users, what comes next, and how Kotlin DataFrame will continue to exist beyond Kotlin Notebook.

Why we’re making this change

Demand for built-in interactive tooling has shifted since we launched the plugin, and Kotlin Notebook didn’t reach the level of adoption we expected. AI tools have changed how developers explore code, prototype, and iterate, and many of the workflows that originally drove notebook adoption have evolved along with that shift.

After reviewing usage trends, we’ve decided to move Kotlin Notebook out of our internal roadmap and into the open. Going forward, our team will devote its time to projects with a broader impact on Kotlin developers.

Timeline and what to expect

Here’s what to expect during the transition:

v2026.1 and earlier:

• Kotlin Notebook remains bundled with IntelliJ IDEA.

v2026.2:

• Kotlin Notebook will be unbundled from IntelliJ IDEA.
• JetBrains will no longer develop new features for Kotlin Notebook.
• The Kotlin Notebook plugin will still be available for installation from the marketplace. It is compatible with v2026.2. However, we do not maintain it anymore. Future development will happen in the open-source repository only. 
• The plugin source will be published on GitHub under the Apache License 2.0. Users can build the plugin from GitHub and install it manually. The README walks you through the steps.

V2026.3 and further:

• JetBrains won’t publish a compatible plugin for v2026.3 and beyond.

During the transition to community ownership:

• We plan to continue maintaining the Kotlin Jupyter kernel on a best-effort basis, as capacity allows.
• If you’re interested in maintaining or contributing to Kotlin Notebook, please share your interest in the Kotlin Slack #notebooks channel. 
• Our Support team will be available during the transition for compatibility questions.

Kotlin DataFrame beyond notebooks

If you’re using Kotlin DataFrame, recent releases have made it much easier to bring notebook-style, type-safe data transformations into regular Kotlin projects. With the Kotlin DataFrame compiler plugin, schema-aware APIs and generated column accessors are now available directly in Gradle and Maven projects and can be used in ordinary .kt files.

To get started, see the setup guides for Gradle and Maven:

• Gradle: https://kotlin.github.io/dataframe/setupgradle.html
• Maven: https://kotlin.github.io/dataframe/setupmaven.html

We also recently released Kotlin DataFrame 1.0.0-Beta5, with numerous improvements across the library. See the release notes here.

If you have questions about migrating existing workflows or adopting Kotlin DataFrame in your projects, feel free to reach out in the Kotlin Slack #datascience channel.

Thank you note

We’re grateful to everyone who used Kotlin Notebook, filed issues, and shared feedback over the years. Thank you!

The JetBrains team

Read on for the details, and check the release notes for the full list of changes and bug fixes.

To get support for Kotlin Toolchain’s latest features, use IntelliJ IDEA 2026.1.2 (or newer). Make sure the latest version of the Kotlin Toolchain plugin is installed. 

Amper is now the Kotlin Toolchain

When we launched Amper, the goal was to experiment with a cohesive, declarative build experience. As the project evolved, it became clear that the ecosystem doesn’t just need another build tool – it needs a unified entry point into all of Kotlin.

The Kotlin Toolchain is that cohesive entry point. It provides a single command, kotlin, which allows you to create a project, build, run, and test it, and configure it for packaging and publishing. In the future, it will even let you format your code, generate docs, and much more. No build-tool decisions up front; no complex plugin wiring before you can write your first line of code.

Of course, we didn’t start from scratch. Everything we built inside Amper was moved to the Kotlin Toolchain, which allowed the project to graduate straight to Alpha! This label means JetBrains is committed to supporting it, and so we’d love for you to try it out and share your feedback.

If you were already using Amper, this major change has several implications that you should be aware of:

• The amper and amper.bat wrapper scripts must be replaced with the new kotlin and kotlin.bat wrappers.
• In IntelliJ IDEA, the Kotlin Toolchain IDE plugin must be installed instead of the Amper IDE plugin, which can safely be uninstalled.

Global installation

The wrapper scripts that are committed to your project are great for providing a clone-and-build experience with zero installation requirements, but they aren’t suitable for all use cases.

With this new release, you can now install the kotlin CLI globally (outside of a project) and use it everywhere instead of ./kotlin. You can install it right now via SDKMAN! this way:

sdk install kotlintoolchain

This improves the experience on several fronts:

• Launching kotlin commands from nested directories inside your project is more convenient.
• You can use project-agnostic commands from any directory (like kotlin tool jaeger or kotlin clean-shared-caches).
• Creating new projects with the init command is more natural (no need to download a wrapper manually or copy it from another project).

Using the global kotlin command doesn’t mean you will have to align your Kotlin Toolchain version in all your projects, though. The kotlin command automatically finds your project’s wrapper script and runs the matching version of the Kotlin Toolchain.

Publishing

The library publication feature is finally in preview! You can now publish your JVM libraries to Maven repositories, including Maven Central.

Regular Maven repositories

To publish to a Maven repository other than Maven Central, use the following configuration in your module.yaml:

product: jvm/lib

repositories:
  - id: myMavenRepoId
    url: https://maven.pkg.github.com/my-org/my-maven-repo 
    publish: true
    credentials:
      file: creds.properties # a properties file containing your credentials 
      usernameKey: maven.username # the name of the property containing the username
      passwordKey: maven.password # the name of the property containing the password

settings:
 publishing:
   enabled: true
   group: com.example
   artifactId: greeter # optional, defaults to the module name
   version: 1.0.0

Provide the credentials file that was referenced in the repository configuration, for example, this creds.properties:

maven.username=john.doe
maven.password=MyVerySecurePassword123

You can then reference the repository by ID when running the publish command:

kotlin publish myMavenRepoId

This command publishes all modules that have publication enabled and have declared a repository with the ID myMavenRepoId.

Maven Central

Publishing to Maven Central is known for being a tedious process involving a lot of moving parts: sources and javadoc JARs, PGP signatures, POM metadata, checksums, etc. The latest Kotlin Toolchain does all of that for you – you declare what to publish, and we take care of the rest.

You will first need an account, a namespace, and a user token on the Maven Central Publisher Portal, as well as a PGP signing key. For everything else, the Kotlin Toolchain has you covered.

To publish to Maven Central, you don’t need to declare the repository by hand. Just add mavenCentral: enabled to your publication configuration, and configure everything that Maven Central requires. Here is a minimal example:

product: jvm/lib

description: A meaningful description for this specific module

settings:
  publishing:
    enabled: true
    group: com.example # the group has to match your Maven Central namespace
    version: 1.0.0
    # artifactId is optional, and defaults to your module's name
    mavenCentral: enabled
    signArtifacts: true # automatically sign your artifacts, no external GPG binary required
    publishSources: true
    pom:
      url: https://example.com
      scm: https://github.com/my-org/example.git # the SCM connection and dev connection are automatically derived from this
      developers:
        - name: John Doe
      licenses:
        - name: MIT
          url: https://opensource.org/license/mit

Check out the documentation to learn how to pass the credentials needed to sign artifacts and upload to the Maven Central Publisher Portal. After this, publishing is just one command away:

kotlin publish mavenCentral

This command builds and signs every artifact, zips them into a Maven Central deployment bundle, uploads the bundle, and awaits its validation. You can then check the deployment and finish the release via the Central portal UI. You can also skip manual verification and fully automate the release with publishingMode: auto if you trust the pipeline. Check out the documentation to read more about publishing modes.

Cinterop support

The Kotlin Toolchain now generates custom bindings for C libraries from the definition files (.def) placed inside the cinterop folder of a module.

The IDE also provides assistance by generating bindings during the project sync process.

Terminal UI improvements

We have made several improvements to the output of the kotlin command.

We have introduced better progress indicators for completed tasks, and the main progress bar is integrated with your terminal’s native progress indicator:

We have also improved how the diagnostics reported by the Kotlin JVM compiler are rendered (requires Kotlin 2.4.0 or newer):

IDE improvements

Library sources download

Sources for libraries are now downloaded automatically as a post-sync activity.

Because the sync is completed first, you can start working on the project straight away while sources are downloaded in the background.

Module-wide dependency resolution

Previously, dependency resolution in the IDE plugin was performed at the project level, unlike in the CLI. This could lead to an incorrect dependency version in a module or incorrect warnings in the editor. We have aligned the behavior with the CLI, so now each module has its own resolution scope, and all diagnostics are the same.

Plugin development improvements

Multiple new features are available for authors of local plugins, including the new checks and commands declarations, new APIs for task inputs, and diagnostic improvements.

New references

When authoring plugin.yaml to wire task inputs, a few built-in references can be used to access information about the project. We introduced two new ones to cover some common cases:

• ${project.rootDir} can be used to access the project’s root directory.
• ${module.classes} can be used to access the directory containing raw compiled class files.

Custom checks

The new kotlin check command is designed to make sure the project passes all quality checks. It runs the usual unit tests by default, and plugins can register additional checks that the command should run.

To introduce a custom check in a plugin, use the checks top-level list:

# my-lint-plugin/plugin.yaml
tasks:
  runLinter:
    action: !kotlinJavaLint
      sources: ${module.kotlinJavaSources}

checks:
  - name: lint
    performedBy: runLinter

The above lint check can also be run individually using kotlin check lint.

To list the checks that are in the project, use the kotlin show checks command. You can read more about custom checks in the plugins docs.

Custom commands

Sometimes you need to expose a public entry point for your plugin’s users. For example, you might want to provide the ability to generate a changelog, print some information on demand, or publish a custom distribution format. Because your plugin’s tasks should be considered private by default, we introduced a new concept called custom commands to represent these public entry points.

A custom command is implemented using a regular task, and as such, it can get data from the build (such as source files, compiled JARs, or runtime classpath information) and depend on other tasks. To register a command associated with your task, use the new commands top-level section in plugin.yaml:

# my-lint-plugin/plugin.yaml
tasks:
  updateBaseline:
    action: !runDetektForBaseline
      sources: ${module.kotlinJavaSources}
      outputFile: ${module.rootDir}/detekt/baseline.xml

commands:
  # shorthand when the name of the command matches that of the task
  - updateBaseline

You can then run this custom command using the new kotlin do command:

kotlin do updateBaseline

This will run the task associated with the command, as well as its dependencies.

To list all the custom commands available in the project, use kotlin show commands. Learn more about custom commands in the plugins docs.

A new way to register generated files

We introduced a new top-level section to plugin.yaml called generated, which allows registering generated sources, resources, and classes. As of 0.11.0, you can even register cinterop definitions when your task dynamically provisions native libraries:

tasks:
  generateStuff:
    action: !myGenerateStuffAction
      outputSources: ${taskOutputDir}/src
      outputResources: ${taskOutputDir}/res
      outputDefFiles: ${taskOutputDir}/cinterop

generated:
  sources:
    - directory: ${tasks.generateStuff.action.outputSources}
      language: kotlin
  resources:
    - directory: ${tasks.generateStuff.action.outputResources}
  cinteropDefinitions:
    - directory: ${tasks.generateStuff.action.outputDefFiles}

This replaces the markOutputAs property inside tasks, which is deprecated and will soon be removed. This way, all outputs that contribute back to the build are registered in a similar way and can be identified at a glance in their individual sections by humans, AI agents, and other tools.

Other improvements

lib renamed to kmp/lib

The lib product type was renamed to kmp/lib to better reflect what it represents after the introduction of the jvm/lib product type. The lib value is deprecated, and we plan to remove it in an upcoming Kotlin Toolchain version.

Nested templates

Templates can now apply other templates, allowing you to build a logical hierarchy of settings. The syntax is the same; simply use the apply section in your template files:

# spring.module-template.yaml
apply:
  - ./jvm.module-template.yaml

settings:
  springBoot: enabled

Maven classifier support

You can now add classifiers to Maven dependency notations to depend on a specific artifact of the library, for example:

dependencies:
  - io.netty:netty-transport-native-epoll:4.2.13.Final:linux-x86_64

run command improvements

We have improved the experience of the run command in cases when only one option is suitable for the current host.

If the project has multiple modules, but only one can run on the host machine, it is no longer necessary to specify the module explicitly. For example, given the following project:

.
├── linux-cli/
├── macos-cli/
├── windows-cli/
├── shared/
├── kotlin
├── kotlin.bat
└── project.yaml

kotlin run will launch the windows-cli module on a Windows machine.

If the specified module has multiple target platforms and only one of them can be run on the host machine, it is no longer necessary to specify the platform explicitly. For example, given the following module:

# linux-app/module.yaml
product: linux/app

# The platforms linuxArm64 and linuxX64 are both present by default

kotlin run -m linux-app will launch the ARM64 version of the app on an ARM machine and the x86-64 version of the app on an x86 machine.

Updated default versions

We updated some of the default versions for toolchains and frameworks:

• Kotlin 2.3.21
• Compose Hot Reload 1.1.1
• KSP 2.3.7
• Ktor 3.4.3
• SpringBoot 4.0.6
• Lombok 1.18.46
• JUnit Platform 6.0.3

Try Kotlin Toolchain 0.11.0

To get started with the Kotlin Toolchain, check out our Getting started guide. Take a look at some examples, follow a tutorial, or read the comprehensive user guide, depending on your learning style.

If you’ve been using Amper, you won’t be able to migrate your installation to the Kotlin Toolchain via the usual automatic update path. Instead, you should replace amper and amper.bat in your project with Kotlin wrappers. You can do so by installing the toolchain globally and then using the Kotlin CLI to generate the new Kotlin wrappers in your project:

kotlin update --create

After replacing the wrappers, you will be able to use kotlin update for future updates.

Share your feedback

The Kotlin Toolchain is still under active development. You can provide feedback about your experience by joining the discussion in the #kotlin-toolchain Slack channel or by sharing your suggestions and ideas in a YouTrack issue. Your input and use cases help shape the future of the Kotlin Toolchain!

• 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.