Are you interested in sharing Kotlin code across different platforms? Our subject today is Kotlin Multiplatform Mobile (also known as KMM). KMM is an SDK for cross-platform development that combines the best of cross-platform and native approaches.
To break this topic down, I invited Mateusz Teteruk.
Mateusz Teteruk
I have been working professionally with Android for over 5 years.
I have worked on projects created from scratch and on projects that have existed for several years. The applications I have developed so far, have had both a few hundred thousand and a few hundred daily active users.
I put a lot of emphasis on using the available tools as efficiently as possible in my daily work.
I am a fan of idiomatic Kotlin, and as a result, of understandable and elegant code.
My eyes can see every UI/UX imperfection.
Creator of the NowoczesnyAndroid.pl newsletter and co-creator of the KlubMobile.pl community.
Q: Mateusz, thanks for being here! Let’s start with a general idea – what is KMM and its purpose?
A: Hello Szymon, thanks for the invitation! KMM stands for Kotlin Multiplatform Mobile.
The general idea behind creating KMM SDK is to combine the benefits of creating cross-platform and native apps. You can have one codebase for both, Android and iOS applications. You share between platforms only selected part of the code.
The most popular option is to share domain business logic and data layer (networking, data storage). User Interfaces are written natively.
You can write data and domain layers in pure Kotlin! And you can use that code from Swift.
At the time of this interview, KMM is in the Beta version – it’s almost stable. KMM is made by JetBrains so the company which created Kotlin and the best IDEs!
Q: Let’s compare KMM with other cross-platform solutions such as Flutter or React Native. We already know that KMM uses a native UI for each platform. This seems like a unique feature.
On the one hand, the framework does not limit us when it comes to building the UI – with the native UI, we do not have to make any compromises. On the other hand, we have to maintain both iOS and Android layouts, instead of a single layout.
What is your opinion on that? Also, do you see any other differences?
A: Yeah, that’s true. I will explain it in more detail in a moment. Please keep in mind that I don’t have a lot of experience creating applications with Flutter or React Native.
Currently, I think that the separation of UI is a good thing.
Why? You can integrate KMM into existing application step by step. You don’t have to worry about UI and you can focus on migrating only a small part of the project. It’s really helpful because new technology means new problems you have to tackle. Don’t rush into migrating everything to KMM at once!
Start from sharing a small part of the data layer, then the whole data layer, then the domain layer. And if that’s working for you, for your team, very well – let’s think about sharing something from the presentation.
It’s possible to somehow share ViewModels between Android and iOS. Personally, I haven’t tried it yet. John O’Reilly creates really good content about KMM, take a look if you’re interested.
Last thing – UI. That aspect might be confusing. We have to keep in mind that Android and iOS UI/UX guidelines are not always aligned. There are some nuances and because of that, UI components might differ. But, there’s one catch. Jetpack Compose.
Jetpack Compose is a huge deal-breaker. It’s written in Kotlin and the runtime of this library is platform-independent. If you know how to use it – you can do more things.
We have Compose Multiplatform from JetBrains based on Jetpack Compose from Google – Desktop, Web, and even iOS!
We have also something else – Redwood from CashApp (incl. Jake Wharton). Redwood is fascinating because it allows writing UI on multiple platforms (Android, Web, iOS). It’s backed by Compose compiler BUT you can use it with any UI – on Android either Views (XML) or Compose, on iOS either SwiftUI or Compose for iOS, etc.
As you can see, sharing User Interfaces is a really interesting topic. A lot is going on in this area. But to sum up my really long comment on this. Personally, at this very moment, I would write native UI.
Q: If I understand correctly, we cannot use libraries that are specific to Android in shared Kotlin code. One example I can think of is Retrofit, which is probably the most commonly used library by Android developers for API connection. What are the guidelines in these situations? Can you tell us about other cases?
A: Yes, that’s true. You cannot use such a library unless this library supports Kotlin Multiplatform. Android-specific library will work on Android but it won’t work on iOS. A perfect example is Ktor. You can use it only on Android but as it supports a multiplatform environment, you can use it in shared Kotlin code.
In general, you should choose such libraries that provide everything you need.
Instead of Retrofit for networking, you can use Ktor.
Instead of Dagger/Hilt for DI, you can use Koin.
Instead of Room for database, you can use SQLDelight.
Of course, you can write your own custom solution using expect/actual mechanism but you have to answer yourself one question – is it worth it?
Q: You mentioned that KMM is currently in a Beta state. Do you see any other issues or dangers we need to consider before using KMM?
A: Yeah, it’s in Beta, and for now, I don’t see any potential issues or dangers. Moreover, I highly recommend starting to use KMM as soon as possible.
Q: Cool! Can you share some resources for everyone who wants to dive deep into KMM? Did you find any interesting repositories with examples?
A: Yeah, sure. You can start with:
