What's new in Kotlin 2.2.20-RC2

Improved overload resolution for lambdas with suspend function types

Previously, overloading a function with both a regular function type and a suspend function type caused an ambiguity error when passing a lambda. You could work around this error with an explicit type cast, but the compiler incorrectly reported a No cast needed warning:

With this change, when you define both a regular and a suspend function type overload, a lambda without a cast resolves to the regular overload. Use the suspend keyword to resolve to the suspend overload explicitly:

This behavior will be enabled by default in Kotlin 2.3.0. To test it now, set your language version to 2.3 using the following compiler option:

Or configure it in your build.gradle(.kts) file:

We would appreciate your feedback in our issue tracker, YouTrack.

Support for return statements in expression bodies with explicit return types

Previously, using return in an expression body caused a compiler error because it could cause the function's return type to be inferred as Nothing.

With this change, you can now use return in expression bodies as long as the return type is written explicitly:

Similarly, return statements inside lambdas and nested expressions in functions with expression bodies used to compile unintentionally. Kotlin now supports these cases as long as the return type is specified explicitly. Cases without an explicit return type will be deprecated in Kotlin 2.3.0:

This behavior will be enabled by default in Kotlin 2.3.0. To test it now, set your language version to 2.3 using the following compiler option:

Or configure it in your build.gradle(.kts) file:

We would appreciate your feedback in our issue tracker, YouTrack.

Swift export available by default

Kotlin 2.2.20-RC2 introduces experimental support for Swift export. It allows you to export Kotlin sources directly and call Kotlin code from Swift idiomatically, eliminating the need for Objective-C headers.

This should significantly improve multiplatform development for Apple targets. For example, if you have a Kotlin module with top-level functions, Swift export enables clean, module-specific imports, removing the confusing Objective-C underscores and mangled names.

The key features are:

• Multi-module support. Each Kotlin module is exported as a separate Swift module, simplifying function calls.

• Package support. Kotlin packages are explicitly preserved during export, avoiding naming conflicts in the generated Swift code.

• Type aliases. Kotlin type aliases are exported and preserved in Swift, improving readability.

• Enhanced nullability for primitives. Unlike Objective-C interop, which required boxing types like Int? into wrapper classes like KotlinInt to preserve nullability, Swift export converts nullability information directly.

• Overloads. You can call Kotlin's overloaded functions in Swift without ambiguity.

• Flattened package structure. You can translate Kotlin packages into Swift enums, removing the package prefix from generated Swift code.

• Module name customization. You can customize the resulting Swift module names in the Gradle configuration of your Kotlin project.

Shared source set for js and wasmJs targets

Previously, Kotlin Multiplatform didn't include a shared source set for JavaScript (js) and WebAssembly (wasmJs) web targets by default. To share code between js and wasmJs, you had to manually configure a custom source set or write code in two places, one version for js and another for wasmJs. For example:

Starting with this release, the Kotlin Gradle plugin adds a new shared source set for web (comprising webMain and webTest) when using the default hierarchy template.

With this change, the web source set becomes a parent of both js and wasmJs source sets. The updated source set hierarchy looks like this:

The new source set allows you to write one piece of code for both the js and wasmJs targets. You can put your shared code in webMain and it automatically works for both targets:

This update simplifies code sharing between the js and wasmJs targets. It is particularly useful in two cases:

• For library authors who want to add support for both js and wasmJs targets, without duplicating code.

• For developers building Compose Multiplatform applications that target the Web, enabling cross-compilation to both js and wasmJs targets for wider browser compatibility. Given this fallback mode, when you create a website, it will work on all browsers out of the box: modern browsers use wasmJs, and older browsers use js.

To try this feature, use the default hierarchy template in the kotlin {} block of your build.gradle(.kts) file:

Before using the default hierarchy, consider carefully any potential conflicts if you have projects with a custom shared source set or if you renamed the js("web") target. To resolve these conflicts, rename the conflicting source set or target, or don't use the default hierarchy.

Stable cross-platform compilation for Kotlin libraries

Kotlin 2.2.20-RC2 completes an important roadmap item, stabilizing cross-platform compilation for Kotlin libraries.

You can now use any host to produce .klib artifacts for publishing Kotlin libraries. This significantly streamlines the publishing process, particularly for Apple targets that previously required a Mac machine.

The feature is available by default. If you have already enabled cross-compilation with kotlin.native.enableKlibsCrossCompilation=true, you can now remove it from your gradle.properties file.

Unfortunately, a few limitations are still present. You still need to use a Mac machine if:

• Your library or any dependent modules have cinterop dependencies.

• You have a CocoaPods integration set up in your project.

• You need to build or test final binaries for Apple targets.

For more information about the publication of multiplatform libraries, see our documentation.

New approach for declaring common dependencies

To simplify setting up multiplatform projects with Gradle, Kotlin 2.2.20-RC2 now lets you declare common dependencies in the kotlin {} block by using a top-level dependencies {} block. These dependencies behave as if they were declared in the commonMain source set. This feature works similarly to the dependencies block that you use for Kotlin/JVM and Android-only projects, and it's now Experimental in Kotlin Multiplatform. Declaring common dependencies at the project level reduces repetitive configuration across source sets and helps streamline your build setup. You can still add platform-specific dependencies in each source set as needed.

To try this feature, opt in by adding the @OptIn(ExperimentalKotlinGradlePluginApi::class) annotation before the top-level dependencies {} block. For example:

We would appreciate your feedback on this feature in YouTrack.

Support for stack canaries in binaries

Starting with 2.2.20-RC2, Kotlin adds support for stack canaries in the resulting Kotlin/Native binaries. As part of stack protection, this security feature protects against stack smashing, mitigating some common application vulnerabilities. Already available in Swift and Objective-C, it's now supported in Kotlin as well.

The implementation of stack protection in Kotlin/Native follows the behavior of the stack protector in Clang.

To enable stack canaries, add the following binary option to your gradle.properties file:

The property enables the feature for all the Kotlin functions that are vulnerable to stack smashing. Alternative modes are:

• kotlin.native.binary.stackProtector=strong, which uses a stronger heuristic for the functions vulnerable to stack smashing.

• kotlin.native.binary.stackProtector=all, which enables stack protectors for all functions.

Note that in some cases, stack protection might come with a performance cost.

Smaller binary size for release binaries

Kotlin 2.2.20-RC2 introduces the smallBinary option that can help you decrease the binary size for release binaries. The new option effectively sets -Oz as the default optimization argument for the compiler during the LLVM compilation phase.

With the smallBinary option enabled, you can make release binaries smaller and improve build time. However, it might affect runtime performance in some cases.

The new feature is currently Experimental. To try it out in your project, add the following binary option to your gradle.properties file:

The Kotlin team is grateful to Troels Lund for his help in implementing this feature.

Improved debugger object summaries

Kotlin/Native now generates clearer object summaries for debugger tools like LLDB and GDB. This improves the readability of the produced debug information and streamlines your debugging experience.

Previously, if you inspected an object such as:

You'd see limited information, including a pointer to the memory address:

With Kotlin 2.2.20-RC2, the debugger shows richer details, including the actual values:

The Kotlin team is grateful to Nikita Nazarov for his help in implementing this feature.

For more information on debugging in Kotlin/Native, see the documentation.

Separated npm dependencies

Previously, in your Kotlin/Wasm projects, all npm dependencies were installed together in your project folder. It included both your own dependencies and Kotlin tooling dependencies. These dependencies were also recorded together in your project's lock files (package-lock.json or yarn.lock).

As a result, whenever Kotlin tooling dependencies were updated, you had to update your lock files even if you didn't add or change anything.

Starting from Kotlin 2.2.20-RC2, the Kotlin tooling npm dependencies are installed outside your project. Now, the tooling and the user dependencies have separate directories:

• Tooling dependencies' directory:

  <kotlin-user-home>/kotlin-npm-tooling/<yarn|npm>/hash/node_modules

• User dependencies' directory:

  build/wasm/node_modules

Also, the lock files inside the project directory contain only user-defined dependencies.

This improvement keeps your lock files focused only on your own dependencies, helps maintain a cleaner project, and reduces unnecessary changes to your files.

This change is enabled by default for the wasm-js target. The change is not yet implemented for the js target. While there are plans to implement it in future releases, the behavior of the npm dependencies remains the same for the js target in Kotlin 2.2.20-RC2.

Improved exception handling in Kotlin/Wasm and JavaScript interop

Previously, Kotlin had difficulty understanding exceptions (errors) thrown in JavaScript (JS) and crossing over to Kotlin/Wasm code.

In some cases, the issue also occurred in the reverse direction, when an exception was thrown or passed through the Wasm code to JS and wrapped into WebAssembly.Exception without any details. These Kotlin exception handling issues made debugging difficult.

Starting from Kotlin 2.2.20-RC2, the developer experience with exceptions improves in both directions:

• When exceptions are thrown from JavaScript: you can see more information on Kotlin's side. When such an exception propagates through Kotlin back to JS, it's no longer wrapped into WebAssembly.

• When exceptions are thrown from Kotlin: they can now be caught on JavaScript's side as JS errors.

The new exception handling works automatically in modern browsers that support the WebAssembly.JSTag feature:

• Chrome 115+

• Firefox 129+

• Safari 18.4+

In older browsers, the exception handling behavior remains unchanged.

Usage of BigInt type to represent Kotlin's Long type

Before the ES2020 standard, JavaScript (JS) did not support a primitive type for precise integers larger than 53 bits.

For this reason, Kotlin/JS used to represent Long values (which are 64-bit wide) as JavaScript objects containing two number properties. This custom implementation made interoperability between Kotlin and JavaScript more complex.

Starting with Kotlin 2.2.20-RC2, Kotlin/JS now uses JavaScript's built-in BigInt type to represent Kotlin's Long values when compiling to modern JavaScript (ES2020).

This change enables exporting the Long type to JavaScript, a feature also introduced in 2.2.20-RC2. As a result, this change simplifies the interoperability between Kotlin and JavaScript.

To enable it, add the following compiler option to your build.gradle(.kts) file:

This feature is still Experimental. Please report any problems in our issue tracker, YouTrack.

New DSL function for cleaner arguments

When running a Kotlin/JS application with Node.js, the arguments passed to your program (args) used to include:

• The path to the executable Node.

• The path to your script.

• The actual command-line arguments you provided.

However, the expected behavior for args was to include only the command-line arguments. To achieve this, you had to manually skip the first two arguments using the drop() function inside your build.gradle(.kts) file or in your Kotlin code:

This workaround was repetitive, error-prone, and didn't work well when sharing code between platforms.

To fix this issue, Kotlin 2.2.20-RC2 introduces a new DSL function called passCliArgumentsToMainFunction().

With this function, the arguments only include the command-line arguments and exclude the Node and script paths:

This change reduces boilerplate code, avoids mistakes caused by manually dropping arguments, and improves cross-platform compatibility.

To enable this feature, add the following DSL function inside your build.gradle(.kts) file: