What Should You Know Before Starting to Use Kotlin Multiplatform Mobile?

Photo by Kelly Sikkema on Unsplash

Last year, JetBrains announced the alpha version of Kotlin Multiplatform Mobile (aka KMM). With KMM you can create multiplatform applications using all modern Kotlin APIs. Taking a quick look at it, many developers may think that it’s just another framework to do the same. But KMM has a different concept and tries to solve the problem using a different perspective. In this article, I’ll bring to you some KMM pros and cons.

KMM does not try to solve all existing problems

While other multiplatform frameworks try to help you with everything, from UI to business logic, KMM helps you share just the business logic. This might not look good at first glimpse, but sharing just the business logic and making each platform implement its own UI helps you keep the look and feel of the platform without any problems. This will be a nice choice for projects that you don’t want to share UI, just the "core" business logic.

Image from KMM website

KMM compiles to native code

This point may sound like a trick, but the integration takes into account the first-class language of the platform. When it’s compiling on Android, the result will be Java bytecode, like any other native Android library. For iOS, it will compile the code through LLVM and produce an iOS framework. After importing it, you can freely invoke/instantiate any KMM classes on your project, without any channels or custom integrations. Just import and use.

shared/src/…/Greeting.kt

Here are we are importing the class on the Android app:

androidApp/src/…/greet.kt

And here on the iOS app under Swift code:

iosApp/…/greet.swift

Kotlin APIs

The Kotlin ecosystem has a lot of useful libraries that you can use to improve your code quality and development speed. Using Kotlin Coroutines, you will not need to be handling threads and background tasks using the coroutine syntax. It’s ready for multiplatform; on Android it’s plug and play, and on iOS it uses callbacks to integrate with Swift code. Another example is the Kotlin Serialization library, that is used to parse data from many formats (like json and protobuf).

You can write platform-specific code

When we start thinking about sharing code with multiple platforms, what comes to our minds is that we don’t have access to platform-specific classes. Well, that’s not the case here. In a KMM project, each platform can have its own source set. The common code will be just one of your source sets, and it will be combined with the platform-specific code. On the platform source set, you will also have access to the native SDK classes from your target (Android or iOS SDK) and you can also import third-party libraries (using Gradle for android and cocoa pods for iOS).

// Common source set
expect class Platform() {
    val platform: String
}

// Android source set
actual class Platform actual constructor() {
    actual val platform: String = "Android ${android.os.Build.VERSION.SDK_INT}"
}

// iOS source set
actual class Platform actual constructor() {
    actual val platform: String
        get() {
            val deviceName = UIDevice.currentDevice.systemName()
            val version = UIDevice.currentDevice.systemVersion
            return "$deviceName $version"
        }
}

Monorepos may be a good way to go

Coding your business logic apart from your main app source looks good. You will have the same source on both platforms, but you will have another project/repository to maintain. Analyzing it quickly, you will probably notice that you will have three projects/repositories to maintain (Android, iOS, Shared). Having a monorepo will help you keep everything in one place and avoid having to make updates in many places after something changes.

Last but not least, Multiplatform is more than just Android and iOS

The KMM stands for Kotlin Multiplatform Mobile, but when you start digging a little bit, you will realize that you can also target other platforms. Just think about the time gained while sharing the same code with desktop apps through native, JVM, or web apps using JavaScript. Or even better, have your apps and backend use the same classes for communication, helping your team avoid breaking contracts on the APIs.