When Baptiste and Marek created BAM in 2014, they immediately understood the potential of development. Cross-platform. Precursor, then leader in technology React Native, BAM is developing equally projects in native code for ios and android but also in Flutter.
Although the technologies Cross-platform current ones make it possible to save a certain amount of time during the development of a project, they are not without compromise: scalability limited to what the framework offers, native development is still necessary for certain functionalities...
KMM would it be the framework to remedy it?
Even though the benefits of frameworks Cross-platform have attracted a good number of developers, today the vast majority of applications remain developed in native code.
In addition, most mobile developers are platform specialists (ios or android) and do not necessarily want to migrate to a framework Cross-platform which would involve a change in language or IDE.
This is one of the fundamental differences with the other solutions called Cross-platform. The structure of a KMM project is very similar to that of a platform-specific project. So, You can consume a library written in KMM like any other module or third party library. In addition, A developer ios can use a module written in Kotlin Multiplatform without even knowing that it was written in Kotlin, thanks to the extensive integration of KMM with Swift/Objective-C.
On an existing native project that can include dozens of screens, you may want to make a very gradual migration, as the application is maintained. KMM allows Easily share code of any size : from a few data structures to the complete logic of the application, including the network layer and persistence.
For comparison, migrating to a framework Cross-platform classical requires the migration of complete functionalities (UI included), and requires the duplication and synchronization of existing data structures.
This is one of the big weaknesses of frameworks React Native and Flutter : you must constantly take into account new versions ofios And ofAndroid. We are therefore at the mercy of a delay, a bug or even an absence of integration of a new OS feature.
We find the same problem with all third-party libraries, which do not necessarily have Binding Cross-platform official or unofficial of good quality, and that you will therefore have to develop yourself.
Note that we potentially have the same problem for libraries in KMM: we cannot share a library even written in Kotlin if it was not intended to work directly with KMM.
However, there is a real fluidity between KMM code and native code (no bridge, KMM objects are interoperable with native objects...) which in fact the solution of choice for applications that have a logic implementation to share, but which in any case have specific features per platform to share (for example: strict compliance with the guidelines and Design Systems of each OS, extensive multimedia integration...)
Cross-platform solutions make it possible to arrive at a unified code base and in the same language in most cases.
However, when the project becomes more complex it is not uncommon to have to know the native environment (development of a bridge, change of project configuration...).
These are then new tools and new languages that are not necessarily mastered by the developer. We must finally have a triple knowledge (cross-platform framework + Android + iOS) in order to be able to intervene on the entire project.
On a project developed natively, we already have both iOS and Android skills. Several choices are then possible to add KMM: have the common brick developed by the Android team, create a dedicated team, train iOS developers to be able to maintain it...
Anyway, these are only 2 languages to master, and what's more, these languages are quite close. However, it should be noted that even if it is the same language, developing in Kotlin for Android or for Kotlin Multiplatform can be quite different and requires a significant increase in skills.
KMM is still a young technology, so using it is not without a price:
These few hard points are clearly not prohibitive, but nevertheless reserve the use of Kotlin Multiplatform for teams mature enough to understand and work around them.
Kotlin has been able to maintain one of the great strengths of java : it is perfect for the business world. One Public roadmap, but above all a controlled evolution reassure technical managers. This same recipe applied to KMM makes it a solid and sustainable solution for years to come.
Native developers are generally very happy with their environment and language: Google and Apple invest heavily in providing the most seamless and integrated development experience possible.
Very often, mobile developers do not consider switching to a framework. Cross-platform that may seem a cut below in terms of Developer Experience.
On the other hand, Kotlin Multiplatform seems to be getting some traction from native developers. Without this being the main criterion for the technological choice of your product, it could well be an element that makes it possible to keep or attract the best developers...
Kotlin Multiplatform, It is also the possibility of sharing code with a web app or even a server JVM or Node.js. More and more libraries Kotlin are written or ported to KMP and allow you to develop the data and logic layers of the application by completely abstracting from the platform.
On the UI side, Jetbrains already offers versions of Compose (the new UI framework fromandroid) for the Desktop (and even for the web under certain conditions). It is very likely that a version ios is coming very soon since Technically nothing stands in the way.
We will then have a complete solution allowing to share all the logic of the application and all or part of the UI!