Kotlin Toolchain 0.12: Multiplatform Library Publishing, Wasm Apps, and More

Kotlin
A concise multiplatform language developed by JetBrains
Kotlin Toolchain 0.12: Multiplatform Library Publishing, Wasm Apps, and More
Kotlin Toolchain 0.12.0 is out. This release brings some long-awaited features: multiplatform libraries publication, a preview of Wasm application support, Compose Hot Reload from the command line, and more.
Read on for the details, and check the release notes for the full list of changes and bug fixes.
Additionally, klibs.io now uses the Kotlin Toolchain in production. A real backend and not a sample, it’s built on JDK 21, Spring Boot 4 (with Spring AI), PostgreSQL, and OpenSearch. We’ve converted nine convention plugins to Kotlin Toolchain templates, and two Gradle plugins with no built-in equivalent: Jib and Git Properties, which we’ve implemented as local Kotlin Toolchain plugins. Check out the sources yourself.
To get support for Kotlin Toolchain’s latest features, use IntelliJ IDEA 2026.2.1 (or newer). Make sure the latest version of the Kotlin Toolchain plugin is installed.
Kotlin Multiplatform libraries publication
Library publishing arrived in preview in 0.11, but only for JVM libraries. Starting with 0.12, multiplatform libraries work too, with exactly the same configuration:
product: type: lib platforms: [jvm, android, iosArm64, iosSimulatorArm64, wasmJs] settings: publishing: enabled: true group: org.example version: 1.0.0
The Kotlin Toolchain publishes everything your users need to depend on your library from any of its targets: the common API, one artifact per platform, the sources, and the module publication metadata that lets build tools pick the right pieces automatically.
Cinterop bindings are supported as well. They are published both commonized and per platform, so your users get the same C API you compiled against without setting up interop themselves. The result is consumable from Gradle projects like any other multiplatform library.
For more details, see the documentation.
Note: Resources of Compose Multiplatform libraries are not part of the publication yet. Follow KTC-5698 for progress.
Better compliance with Maven Central quotas
Because of the new quotas on Maven Central publications that Sonatype will soon enforce, we made a few notable changes to reduce the number of files published by default:
- Checksums of signature files (
.asc.sha1
) are not necessary and are no longer published. - Only the
.md5
and.sha1
checksums are published by default now. If you need to continue publishing the.sha256
and.sha512
checksums, usesettings.publishing.checksums: [md5, sha1, sha256, sha512]
.
Wasm application support
wasm-js/app
modules can now be built into a ready-to-use web application.
Among the supported features are:
- Running Wasm apps with the
kotlin run
command. - Customizing
index.html
and other resources. - Fetching transitive npm dependencies from Kotlin Multiplatform libraries.
More information on working with Wasm web applications is available in the documentation.
Terminal UI improvements
We are actively working to make the output of the kotlin
command less verbose and more user-friendly.
Diagnostics
For example, here are some of the recent diagnostics improvements:
Tests in the status widget
Running tests are now visible in the status widget under the respective tasks and their suites. There are also short test execution statistics visible during the run.
There are more things to iron out, but we’ll get there.
IDE improvements
Compose preview support
Android modules and kmp/lib
modules that have Android as one of their targets now support the Compose preview feature, powered by the androidx.compose.ui.tooling.preview.Preview
annotation and the Android plugin.
Better support for Compose resources
The IDE now correctly recognizes Compose resources, updates Res
classes on the fly, provides navigation, completion, and refactorings that update both XMLs and your code.
Android tooling improvements
Adding to the Compose preview support mentioned above, we have also brought support for more of the Android features you are accustomed to, such as:
- Android Lint
- Live Edit
- Layout Inspector
- Resources (
R
class) navigation and completion
iOS improvements
Starting with IntelliJ IDEA 2026.2.1, the experience of working with iOS applications should be closer to what you’re used to in Gradle projects.
The run configuration now lets you pick a device, configure Xcode options, and choose a debug/release configuration mode.
We’ve also fixed a few issues with Kotlin/Swift interoperability, which should be more stable now.
Inlay hints with coordinates of catalog dependencies
Catalog dependencies in module files and templates now have an inlay hint next to them displaying coordinates that each entry points to.
Better Compose Hot Reload support
We now properly support Compose Hot Reload from the command line using the kotlin run --compose-hot-reload-mode
command.
General improvements
- The very first reload is now much faster and the build should consume fewer resources.
- The Restart the application action from the DevTools menu is now supported.
Compose Hot Reload MCP
We now support an MCP server for agents to interact with applications running with Compose Hot Reload.
To get started, add the following snippet in your mcp.json
:
{ "mcpServers": { "Compose Hot Reload": { "command": "./kotlin", "args": [ "compose-hot-reload-mcp-server" ] } } }
With this, agents can interact with, reload, restart, and view window snapshots, and dump the tree of composables. Read more about these capabilities here.
Other improvements
New recommended local dependency format using the //
prefix
Previously, the only way to define local module dependencies was to use relative paths starting with the .
(dot) symbol. This approach had several problems. For example, moving a module from one directory level to another required changing all the dependency paths, such as from../../foo
to ../foo
. And having a multitude of ../
in deeply nested directory structures generally made paths hard to read.
The new recommended way to define local module dependencies is to use project-root-relative paths starting with the //
prefix. You might be familiar with this syntax from tools like Bazel. The //
prefix represents the project root directory and can be used not only in the dependencies
block but in any place that expects a path as well, for example, apply
.
The old relative-paths approach still works for now.
This is a step toward allowing multiple modules with the same directory name.
Raised minimum JDK and Kotlin versions
Until now, the minimum JDK version supported by the Kotlin Toolchain was not clearly documented anywhere, and the build would just fail in different places if you used a JDK that was too old. There is now a clear diagnostic and a clear minimum: only JDK 17 and higher are supported to compile your code. You can still use settings.jvm.release
to set a lower target if your code should be runnable on lower JREs.
The minimum Kotlin compiler version was raised from 2.1.10 to 2.2.20. This allows simplifying our code, and is in line with the new security support policy for the Kotlin standard library.
Updated default versions
We’ve also updated some of the default versions for built-in toolchains and frameworks:
- Kotlin 2.4.10
- JDK 25
- JUnit Platform 6.1.3
- KSP 2.3.11
- Ktor 3.5.2
- Spring Boot 4.1.0
- DataFrame 1.0.0-rc01
- Kotlinx.rpc 0.10.3
Try Kotlin Toolchain 0.12.0
To get started with the Kotlin Toolchain, check out our Getting started guide. Take a look at some examples, follow the tutorial, or read the comprehensive user guide, depending on your learning style.
To update an existing project, use the kotlin update
command.
Share your feedback
The Kotlin Toolchain is still in Alpha and under active development. You can provide feedback about your experience by joining the discussion in the #kotlin-toolchain Slack channel (get invite: https://kotl.in/slack or by sharing your suggestions and ideas in a YouTrack issue. Your input and use cases help shape the future of the Kotlin Toolchain!

