Technology
Kotlin Multiplatform: Write Code Once

Write code in your favorite programming language, run it everywhere. Oh, and save money while doing it. In just a few years this might be reality, provided you like Kotlin.

For some time now I have been following Kotlin Multiplatform. I already liked to program in Kotlin as an alternative to Java and Scala, after I was introduced to it while working on an Android app. Features like explicit nullability, explicit mutability, good functional programming support and a clean syntax make programming in Kotlin a breeze. Also, while working on this app, I noticed that we were basically building some parts of the app three times. Besides being wasteful, this also required more coordination and poses a risk for bugs. Kotlin Multiplatform could be the solution to this.

Assume you are working on an app

This app consists of a backend API written in Java, Android and iOS apps and you even have a web site where some of the functionality is available as well.

To test your API, you will likely implement a Java API client for your integration tests. Meanwhile, the Android app also contains an API client. Implementing this client only once is easily done, as both platforms run Java code. But for your web site and iOS app this is obviously not so easy.

Implementing such a client multiple times is a waste of resources, but besides that, it also introduces risk. Every change to your API now requires changes in three places (JVM, iOS, JavaScript). Additionally, in three places mistakes can be made, for example by interpretation differences, different parsing logic or platform defaults that differ. If I had to say which client I would trust the most, it would be the JVM client. As this is the client used to test the API, I’m pretty sure it works with that same API without many issues.

Kotlin multiplatform to the rescue

Instead of writing Java, we can use Kotlin. It is a pretty much drop-in replacement and allows for a smooth transition. If we do this smartly, we could even try to make our client a multiplatform project, allowing us to use this code on iOS and in the browser as well.

So how does this work?

There are multiple flavors of Kotlin, namely Kotlin/JVM (a.k.a. “Kotlin”), Kotlin/JS and Kotlin/Native. Kotlin Multiplatform combines all these flavors into a single project. From one Kotlin codebase Kotlin Multiplatform can build artifacts for all platforms, a jar for JVM, a JavaScript module for the browser and a Swift framework for iOS.

A project starts out with common code, which is plain Kotlin using only the standard library. This already works for each platform, but in many cases some platform-specific glue is needed. Luckily, this can also be written in Kotlin.

It does not make sense if every developer has to write the same (or similar) glue code for every project, so many common integrations are already available as libraries. From the makers of Kotlin themselves there are HTTP client/server libraries, serialization libraries and testing libraries, just to give a few examples. Additionally, it is quite easy to publish a multiplatform library yourself, in case something is missing.

The “write code once” approach is also noticeable when looking at unit tests. Tests that are written for the common code are executed on each target. A single test can thereby validate the implementation for each supported platform.

What now?

Based on the story above you are probably thinking “why is not everyone doing this?”

Well, high-profile applications usually go for trusted technology, not something that might break (and cost way more that way then was saved by adopting the new technology).

At the time of writing, Kotlin 1.4 just released. This release included many improvements to Multiplatform, including bumping it from “experimental” state to “alpha”. It does not feel polished enough yet to start using it in high-profile projects though, but it will definitely be interesting to see where it goes the coming years. If you are reading this blog post in 2023, please also have a look at the follow-up post on this blog (provided I did not forget to write one).