As a mobility expert, I really enjoy analysing the market from a technical and strategic point of view for my job performance. That is why, after analysing this technology, I have decided to make a post that collects my research in case anyone else might find it useful.
Compose Multiplatform
Many people new to Flutter application development wonder how Flutter differs from the Kotlin Multiplatform. Well, in this post I intend to clarify what this technology is, how it works and finally, how it differs from Flutter.
Kotlin Multiplatform
Kotlin Multiplatform is a SDK developed by JetBrains that allows you to create applications for various platforms and efficiently reuse code across them while retaining the benefits of native programming. Your multiplatform applications will work on different operating systems, such as iOS, Android, macOS, Windows, Linux, and others.
Kotlin Multiplatform Mobile (KMM)
From Kotlin Multiplatform, Kotlin Multiplatform Mobile (KMM) is born. By using KMM, developers can create cross-platform mobile apps and share crucial elements like business logic, data, and connectivity implementation between Android and iOS. Analogous to flutter doctor, the Kotlin team offers us kdoctor, a tool to check if we have the environment correctly installed.
In fact, I liked to see the option to link it in iOS as a Build Phase or as an external dependency in CocoaPods. I gather that like Flutter, Swift Package Manager (SPM) is out of the question.
Giving a project name we will have the project created. If we take a look at the folder structure we can clearly see a Kotlin project with three modules.
Each Kotlin Multiplatform project includes three modules:
- shared is a Kotlin module that contains the logic common for both Android and iOS applications – the code you share between platforms. It uses Gradle as the build system to help automate your build process.
- androidApp is a Kotlin module that builds into an Android application. It uses Gradle as the build system. The androidApp module depends on and uses the shared module as a regular Android library.
- iosApp is an Xcode project that builds into an iOS application. It depends on and uses the shared module as an iOS framework. The shared module can be used as a regular framework or as a CocoaPods dependency, based on what you've chosen in the previous step in iOS framework distribution. In this tutorial, it's a regular framework dependency.
The shared module consists of three source sets: androidMain, commonMain, and iosMain. Source set is a Gradle concept for a number of files logically grouped together where each group has its own dependencies. In Kotlin Multiplatform, different source sets in a shared module can target different platforms.
The common source set uses common Kotlin code, and platform source sets use Kotlin code specific to each target. Kotlin/JVM is used for androidMain and Kotlin/Native for iosMain:
This means when the shared module is built into an Android library, common Kotlin code is treated as Kotlin/JVM. When it is built into an iOS framework, common Kotlin is treated as Kotlin/Native:
The most amazing part was to see that the project that creates the iosApp module was written in SwiftUI.
If we stop for a moment to analyse, we have a shared module with the logic in common, but there are really two native projects, each with its own UI. On the other hand, an interesting fact is that JetBrains has just announced on (1 November 2023) that KMM is considered stable and ready for production.
Compose Multiplatform
Compose Multiplatform was born from the need to be able to share not only the application logic, as KMM did until now. But to be able to share also the UI of the application. This techology has been created by JetBrains, the same team as Kotlin Multiplatform.
The first thing to note is that this technology is still in Alpha version and we can see that some features are not yet available.
After a while of downloading dependencies, we can see the new project structure. If you notice, it has a structure based on KMM.
If you notice, it has a structure based on KMM except that now it no longer has 3 modules. The project contains two modules:
- composeApp is a Kotlin module that contains the logic common for Android, desktop, and iOS applications – the code you share between platforms. It uses Gradle as the build system that helps you automate your build process.
- iosApp is an Xcode project that builds into an iOS application. It depends on and uses the shared module as an iOS framework.
The single difference with KMM is this new composeApp module consists of four source sets: androidMain, commonMain, desktopMain, and iosMain. (desktopMain is the new one, the other three sets were inherited from KMM). Source set is the as KMM happened, it's a Gradle concept for a number of files logically grouped together where each group has its own dependencies. In Kotlin Multiplatform, different source sets can target different platforms.
Compilation standards between Kotlin/Native and Kotlin/JVM are maintained between Compose Multiplatform and KMM.
A curious fact about compilation times is that I was pleasantly surprised to see the project compiled for iOS in 18 seconds.
The result of the compilation of the example project is as follows.
Conclusions
The technology looks interesting, especially for Android developers. In conclusion, KMM only shares Kotlin logic between native projects via Kotlin/JVM and Kotlin/Native. To share the UI it uses Compose Multiplatform which despite being in Alpha version has pros and cons.
Kotlin/Native is the one that interests me the most as it is used for iOS and Apple platforms, as these are the Achilles heel for most cross-platform technologies compared to Android.
In favour of KMM and Compose Multiplatform I will say that the iosApp module is designed with SwiftUI and uses a Build Phase so it compiles in very good times. On the other hand Kotlin as a language is quite good and modern.
Against that I strongly believe that Dart's dual compiler is much more optimised. The internal binary tree for state management. Compose Multiplatform uses canvas-based rendering, using the Skiko graphics library. Also known as Skia for Kotlin, Skiko is based on Skia. Flutter is currently moving away from Skia in favour of Impeller. Things like this make Flutter (at least for the moment) a far superior technology in performance. Hot Reload, Hot Restart are two missing features of Flutter and last but not least.
I hope this has clarified the pros and cons of this technology, which while interesting on a theoretical and technical level, for me is not close to replacing the wonderful Flutter. If you want to see another extensive review of Flutter you have it here.
Best regards and see you in other posts.
Comments
Post a Comment