Kotlin Multiplatform Mobile for cross-platform development
When it comes to developing a mobile app, the first choice to make is the technology: native or hybrid.
Hybrid development favors cost reduction by avoiding code duplication, but it has many disadvantages. If you are not familiar with these concepts, we recommend you read this article as a starting point. What if it was possible to limit this duplication while avoiding the disadvantages encountered? That's the promise of this technology that was recently released: Kotlin Multiplatform Mobile. Let's take a look at it.
Kotlin Multiplatform Mobile: Who is this newcomer?
Kotlin Multiplatform Mobile (KMM) is a cross-platform development framework created by JetBrains. This company is actually behind Kotlin, a popular programming language for Android and officially supported since 2017. Its goal is to allow developers to share code between iOS and Android.
KMM, by the way, stems from an overall desire by JetBrains to popularize the use of its language on other platforms (JS, Linux, Windows). Called Kotlin Multiplatform (KMP), this technology is based on cross-compilation, allowing to compile Kotlin code into native code on the targeted platform (Kotlin/JVM, Kotlin/JS or Kotlin/Native depending on the platform). KMP allows to get rid of the Java Virtual Machine (JVM), in which the Kotlin code usually runs, and which is not omnipresent.
Thus, if we take the case of KMM, it is a question of being able to execute Kotlin code on Android as well as on iOS. Following the documentation, we end up with a project containing an iOS app, an Android app and a framework written in Kotlin that can be used in both apps.
Is KMM a reliable technology?
At the time this is written, KMM is in beta since October 2022. The denominations alpha & beta are defined by JetBrains according to their own rules; Beta means for them that the technology is soon finished (at least its first version) and stable, that it can be used in production (as it is already the case) and that few changes are expected in the next migrations.
In addition to their good communication and documentation, the fact that KMM development is listed among the Key priorities brings confidence for the integration of the technology in new projects, without fearing for their future.
Heavily impacted by the Russian invasion of Ukraine, JetBrains has shown its seriousness by closing its development offices in Russia and relocating its employees. The KMM beta was delayed by a few months, but the impact stops there.
What's the worst that could happen? Many tools and SDKs have been released since the beginning of smartphones, only to be regularly shelved and shunned by the community, always attracted by innovation. The good thing about KMM is that no matter how the technology develops, you can get out of this cross-platform framework and keep the existing code for the Android app and rewrite, if necessary, a similar code in Swift, a language close in syntax and modernity.
Is everything shared with KMM?
The use of KMM, without being dictated, remains framed by its design and its limits. The shared code generally concerns the business logic. That is to say, the algorithms and processes that manage the functionalities of the app, such as transaction processes, network calls, the database, and all the management rules that can be found within an app.
The interface is coded natively in the platform language to display the data returned by the KMM framework containing the shared code, namely the business logic.
KMM offers a solution for using platform-specific code directly in the shared framework. Via the expect / actual functionality, one can in some cases use the APIs of the platforms to keep the maximum logic within the framework despite the differences in implementation.
What are the advantages of Kotlin Multiplatform Mobile?
The user interface, i.e. the views, remains developed in the language of the respective platform, with all the power of the latest APIs. The look and feel of the app is not impacted in any way by the use of KMM, the rendering is native. Some might argue that this is a flaw compared to other hybrid technologies, because it duplicates the interface code. We think it is a strength; the interface is adapted to each platform and its rendering is unmatched.
The development time is obviously reduced, because the business logic only needs to be written once. The gain is even more important, once the architecture is in place, on the support and the future evolutions.
The use of a framework leads to the declaration of an API to interface the shared code and the UI code. The separation is clear between these two codes and must be as clear as possible to connect two distinct apps in the best way. What seems to be a constraint actually allows to propose a simpler and more focused code, with a layered architecture.
The fact that the described architecture forces developers to separate the business logic and the interface code has another advantage. Knowing that the interface code is difficult to test, we have the guarantee that the business logic is devoid of it and that it can therefore be easily structured by unit tests.
What are the drawbacks of Kotlin Multiplatform Mobile?
Unfortunately, the code on Android runs in a JVM, and the development in Kotlin is based on the abundant use of existing Java libraries. So you have to restrict yourself to those designed for KMM, which are few in number. But you can quickly find what you need to develop, as for example this GitHub directory which provides a non exhaustive list.
It also takes more time to set up a KMM project, especially because of the complexity of the build.gradle.kts files and the integration of the right dependencies. Other than that, there is no real impact on Android development. It's on iOS that we really feel the presence of KMM: 2 development environments (Xcode, Android Studio), 2 languages (Swift, Kotlin) and the constant juggling between them. Compilation time as well as debugging are clearly impacted, especially when dealing with shared code.
So, do we have faith in it?
Designed to save development time without affecting the quality of rendering, KMM seems to keep all its promises. The technology convinces by its ease of use once implemented, and the time saving resulting from the use of shared code. The project is stabilizing, its community is growing, and even if we have to keep a close eye on it, it seems to be well on its way to last. Nevertheless, it is important to be aware that KMM does not adapt to every kind of app, and it is important to measure the impact of its use.