Kotlin Multiplatform – A remedy for all mobile app development?


Ever since mobile apps were built there was a desire to have a single codebase that can run upon multiple platforms. Way more solutions and technologies saw the light of day than I can think and can keep track of and with Kotlin Multiplatform (Mobile) there is a (fairly) new player in town. Is this new player in town worth to invest your valuable time in? In this article, we’ll explore Kotlin Multiplatform, what it is, how it is different from what already is available, how it works, and finally arrive at a conclusion as to why you should at least try it in one of your next mobile projects.


So, what is Kotlin Multiplatform Mobile?

Some say Kotlin Multiplatform Mobile is an SDK, a mechanism, an extension or even a way of living. In my opinion it doesn’t really matter what it is, although Jetbrains, the company behind Kotlin, says it’s an SDK, as long as it does what it says it does. Kotlin Multiplatform Mobile is a subset of Kotlin Multiplatform and allows you to write business logic code for both iOS and Android from within a single codebase. While the superset, Kotlin Multiplatform, enables you to include other platforms like Linux, Windows and the web (JavaScript). Kotlin Multiplatform Mobile projects are still considered alpha, which means features and tooling may change in future Kotlin releases, but nonetheless it is getting more mature fast, with almost all its components already considered beta.


Okay, but how is it different than what is already known?

It really is not, at least if you compare the goals of most – if not all – other solutions with each other. Most – if not all – solutions aim to make developing apps easier and more maintainable. They differ by how they are achieving that goal and, in my opinion, most compelling difference between Kotlin Multiplatform Mobile and most other solutions is that Kotlin Multiplatform Mobile allows you to run compiled code straight onto native platforms, without the code being run using a virtual machine or in a webview-like solution. The second big difference is that Kotlin Multiplatform Mobile guarantees a full native user experience, because (for now) it doesn’t support sharing UI logic across platforms, which means iOS developers have no other option but to use Apple’s frameworks. With Xamarin a similar approach can be used. Solutions like React Native (and other webview-like solutions) need to bridge code between the native OS platforms and JavaScript. This causes performance issues and on top of that the animations are not as satisfactory as within native apps. Flutter solves many of these issues common to React Native, and thus it also doesn’t guarantee a full native user experience. The table below displays a few of the main differences between a couple of widely adopted other solutions.


Now, how does it work?

Kotlin Multiplatform (Mobile) enables you to write common (Kotlin) code for your business logic, which is then usable on every platform supported, because all code gets compiled to bytecode for Android and native for iOS. When you need to write code that needs to access platform-specific APIs you can use the Kotlin mechanism of expected and actual declarations. With this mechanism, a common source set defines an expected declaration, and platform source sets must provide the actual declaration that corresponds to the expected declaration as seen below in the small code example. One of the key benefits is that you can use code from platform-dependent libraries like Foundation and UIKit for iOS.

// Common
expect fun randomUUID(): String
// Android
import java.util.*
actual fun randomUUID() = UUID.randomUUID().toString()
// iOS
import platform.Foundation.NSUUID
actual fun randomUUID(): String = NSUUID().UUIDString()

With this knowledge it is possible to leverage the advantage of this mechanism and move as much code to the shared library as possible and thus make the actual native app as ‘dumb’ as possible. Ideally the native app is only used to link the UI with the actual shared library. Using Kotlin Multiplatform I think that it should be possible to share 70-80% of code across mobile platforms and even up to maybe 90% on “simple” apps. Adding a new platform will solely be a matter of implementing UI code.


Why should I choose Kotlin Multiplatform Mobile for my next project?

  • It has no overhead as it compiles to bytecode for Android and native for iOS.
  • Many Android developers are already familiar with Kotlin and the Gradle build system, it’s a little to no change for them.
  • Not sharing the UI can be a curse or a blessing. While reducing code by writing UI once, this can come at the expense of reduced user experience as every platform has its own way / method of interaction, guidelines and so on, this can either be a curse or a blessing: Everyone bakes his cake as he likes to eat it.
  • Due to the interop with the other platform specific languages Kotlin Multiplatform allows you to write Java, Swift or Objective-C code and use Kotlin code within those languages and vice-versa.
  • It is also possible to use platform-specific libraries and even choose a totally different library for let’s say logging where each platform defines a complete other interface to log (you need to define what functions should be called using the expect/actual-mechanism, but this opens up for tons of possibilities).


Are there any downsides?

Of course. If there are advantages there are probably also disadvantages, which is also the case for Kotlin Multiplatform (Mobile).

  • Kotlin Multiplatform (Mobile) projects are considered alpha, so in future Kotlin releases features and or tooling may change.
  • It has a relatively smaller community as compared to React Native or Flutter, which means it is possible there will not be an answer for all your questions or problems. I personally haven’t experienced it yet, but it is possible.
  • For iOS-only developers, with no Kotlin or Gradle experience, it means a new build system and/or language should be learned.
  • Objective-C interop (still) has its limitations. Inline classes and custom classes implementing standard Kotlin collection interfaces aren’t fully supported.


How do I get started?

I won’t get into too much detail about how you can get started. This isn’t supposed to be a how-to guide, but merely an article informing you about what Kotlin Multiplatform Mobile is. Nevertheless, I’ve found some great resources that I think you should most definitely check if you want to try it out.

  • First, I would suggest visiting its website.
  • After that I would take a look at the docs.
  • Ray Wanderlich always has a lot of good hands-on tutorials.
  • Last but not least; I would suggest joining the Kotlin slack or get otherwise involved with the community.


Final Thoughts

Now that we’ve explored Kotlin Multiplatform Mobile, we’ve learned that it is an SDK available to share as much code as possible between platforms, that it guarantees a full native user experience, while compiled code is being run straight onto the native platforms. We’ve also explored how Kotlin Multiplatform Mobile works and that we can access platform-dependent APIs with the help of the expected and actual declarations. All in all, when weighing the advantages with the disadvantages, I think it is safe to say Kotlin Multiplatform Mobile is worth your valuable time (especially if you’re an app developer like me, even if you’re a iOS-only developer) and thus you should most definitely try it out on one of your next projects to become just as enthusiastic as I am.