KMP vs CMP

Motivation

We first started to get into Kotlin Multiplatform when we started noticing a bunch of our startup clients started focusing on reducing development cost and increasing the development speed.We figured out there are two ways we could go about it:

1. Deliver apps using a fully cross platform framework (ex. Flutter or React Native)
2. Try out the Kotlin Multiplatform as the semi-crossplatform solution

Since we have a really strong iOS and Android native team in-house, our decision to go with the second approach came quite naturally.

We are actively maintaining two Kotlin Multiplatform apps and one Compose Multiplatform app

Experiences

We are currently actively maintaining two KMP applications and one CMP application for our clients.

When it comes to KMP, our experience was a roller coaster, but in a good way. At the moment we decided we want to give it a try, we had to decide whether we want to share only the networking layer or the entire business logic including the view models.

We decided to go with the approach of sharing the whole view models, and even took a step further and also decided to share assets and strings across the iOS and Android codebase.

And it required a lot of heavy lifting in the beginning. It was mostly due to Kotlin-Swift interoperability with the combination with SwiftUI we are using for the UI part of our KMP apps. The thing is that currently, Kotlin code gets compiled to Objective-c wrappers, so even with a couple of different libraries we use to observe the changes from the shared view models in our SwiftUI views, we had to adjust the libraries and to create our own wrappers, to do it the right way.

After some time, Google exposed Android ViewModel to KMP, so we were able to share view models the right way very easily, and it integrated with SwiftUI pretty well.

We had to tackle all of this things while working on delivering new features in the app, so it was a pretty interesting experience through which we learned a lot.

When it comes to CMP, we decided to go with it, at the moment we received the information from one client which had their app in KMP wants to redesign the whole app.

At that moment, we were like okay that would now be two developer job if we want to go with KMP, because the UI has been written natively on iOS and Android, we are already pretty confident with sharing things across iOS and Android, so why not try out CMP and share the UI as well?

When we started preparing a technical plan for CMP adoption, one of the main challenges we faced is navigation. We wanted the app to look and feel as much as native on the iOS side so we wanted the navigation transitions to look like native, and to have the swipe back functionality. After trying out a lot of different things to achieve this, including Compose navigation, Voyager library, and a couple of other approaches with no luck, the approach we ended up using was the following:

1. Keep the navigation native on iOS and Android
2. On the iOS side, use wrappers on Compose screens and display them in navigation

And we couldn’t be more happy with how it went! Using Compose wrappers in iOS with CMP is super easy, and the functionality of the screen gets kept out of the box. We managed to release the fully revamped app in the CMP after only 1.5 months.

‍Pros and cons

Based on our KMP and CMP experience shared in the paragraph above, I want to share with you some of the pros and cons both KMP and CMP have so you can make the decision what works for you and your project.

Kotlin Multiplatform

Pros:

• More flexible, because of the iOS and Android are written natively including navigation
• Much faster than native because whole business logic including view models can be shared
• Platform native libraries work without any issues

Cons:

• Sharing strings and assets requires additional work
• Slower development time because the UI is not being shared

Compose Multiplatform

Pros:

• Much faster than KMP because of the shared UI across iOS and Android
• You can share even complex functionalities like QR code scanning, social logins etc. by leveraging Compose expect and actual methods
• You can easily keep the native navigation and only use Compose wrappers on the Android side

Cons:

• Compose native navigation still doesn’t support iOS swipe back
• It can be hard to get started with using actual and expect to do platform specific things because it requires both iOS and Android knowledge

Conclusion

Both KMP and CMP have their usage in the mobile development ecosystem. It’s just about figuring out the business needs of your mobile app, and then making the right decision which of these two you will go with.

‍