Facts Only

* Kotlin Toolchain 0.12.0 was released.
* Multiplatform libraries can now be published with the following configuration: product, type, platforms [jvm, android, iosArm64, iosSimulatorArm64, wasmJs], settings: publishing enabled: true, group: org.example, version: 1.0.0.
* Cinterop bindings are supported and published as commonized and per-platform artifacts.
* Default publication changes restrict checksums to .md5 and .sha1; other checksums require explicit settings.
* Wasm application modules can be built into web applications with features like running via `kotlin run` and customizing `index.html`.
* Compose preview support was added for Android modules and KMP/lib modules using the androidx.compose.ui.tooling.preview.Preview annotation.
* IDE improvements include better Compose resource recognition, updates to Res classes, and enhanced Android tooling features (Lint, Live Edit, Layout Inspector).
* iOS work experience improves with device selection in run configurations and fixes to Kotlin/Swift interoperability.
* Local module dependencies should use project-root-relative paths starting with // for dependency definitions.
* Minimum supported JDK version is now clearly defined as JDK 17 or higher.
* The minimum Kotlin compiler version was raised to 2.2.20.

Executive Summary

The Kotlin Toolchain 0.12.0 release introduces multiplatform library publishing support, allowing for the publication of multiplatform libraries with a unified configuration across JVM, Android, iOS, and Wasm targets. This is supported alongside Cinterop bindings, which are published in both commonized and per-platform forms. The release also addresses Maven Central quota concerns by changing default checksum publication to favor .md5 and .sha1 files, requiring explicit settings for broader checksum support. Furthermore, Wasm application support is introduced, enabling the building of web applications with command-line running and resource customization. IDE improvements include Compose preview support for Android modules and KMP/lib modules, better recognition of Compose resources, enhanced Android tooling features like Lint and Layout Inspector, and improvements to the iOS experience in IntelliJ IDEA 2026.2.1. General quality-of-life updates include faster reloads, new dependency formatting using the // prefix, and a support for an MCP server for Compose Hot Reload agents. Minimum requirements have been raised, supporting JDK 17+ and Kotlin compiler version 2.2.20.

