Everything to Know About Kotlin 1.9.20

Kotlin is one of the most dominating programming languages added to the market by JetBrains. Today, Kotlin has become a one-stop solution for businesses to develop Android app development,   surpassing Java to a greater extent. According to the reports, more than 50% of developers are showing their complete reliance on Kotlin for Android app development. But what’s so great about Kotlin, and what has led them to take over the entire app development market? Well, that’s their team that keeps on introducing new releases to boost the efficiency of the language, allowing developers to develop more technology-driven and feature-rich mobile apps. 

On 1 November 2023, they popped up a new release, Kotlin 1.9.20. Yes, you heard it right, the latest release up and running. This release brings it on the K2 Compiler all of the beta targets, multiplatform acquires the stability and various other improvements and features that set you on top of trends to enhance the performance of your applications. Continue reading the blog to discover what the Kotlin latest release puts into action.

What’s New Kotlin 1.9.20 added to the release?

Kotlin latest version, 1.9.20, is the signature release that brings up some impressive improvements to level up the quality of Kotlin app development services. Let’s get to business and explore the sea of improvements with Kotlin’s latest release.

Kotlin Multiplatform

Kotlin 1.9.20 strengthens Kotlin Multiplatform stability and simplifies developer workflows with new project wizards, among other improvements:

Kotlin Multiplatform is Stable

Kotlin Multiplatform has finally become stable with the 1.9.20 release, marking an important step forward in Kotlin’s evolution. Using the technology in your projects means it is safe and ready for use. Furthermore, Kotlin Multiplatform will continue to develop.

Template for configuring multiplatform projects

Beginning with Kotlin 1.9.20, a Kotlin Gradle plugin generates cross-platform shared source sets automatically. In the case of one of these setups, there is no need to configure the source set hierarchy manually. It is simply a matter of specifying the targets required for your project explicitly.

Kotlin Gradle now includes a default hierarchy template, which simplifies setup. The source set hierarchy is a predefined template built into the plugin. For the targets you declared, Kotlin creates intermediate source sets automatically.

Full support for the Gradle configuration cache in Kotlin Multiplatform

For Kotlin multiplatform libraries, a preview of the Gradle configuration cache was previously available. In Kotlin Multiplatform 1.9.20, the plugin takes another step forward.

As well as supporting Gradle configuration caches in Gradle plugins for Kotlin CocoaPods, it now supports embedAndSignAppleFrameworkForXcode integration tasks required for Xcode builds.

Multiplatform projects now benefit from improved build times. Gradle’s configuration cache makes building faster by reusing configuration results across builds.

Kotlin/Native

Kotlin 1.9.20 introduces a new memory allocator with a Stable memory manager by default, improved garbage collection performance, and other improvements:

Custom memory allocator enabled by default. 

By default, Kotlin 1.9.20 features memory allocation. It replaces mimaloc, previously the default memory manager, by improving garbage collection efficiency.

System memory is divided into pages by a new custom allocator, allowing consecutive sweeps to be performed independently. Allotments are organized within pages as memory blocks, and the page keeps track of the size of each block. 

The size of allocations is optimized for different page types. As the memory blocks are arranged sequentially, iteration through each block is efficient.

Performance improvements for the garbage collector

The new Kotlin/Native memory manager continues to be improved and stabilized by the Kotlin team. With 1.9.20, the garbage collector (GC) receives several significant updates, including:

• Full parallel mark to reduce the pause time for the GC
• Tracking memory in big chunks to improve the allocation performance

Incremental compilation of klib artifacts

With Kotlin 1.9.20, a new compiler time optimization is introduced for Kotlin/Native. Now, klib artifacts are partially incrementally built into native code.

The Kotlin source code is compiled into native binary for debugging in two stages:

• Klib artifacts are compiled from source code.
• Compiled klib artifacts, together with their dependencies, are packaged into executables.

During the second stage, compilation time has been optimized by building dependency caches. Every time a binary is compiled, the result is reused once converted into native code. However, each time a project was changed, klib artifacts were fully recompiled into native code.

Using incremental compilation, only a part of klib is recompiled into a binary if the project module change only requires a partial recompilation.

Managing library linkage issues

A new release improves how Kotlin/Native deals with linkage issues in Kotlin libraries. There are now more readable error messages, using signature names instead of hashes, making it easier to locate the problem and fix it, for example:

There is no function found for the symbol ‘org.samples/MyClass.removedFunction|removedFunction(kotlin.Int;kotlin.String)[][0]’.

It is possible to detect and report linkage issues between third–party Kotlin libraries using the Kotlin/Native compiler at run time. Incompatible changes can occur following the changes in one Kotlin library’s experimental APIs that another Kotlin library uses.

Opt-in requirement for all Cinterop declarations

