二月 03, 2022
Kotlin Multiplatform Mobile (KMM) is a framework that allows you to build an application that targets Android and iOS. Unlike other multiplatform frameworks, it does not attempt to make all the code of the application reusable across both platforms.
Instead, the UI layer, in Clean Architecture terms, is the only layer that needs to be developed natively, allowing most of the rest of the architectural layers to be shared.
The shared architecture is provided to each native app as a compiled package. This package is then accessed within the native app code. KMM has the potential to be the foundation for a number of platforms, including Android, JavaScript, Java, Kotlin and Swift iOS codebases.
What skills are required to develop an app using KMM?
Knowledge of the Kotlin programming language is required to develop the reusable libraries of KMM applications. To achieve a great level of reusability, good grasps of Clean Architecture or similar, software design patterns, separation of concerns, modularization and SOLID principles are also required.
Engineers with knowledge of native Android and iOS development are also required in order to consume the KMM shared libraries and develop the UI and any other areas that require native APIs to be implemented.
Teams will need to be made up of developers familiar with the native target platform for the app and, of course, others who are comfortable with Kotlin for the shared layer development.
For example, an Android and iOS app would need a team of iOS (Swift) developers and Android (Kotlin). The balance in the development team may need to lean a little more toward Kotlin in order to support the shared layer development as well as the Android UI layer.
What are the advantages of developing an app with KMM?
A great portion of the code can be reused across platforms. This can result in a single codebase that is easier to maintain and scale. Similar to native code, due to only targeting a specific platform, it’s void of any logic required for achieving different behaviors for different platforms, resulting in an easier to scale and maintain codebase. Also, as all the UI code and native API integrations are direct to the OS, a great level of performance and, thus, user experience can be achieved.
Truly native UI, UX and performance can be obtained while at the same time lifting business logic into the shared codebase. This enables you to avoid duplication of logic and work, ensuring better consistency across platforms and better tested and maintainable code.
Developing your app with KMM can greatly speed up development on multiple platforms or possibly give the flexibility to allow other platforms to be supported in the future.
What are the disadvantages of developing an app with KMM?
KMM is still in alpha at the time of writing and, thus, may contain many bugs, have missing features and introduce breaking changes to your codebase further down the line. It also requires native Android and iOS developers to write part of the code for the app in question.
Although it is in good shape for an alpha release, there aren’t the same levels of ready-made, well-tested libraries or packages as there are for more mature methodologies. For example, there is currently no official firebase support, which means you would either have to find some workarounds or spin up your own. iOS developers who are not familiar with Kotlin would need some assistance from the Android developers on the team to work on the shared layer.
The compilation of the package after small changes to the shared layer can lead to slow build times for iOS developers. Additionally, the preferred IDE for KMM is AndroidStudio, whereas iOS native development is most likely to be done using Xcode, which could impact developer experience and speed using unfamiliar tools.
That said, support and more efficient ways of working are likely to emerge as more adoption occurs and developers get more experience with the technology.
In which scenarios would you recommend using KMM?
When targeting both Android and iOS and would like to reach native performance, require access to native APIs and have a sizable code base that could benefit from sharing a large part of it across platforms. Also at the time of writing, as KMM is in alpha, you would need to be OK with the potential issues that were previously mentioned.
In which scenarios would you advise against KMM?
KMM shouldn’t be selected when the alpha-related issues above might come into play. Also, if developers are not well-versed in Kotlin or don’t have a good understanding of software architecture and modularization, then KMM might not be the best solution.
When the product also needs to target more than Android and iOS and there is a possibility of sharing code using another technology, it might not be possible to use KMM to full advantage.
Can you talk about a project on which you’ve used KMM and why it was chosen?
We chose KMM for an internal hackathon because we wanted to develop for both iOS and Android to put KMM to the test.
Building a meal-sharing app, we used the shared layer to build API calls to update the server with meals, as well as calculate distances between meals. We found it to be quite easy to make changes to the shared codebase, which helped us focus on the UI layer rather than having both Android and iOS developers writing the same API calls and business logic map distance calculations.