Full Take

The evolution of the Kotlin Toolchain reflects a strategic shift toward providing holistic, end-to-end multiplatform tooling, integrating low-level library concerns with high-level application deployment experiences. The introduction of full multiplatform library publication suggests an effort to eliminate friction points in the ecosystem where cross-platform artifact management was previously fragmented. The Wasm support signals a commitment to extending Kotlin's reach beyond traditional JVM targets into modern web deployment paradigms, positioning Kotlin as a viable solution for full-stack development.
The changes regarding Maven Central quotas and dependency formatting illustrate a necessary adaptation to external infrastructure constraints and internal code maintainability. Restricting default checksums suggests balancing ecosystem utility against external policy pressures, while mandating the new path-relative dependency syntax is a move toward enforcing structural consistency in large, modular projects. The focus on IDE integration—improving Compose preview support across Android and KMP targets—indicates that tooling maturity is now directly tied to the perceived quality of the language's multiplatform capabilities.
The pattern observed is one of increasing integration density: moving from simply compiling Kotlin code to publishing cohesive, runnable artifacts across diverse targets (JVM, iOS, Wasm) with synchronized build and IDE experiences. The implications point toward a future where the toolchain itself acts as a unified layer that manages complexity at every level, shifting developer focus from platform-specific plumbing to cross-platform architecture design. What is being balanced here is the need for cutting-edge features (like Wasm and Compose Hot Reload MCP) against the stability requirements imposed by external systems and community expectations, forcing a negotiation between innovation speed and infrastructural consensus.
Bridge Questions: If multiplatform publishing becomes the standard, how will dependency resolution mechanisms evolve to handle complex, non-linear cross-target dependencies more efficiently? What are the long-term governance strategies for maintaining synchronization across platform-specific tooling (like Android and iOS toolchains) as they rapidly advance? How does this push for unified tooling change the perceived necessity of keeping distinct targets separate?

Sentinel — Human

Confidence

This text reads like an official, technically dense release announcement, demonstrating high specificity and internal knowledge typical of human authorship within a development context.

Signals Detected

Moderate sentence length variance and technical detail; rhythm is functional rather than perfectly metronomic.

High internal coherence, structured around feature updates; lacks the hyper-balanced framing typical of pure AI synthesis.

Structured listing of features and specific code/configuration changes suggests direct developer communication rather than generic reporting.

Specific, granular details (e.g., KTC-5698 reference, specific checksum changes, version numbers) point toward internal documentation or direct source reporting.

Human Indicators

The inclusion of specific technical migration paths, file format recommendations (// prefix), and links to internal tracking systems (#kotlin-toolchain Slack, YouTrack issue) strongly suggests input from a project team or developer communication.

The tone mixes marketing language ('long-awaited features') with very precise, low-level configuration details, a hallmark of technical release notes written by the implementers.