Recently, I had a small experience with KMM, which is the Google project for using Kotlin as the native language in both platforms: Android and iOS.

The idea of using one language for multiple platforms is not new, actually, this is how languages like C, C++ and Java got so popular. However, we know that nobody develops for mobile devices only with these languages for different reasons.

When talking about multiplatform mobile development, the only language widely used is javascript, and people who criticises it is due to it is not native, which implies slower speed and having your code exposed to hackers.

Maybe, KMM comes to fix the complexity C++ had and bring the native part which Javascript did not have. Making it the ideal project for developing for iOS and Android (who knows? 🤷🏽‍♂️).

The project sounds very promising, and I’m pretty sure that in 2 years time, there will be many apps using it, but the reality is: today (year 2020) this is the biggest mistake you can have with your project, and I’m going to explain why.

Only Simple Features

Everybody knows how demanding projects are. Mainly mobile projects, as besides its logic behind the scenes, they also require artworks, visual components, animations, using local sensors, push notifications and many other features.

However if you check the KMM documentation (https://kotlinlang.org/docs/mobile/home.html) you will see that all it has are database, HTTP Request and a few more details like project organization and concurrency. Is it enough for you mobile project? 🤔

If you research a bit deeper on the internet, you might find articles explaining how to create view controllers on iOS, but it seems that now, they decided to move to SwiftUI. And here you might ask: Ohh! That’s interesting, how can I write SwiftUI with Kotlin only? The answer is: You can’t!

The old view controllers don’t seem to be working any more (I might be wrong here) and the current documentation doesn’t say too much about that, all it shows are some projects which even so, they had to create the ViewControllers using Swift (see this example: https://github.com/touchlab/KaMPKit/blob/master/ios/KaMPKitiOS/ViewController.swift).

So I decided to follow the tutorial and see how the “Hello, World!” program is when using this plugin, and you can immediately see that you have to create the whole UI in Swift, and all you receive from Kotlin is a string. Does it worth?

Still Beta

Theoretically, when a software achieves the version 1, it is supposed to be on its first stable version, however, it doesn’t seem to be the case of KMM. Although it is on its version 1.4.0, only the Kotlin/JVM is considered stable.

Besides that I tried to move one project created at version 1.3 and it was easier if I created a new project on KMM 1.4, and copy everything from 1.3 to 1.4, rather than migrating it. How many times would you be willing to accept this kind of pain? 😱

The effort of migrating your project

Assuming you have a project with hundreds of thousands of lines of code, what would you need to do for migrating it to KMM?

Firstly, you will need some time for setting up both project to be under the same project with KMM. Assuming you could do it with your project, then you have to ask yourself: what can be shared? If you do not share components, then KMM is pointless.

Considering that Apple GCD and Kotlin Coroutine are completely different, I don’t really know if it worth dealing with that as a starting point. So it leaves us with 2 options: HTTP requests and database.

The HTTP requests seem to be the easiest ones. A library compatible with both is already available. Its name is KThor.

Considering that you shouldn’t have URLSession and Volley calls spread around your code, but just a wrapper over them with a public interface (Interface Segregation Principle), then this part shall be easy to deal with. If that’s not your case, this might be a good occasion to tidy up your code 😁.

However the database is much more complex than that. On Android we use Room, and on iOS we have Core Data, and on KMM we have…. SQLDelight . And what’s SQLDelight? Is is a library for persisting objects based on SQL mapping, like the old iBatis/MyBatis.

How much effort we do we need here? A lot! actually, this would break your whole development.

Happy ideas like migrating entities one by one, will make your development more difficult, prone to issues and spoiling your project quality. Besides that, when will you finish the migration?

So, migrating your existing project will be expensive, prone to issues and will lower your project quality. And what do you get in exchange? Nothing, only more headaches 🤯. You will still need to keep your Android and iOS developers. Don’t you think it is pointless?

The effort of a new project

As it was mentioned before, you don’t save any budget in your project, the only thing you can do is sharing small bits and pieces between both platforms, thus, in theory, the effort is the same as developing any project. So, why not use KMM?

The issue is not going to be found today, but in a few years time, when you will have to migrate other parts of your project to KMM, like, when UI components start being available in KMM you might need to redo the whole UI from scratch again.

Besides that, this project lacks on documentation, and its community is very small. So, it is not clear what kind of issues you will find on the long run. For example, how do Swift UI modifiers, like @ObservedObject, @State or @EnvirnmentObject work with Kotlin components? I really don’t know, and even more, I don’t want to be the one who will discover that.

Lack of libraries

As I already mentioned, I don’t see many libraries done for KMM nowadays. Consider that creating a library compatible with KMM require some effort, like creating factories for components with contexts on Android and without contexts on iOS.

Soon or later many libraries will appear, but nowadays, what you will probably need to do is getting the Android library and the Cocoapod on iOS and create a factory just for ensuring you have something shared between both platforms. Then the question is: What’s the point?

If Apple breaks their own stuff, why wouldn’t they break stuff from someone else?

KMM, like any framework which needs to compile to iOS, depends on Xcode, so you won’t use only Android Studio.

Every year, Apple releases a new version of Xcode and Swift, and also brings new features and deprecates old ones. Some of these new features break out your whole project, and you have to spend a lot time fixing it. I remember when Swift 2 was released which basically made we change most of our porject code, and now, with SwiftUI is even worse.

So, when Apple changes anything, you will have to wait until the KMM make a new version compatible with such changes.

Don’t forget that Apple was able to block applications made with Java and websites made with Flash. Will they accept applications made with Kotlin rather than Swift?

Summary

I’m pretty sure that in a few years time KMM will have a more stable version, and it will be used by many projects, and even in big project, but nowadays it is like the communist manifesto: It sounds great and looks that it is the solution for your problems, but in the end all it brings is economical disaster, chaos and destruction.