Kotlin Multiplatform for Cross-Platform Development: Yes or No

Learn why big companies like Netflix, McDonald’s, and 9gag already use Kotlin Multiplatform.

Aleksa Simic
Mobile Tech Lead
Tech Solutions
Posted on
July 5, 2024
Table of Content
Kotlin Multiplatform for Cross-Platform Development: Yes or No

Since the beginning of my career, I knew that I wanted to pursue iOS development, but I’ve also been curious about how everything is done on Android. However, I have always wanted to master iOS development before learning more about any other technology. After 7 years of working in the iOS ecosystem with different clients on more than 20 different iOS applications, I had a chance to dive into Android development just a little bit, thanks to the new piece of technology called Kotlin Multiplatform, or shortly KMP.

But before working with Kotlin Multiplatform technology, I had a chance to try out other cross-platform tools like Flutter and React Native. That is how I gained an insight into cross-platform app development and how they compare to native development.

My experience with Flutter and React native programming

Flutter and React native
Flutter and React native

As for using Flutter for iOS and Android, I went through the whole course by  Angela Yu, and would recommend it to anyone starting to learn from zero. During the course, I made a bunch of smaller Flutter apps and figured out how the UI building itself is similar to SwiftUI and Compose. Because of that, the UI part was easy for me to grasp, but I had a sense it would take me too much time to learn Dart. Dart is the language behind Flutter, making it the primary choice for developing Flutter-based mobile, web, and desktop applications. For some reason, I had a feeling I should wait for some better options and that is where my Flutter journey stopped.

As for React Native, my only experience was during the transition of a couple of React Native applications to Kotlin code. First, it was a difficult process for me to get the project running using all of the scripts and the expo. Second, the code for those projects was written rather poorly since they were using JavaScript and not TypeScript. Overall, it didn’t feel right to me to use it for Android and iOS apps.

Then at some point, I started reading about Kotlin Multiplatform for mobile development and its main benefits. Compared to Flutter, with KMP:

  1. You can share only the business logic and only the pieces you choose
  2. You build UI natively for iOS and Android, so you get the native performances on mobile devices

That was enough for me to become super interested in KMP! Fast forward, 6 months after I first heard of it, my team and I currently manage Kotlin multiplatform project for 3 different clients, making a good basis for a trusted cross-platform mobile app development company. Kotlin can work on different operating systems like iOS, Android, macOS, Windows, Linux, watchOS, and others. Major Kotlin Multiplatform use case is sharing code between multiple platforms.

Big companies are adopting Kotlin Multiplatform

  1. McDonald’s
  2. Netflix
  3. 9gag

That’s the list of companies that have already adopted Kotlin Multiplatform for Android and iOS applications.

Big companies that adopted Kotlin Multiplatform
Big companies that adopted Kotlin Multiplatform

You heard that right! I was pretty curious when I found out about this, and I wanted to see how our way of doing Kotlin Multiplatform compares to these big companies’ way of doing it.

McDonald’s

At McDonald’s, the main motivation was reducing the total amount of the code they needed to maintain. Also, one big advantage of KMP is having the business logic isolated and unit-tested in one place. They are taking the integration slowly, and migrating piece by piece of shared functionality to KMP.

Netflix

Netflix, on the other hand, has been using it in their app built from scratch, Prodicle, which they are making to innovate in the area of physical production of TV shows and movies. They emphasize how the communication with the database and support for the offline mode is in one place.

9gag

When it comes to 9gag, the interesting thing is they migrated the whole app to React Native in 2016, but as it grew, they had performance issues so they switched back to native. Then in 2020, when Flutter was gaining a lot of attraction, they tried using it, but eventually stepped away because of a lack of support for ads and Firebase, at least at the time. Then, they decided to give Kotlin Multiplatform a shot and suggested starting with sharing some constants, then moving to writing some common utils in KMP, and just after that writing the whole business logic in the shared module. They are using it for network calls, offline mode, sharing resources with moko resources, and encryption decryption.

A couple of weeks ago, Google announced they are using Kotlin Multiplatform for their Google Docs iOS and Android app. It’s a big proof they mean serious with KMP and this cross-platform framework is here to stay.

Deciding what pieces of logic to share in the KMP shared module

As I stated previously, when using Kotlin Multiplatform, you get to decide which pieces of the business logic you want to place in the shared module and share the same code between your iOS and Android app.

There are two approaches you can go with in terms of the shared code:

  1. Data layer - Share-only models, repositories, networking, etc.
  2. Data layer and view models - Share everything as above, just with the addition of sharing view models between iOS and Android codebase

Our team decided to go with the second approach because we wanted to take all KMP advantages. We went through all of the available articles about the sharing view model and got started. It was way more difficult than we expected.

We spent a couple of days figuring out how to make it work and here are the challenges we faced:

  • Compatibility - you need to figure out what Kotlin and Java versions work with the latest Swift version
  • Third-party library dependency - if you want to share your view models, KMP strongly relies on the mokko-mvvm library which has compatibility issues with Swift 5.9, so you need to figure out a way to make it work. In the end, we made it work by downloading some files from the library and adding them manually to our iOS project
  • Lack of good documentation - when we came to some issues and tried to find a solution online, we were constantly getting the same three articles all over again

Thanks to our experienced developers and quick teamwork, we managed to implement KMP in our application in a very short period. This is the complete tech stack we are using across all three of our Kotlin Multiplatform projects right now:

Want to launch your own app or need a team extension?

Kotlin Multiplatform for shared module

Things we shared between the apps:

  1. Models
  2. ViewModels (business logic)
  3. All API and communication with the database logic
  4. Resources (images and strings)
  5. Compose for building UI in Android
  6. SwiftUI for building UI in iOS
  7. Firebase Firestore as a database

Over time, as we saw we could successfully ship applications using KMP, we got more comfortable trying out different approaches to sharing our view models between the apps:

  • mokko-mvvm (https://github.com/icerockdev/moko-mvvm) - we had a difficult time making it work properly with SwiftUI. Eventually, we ended up creating the new view models on the iOS side which had the reference to the shared view model
  • kmm-viewmodel (https://github.com/rickclephas/KMM-ViewModel) - I immediately saw it works much better with SwiftUI than mokko-mvvm, and we decided to give it a shot in our second KMP project. Ended up working well for us, without the need for local view model wrappers
  • Android native ViewModel - so as Google introduced the support for the Android ViewModels in the KMP, all you need now is to conform the one you want to share to ViewModel, and you will be able to access it in your iOS codebase. No third-party library is needed anymore. How good is that? We are still at the initial stage of adopting this approach and I’ll let you know how it goes.

We will keep exploring and pushing boundaries side by side with KMP!

Sharing business logic makes development time quicker
Sharing business logic makes development time quicker

Conclusion

If you want to start quickly and create applications as soon as possible, go with the first approach from the above and share only the data layer.

But if your goal is to share as much code as you can in the long run, I suggest you go with a second approach as we did. More work in the beginning, but will bring more benefits later on in the product development lifecycle. These are the main benefits we had when working with KMP:

  1. Ability to deliver more complex projects much faster than previously when we relied only on native mobile platforms (iOS and Android)
  2. Consistency between Android and iOS platforms because we are sharing everything other than UI, including resources and view models
  3. Keeping the performance high on both mobile platforms because the UI is written natively

Kotlin Multiplatform is just heating up, and I am happy it is now included in our cross-platform app development services. All you need is an Android developer that knows how to migrate existing projects and use the same code from existing native apps.

Thank you!
Oops! Something went wrong while submitting the form.

Thank you!
Oops! Something went wrong while submitting the form.

Let's work together!
* Full name
* Email address
Tell us about your product
(optional)
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.