Kotlin Multiplatform Mobile, KMM from now on, is a very interesting technology with very well defined use cases, as we will see throughout this article, which allows us to create multiplatform projects in which we can have a library written in the Kotlin language that will be compiled to native binaries that will be executed in each platform with native performance.
In this article, I am going to make a brief explanation about KMM in case you don't know it yet, then we are going to see how it compares with Flutter, what advantages it has, what disadvantages it has, and what kind of audience it's intended for.
What is KMM?
KMM is the proposal made by JetBrains, the creator of the popular IntelliJ code editor, to reuse code between applications that run on different platforms to save time and costs.
It is not a framework as such, but rather a set of technologies brought together in an SDK that will allow us to share several layers of our application, for example the business logic layer, the data layer, and even the layer of state management; so you only have to write them once. A fundamental difference with other solutions like Flutter or React Native is that KMM is designed to be used as a library, so the user interface part will have to be created natively.
Source: Official KMM website
For example, in a mobile application we could have the business logic and the data layer in the KMM module, while the visual part could be built with Jetpack Compose on Android and SwiftUI on iOS. This can be seen as an advantage or a disadvantage. On one hand, if you are used to work with Flutter or React Native, it may seem that creating an application with KMM is going to require more work, since unlike these two KMM does not provide you with a shared visual layer. However there are some advantages that this approach has:
- Since you are going to use native visual elements, you don't have to worry at all that the final appearance of your application will give the user the feeling that it is not something native. The user will not be aware at all that your app is sharing code since it will have the exact look and feel than a native app.
- You are going to work directly with APIs provided by the platform, you will always be able to use the latest components directly, without having to wait for anyone to adapt it. For example in Flutter, although there are several Cupertino widgets that you can use, there are some native elements that are not ported to Flutter so you have to look for substitutes.
Another fundamental aspect to highlight about KMM is the choice of Kotlin as its programming language. Kotlin is a modern language and is loved by many developers. I personally think it's a wonderful language, concise and elegant. A full-fledged evolution of Java.
One of the most important technologies of KMM is Kotlin/Native, which allows the Kotlin code in the shared module to be compiled directly into executable binaries, so that a virtual machine will not be required for said binaries to be executed. This is particularly useful on iOS, given the complexity of running code using a virtual machine.
The final result is an application that we can consider as 100% native, since it will contain a part of the UI created with the SDK provided by the platform and a shared module compiled to a native binary.
KMM and Flutter
But how does KMM compare to Flutter? What advantages does it bring? and more importantly, what disadvantages does it have? Well, let's go part by part, let's see first some fundamental differences between KMM and Flutter:
- Flutter is a cross-platform framework, whose goal is to abstract as much as possible from the native platform; while KMM is a cross-platform SDK that aims to work together with the native platform tools and SDKs
- Flutter's programming language is Dart, while KMM's is Kotlin + the platform language (Swift on iOS, C++ on desktop, etc.)
- Flutter provides a UI toolkit with many widgets to create interfaces that may or may not be the same between different platforms. KMM is not intended to replace the creation of native UIs, so the UI must be created with native SDKs for each platform.
- Flutter creates executables that perform very well, however, each app needs to embed the Flutter engine to work correctly, KMM compiles libraries that are 100% native to the platform, it is not necessary to embed any engine or similar
- I think that we can already consider Flutter as a more or less mature framework, with a rich community behind it, an ecosystem of packages and plugins, etc. KMM is still in Beta phase, and although it could be considered as a candidate for a potential production app, there is still time for its components to stabilize and reach the stable phase.
Finally, it remains to ask ourselves, who is KMM targeted at? Should I use Flutter or KMM for my next project?
Should I use KMM or Flutter?
With KMM we can share entire layers of code, for example, the entire use case layer with its logic can be in KMM, the entire data part with its respective repositories and data sources can also be in KMM. There are even some early-stage libraries that help us to share ViewModels to manage the state of the UI.
Source: Official KMM website
So is KMM a replacement for Flutter? Or can KMM kill Flutter in the near future? In my opinion: no, I think Flutter and KMM have different use cases.
In my opinion Flutter is more aimed at individual developers or small businesses, or for the creation of proofs of concept. Its focus is on abstracting as much as possible from the native platform, even to the point of providing us with a UI toolkit to also create the UI. This speeds up development and reduces costs, making it the ideal candidate for small teams or indie developers like me.
On the other hand, KMM does not seek to replace either the look and feel or the optimizations that native applications have. It seeks to be a complement to existing applications. I think its focus is more on reducing costs and time to a certain extent in more corporate environments, where there are already Android and iOS teams.
However, KMM still has a long way to go to reach a stable state to be put into large-scale production applications, so we are going to see how it evolves over time.
Thank you very much for reading so far, I hope it has been useful, see you in the next article!