From Kotlin 1.9.20 onward, every Kotlin declaration generated by the cinterop tool from C libraries, such as libcurl and libxml, is marked with @ExperimentalForeignApi. Coders will not be able to compile their code without the opt-in annotation.

As a result of this requirement, the C and Objective-C libraries are still considered experimental. Using it in your projects should be limited to specific areas. Upon stabilizing the import, your migration will be easier.

Custom message for linker errors

You can now create custom messages for your library users to help them resolve linker errors.

Using the CocoaPods integration, Kotlin libraries may require C or Objective-C libraries to be installed locally on the machine, or the project build script may specify these libraries explicitly. This would result in a confusing “Framework not found” error message.

Compilation failure messages can now include specific instructions or links. It is possible to accomplish this with the -Xuser-setup-hint compiler option or by setting the userSetupHint=message property.

Removal of the legacy memory manager

With Kotlin 1.6.20, the new memory manager was introduced. 1.7.20 introduced it as the default. Afterward, it got enhancements and performance improvements and is now stable.

Until the legacy memory manager has been removed, the deprecation cycle will end. If you still wish to use it, remove the kotlin.native.binary.memoryModel=strict setting from your gradle.properties file.

New Kotlin K2 compiler updates

Its team is actively working to stabilize the new K2 compiler, which will provide major performance improvements, make it faster to develop new language features, and make multiplatform development more robust.

Gradle

The Kotlin 1.9.20 release is compatible with the Gradle versions 6.8.3 to 8.1. If you use Gradle versions earlier than 8.1, deprecation warnings may appear, or some Gradle features may not work properly. Changes in this version include:

Access to internal declarations for test fixtures

With Kotlin 1.9.20, you can access internal declarations within source set classes using the java-test-fixtures plugin in Gradle. Test fixtures classes also expose any internal declarations within their classes to any test sources.

New property to configure paths to Konan directories

Kotlin 1.9.20 now introduces the kotlin.data.dir Gradle property, which allows you to specify your path to the Konan directory without configuring it via environment variables.

If you’d rather, you can use the -Xkonan-data-dir argument to specify a different path to the /konan directory.

New build report metrics for Kotlin/Native tasks

With Kotlin 1.9.20, metrics for Kotlin/Native have been added to Gradle build reports.

Kotlin/Wasm

Here are some of the major improvements that come down with Kotlin/Wasm. Here are some of the following versions that makes the development easier: 

Compatibility with Wasm GC phase 4 and final opcodes

Wasm GC moves to its final phase and needs to update its opcodes, which are constants that make up binary representations. Kotlin 1.9.20 is the latest version supporting the latest opcodes, which means your Wasm projects should be updated to the latest version. With the Wasm environment, you should also use the latest versions of browsers:

• Chrome and Chromium-based browsers should be running version 119 or newer.
• Firefox version 119 or newer is required. Firefox 119 requires you to manually enable Wasm GC.

New wasm-wasi target, and the renaming of the wasm target to wasm-js

With this release, we added a new Wasm/Kotlin target – wasm-wasi. The wasm target will also be renamed to wasm-js. Gradle is able to access these targets as wasmWasi [] and wasmJs [].

If you want to use these targets in your project, update the build.gradle.kts file as follows:

kotlin {   wasmWasi {      // …   }    wasmJs {       // …    } }

Prior to this release, the wasm {} block was phased out to make way for wasmJs {}.

Follow these steps for migrating your Kotlin/Wasm projects:

• Rename the wasm [] block in build.gradle.kts to wasmJs {}.
• Change the name of the wasmMain directory in your project structure to wasmJsMain.

Support for the WASI API in the standard library

WASI, a system interface for Wasm, has been added to this release. Kotlin/Wasm support through WASI provides a standardized API for accessing system resources, allowing you to use it outside of browsers, such as in server-side applications. WASI also provides capability-based security – an extra layer of security when connecting to external servers.

The VM you use for Kotlin/Wasm applications needs to support Wasm Garbage Collection (GC). Examples include Node.js and Deno. It is still difficult to support Wasm GC fully, but Wasmtime, WasmEdge, and others are working on it in parallel.

WASI functions can be imported using the @WasmImport annotation:

import kotlin.wasm.WasmImport

@WasmImport(“wasi_snapshot_preview1”, “clock_time_get”)

private external fun wasiRawClockTim

Kotlin/Wasm API improvements

The Kotlin/Wasm API has been improved with this release as a quality-of-life improvement. When listening for DOM events, a return value is no longer needed:

Before 1.9.20

fun main() {window.onload = {     document.body?.sayHello()     null } }

In 1.9.20

fun main() {    window.onload = { document.body?.sayHello() }}

Conclusion 

With the latest version of Kotlin, you have the advantage of making the most of the programming language. With Kotlin 1.9.20, you raise the level of Kotlin development services. To bring world-class expertise to the table, it is highly advisable to hire Kotlin app developers today to stay updated with the Kotlin latest version.