Kotlin Multiplatform Mobile (from now on, KMM), it’s a new framework to develop hybrid mobile apps. Today I want to share with you my experience after 6 months using it in a professional app.

In the current space, we already had React Native, Xamarin or Flutter, where the developer with just one codebase could release a mobile app for iOS, Android and even the web.

This of course seems too good to be true, but as it happens to everything in life, there are trade-offs. Performance can take an impact, usually as the apps grows, access to specific things of each platform is harder compared to native development and there’s also the money department, let me explain.

Paying independent teams to develop an app for each platform is more expensive than paying for a hybrid implementation.

Clients that pay less money usually implies lower salaries, and probably worse backend as because of this money limitations, deteriorating the coding experience and the final product result.

KMM approaches these problems differently.

With this framework, there is a codebase in Kotlin that is shared between iOS and Android. If you want, you can write the entire architecture in KMM of each app up until the UI, which is where usually the biggest hit in performance happens in the other hybrid technologies.

Now let’s see my experience using this framework in a professional environment and what are some of the pros and cons that I’ve found along the way.

Background

I’ve been developing Android native apps for 4 years now, if I count my time as a student. In that time I’ve also played with iOS and I know the basics and how to build a simple but functional app, and occasionally I’ve tried out Flutter and Xamarin.

To be honest, I never liked hybrid frameworks. They forced me to learn a new language just to tried them out.

There’s also the fact that instead of depending on the Android and the iOS platform, you have to add another player to the game that is going to have delays when supporting new features, with bugs included.

For these reasons and the one mentioned above about what kind of projects usually involve hybrid frameworks, I’ve stuck with native, but this has changed thanks to KMM.

How it feels when coming from Android vs iOS

First I’m going to talk about the experience if you are an Android developer, and then if you are native iOS, using some of the feedback that the team gave me.

Android developers have two options when it comes to languages, which are Java and Kotlin.

Nowadays, every new project uses Kotlin, and older ones are a mix of both with newer parts of the apps written in Kotlin, and legacy ones in Java (assuming no refactors were done).

As the KMM module is built using Kotlin, transitioning to this framework is pretty straightforward. You just need to learn how the framework works and maybe some libraries.

This is because the ones, from the Android framework, are not available in the hybrid part of the app, this is, the KMM module. For example, in my case, I had to learn Ktor, as I’ve always used Retrofit previously. Nothing that couldn’t be managed in a few hours.

Being an iOS developer, the story changes. Now you not only need to learn a new language (although Kotlin and Swift are pretty similar), but you need to get comfortable with a whole new set of libraries and a new IDE.

There’s also the pain when you are debugging the iOS side of the app, where you’ll need to have open Android Studio to check the Kotlin code, and to set breakpoints. You can try to do it from Xcode, but the output is not pretty and is not the easiest thing to read.

We also had problems with M1 Macs and had to run for quite a long time Xcode and Android Studio in Rosseta, with a performance hit, but now it’s been fixed.

Pros

Let’s start with what I like the most about KMM, flexibility.

Developers can choose how much code to share, you can go all-in, or just share some bits. For example, you can use KMM up to the ViewModel or just use it for your data layer.

The technology is still new and evolving. There are some projects to share also the UI code using Compose, but this is something that I’ve not tried out, and I don’t want to dive into it.

You don’t need to write two times in different platforms code that does exactly the same, with all the time and money saves this comes with. And if you are someone that develops simultaneously for iOS and Android, you are going to love this.

Performance drops are not going to be affected noticed compared to native development, at least for medium size apps, which is my experience.

Cons

The most important in my opinion is the one we talked about before, the learning curve for the iOS team is going to take some time, and it’s going to cause rejection.

Because of that, the Android team is going to have more responsibilities, specially at the beginning, as they are going to need to support the iOS team and develop the KMM module.

Balancing the amount of work is going to be a new problem for the team.

You now have another Git Submodule to take into consideration and changes are going to affect both platforms, so be extra careful to avoid bugs and write tests if you are not doing it now.

And to finish, well, this technology is new, so you are going to suffer the consequences of being an early adopter.

Final thoughts

Overall, my experience with this technology has been pretty good, and my teammates agree.

Our client and the users are happy with the app, and we could say that they don’t notice anything different, so it’s feel like it is native. You know that when apps are developed with hybrid technologies, you could see that something felt weird when using the app.

I recommend using it for new projects and if you feel brave, start sharing bits of your app in KMM!

Featured image by Jetbrains


If you want to read more content like this without ads and support me, don’t forget to check my profile, or give Medium a chance by becoming a member to access unlimited stories from me and other writers. It’s only $5 a month and if you use this link I get a small commission.

Categorized in: