Kotlin Multiplatform Mobile — Overview and kickstart and personal experience

5 min readJul 26, 2021

Maintaining two different code bases for a single app has always been a challenging task. It certainly costs more, takes longer development time. Making changes in the app gives twice the required pain. Over time, emerging technologies have made cross-platform development more adaptable, powerful, and flexible than before. Still, there are few challenges faced by cross-platform technologies and performance issue has always been one key factor which inclines us towards the native applications. Though newer hybrid mobile solutions like React native and flutter provides a great performance improvement, there will always remain an envelope which through which the hybrid code will communicate to the native UI. Kotlin multiplatform mobile comes to light to remove this envelope.

In Kotlin multiplatform mobile, the developer can code the entire project in Kotlin ( Network layer, data layer, and domain layer) as an Android application, and the presentation layer(UI) is written separately for both Android and IOS. This way, both Android and IOS devices will have their native UI and the business logic can be shared. This was we can overcome the shortcoming of handling an additional layer which was the case with hybrid frameworks. This way we can provide the complete native user experience without the effort of writing and maintaining two different projects.

On other hand, we still have some dependency on the IOS developers for writing UI. Handling Gradle is another challenge that is faced in KMM. Most Android developers just have a basic understanding of the Gradle, and in some situations, I faced several challenges with the Gradle and had to invest some time in it. At this stage, very little documentation is present on the internet so if a developer faces an obstacle, it is very unlikely for him to find its solution on the internet. This is because the technology is comparatively new and the KMM community is still in the budding stage. Though I believe it is not fair to complain about it as every technology was once new, finding solutions to obstacles is somewhat challenging. There is still no recommended architecture for project development in KMM. I feel clean architecture can be a good option.

In the KMM project, there is a common directory that contains various classes and flies that can be shared between Android and IOS. There are two separate directories for Android and IOS as well where we write the UI and native code which can not be shared between Android and IOS. We also have separate gradles for each for common and Android. In the App-level build.gradle, there are three sections for writing dependencies. The dependencies which are common to both Android and IOS and support KMM are added in the common section of the file(eg. Ktor) whereas those dependencies which are specific to android are added in the androids section. Thus, handling Gradle is a bit different in KMM the in traditional Android projects. For a better KMM development experience, it is highly recommended to install KMM plugin in your Android Studio. You can check out how to install the KMM plugin and set up the environment for KMM development on https://kotlinlang.org/docs/mobile/setup.html

We can share the business logic. We write two different presentation layers. What about ViewModels? Can we share the View Model? Sharing the view model will drastically reduce our code and dependency on IOS developers. The only responsibility they now have is to create the views which can interact with the shared view models. It is a bit challenging to share view models, but the MOKO libraries come to our rescue. Moko is developed by Icerock development. Moko provides us a lot of libraries that can be used to perform various tasks in project development. These libraries have gained popularity in a very short span of time. I would recommend you to go to their website(https://moko.icerock.dev/) once and check out what all libraries they offer.

Integrating these libraries can also be a little troublesome as I have already pointed out the challenges we face with the Gradle. Moko has a solution for this problem. They have a template project which can be used as our base project to start with. They have already added various dependencies in that project, and you can add more dependencies by following the same procedure. They have also set up a base architecture (MVVM), which can be modified based on the requirement. The template also has the provision for dependency injection in the classes which makes our life easier. Icerock development also provides detailed documentation explaining this feature, architecture, and guidelines on how to set up and run the project. For further reading about the Moko template, you can go to their official repository. https://github.com/icerockdev/moko-template

The Moko-MVVM library provides a shared ViewModel object. However, it is not available for SwiftUI or Jetpack Compose. This means, in iOS, a ViewController needs to be used. The same goes for Android — Instead of Compose, a Data binding set in the Activity’s layout file needs to be used.

KMM has a lot of potentials. Currently stability level for KMM is alpha, but it is already attracting a lot of attention and I personally know few organizations that are already working on it. As there is not much documentation and solution available on the internet, working on KMM is a bit challenging, but was once the case with every new technology. An experienced Kotlin developer (with experience in Android development) will be very comfortable in exploring this new technology. Although the scope of KMM is limited to Mobile development, Kotlin is developing its multiplatform ecosystem tremendously. I believe, very soon Kotlin will be used in various fields of development.

Kotlin Multiplatform Mobile — Overview and kickstart and personal experience

Written by Anant Raman