KMP vs Flutter vs React Native

There is a wide range of options in cross-platform nowadays, among them Flutter, React Native, and, of course, Kotlin Multiplatform Mobile. Which technology should you choose, and why this one? Let’s try to clear out!

All technologies have their advantages and disadvantages, resolve particular problems, but never all of them. Thus, your choice will depend on specific tasks.

Guys from Jetbrains have made an incredible attempt to optimize development costs and reuse the code. Moreover, such reuse is possible not only within one platform but also between different platforms (Android and iOS). If your development team wants to keep native UI for each platform, then Kotlin Multiplatform Mobile is your perfect option.

It is due to the fact that Kotlin Multiplatform doesn’t do UI at all. It, instead, does business logic for Android and iOS apps. Because of the special configuration of the project, it is possible to make a project that will be compiled in the Android library with specific code for Android, and in the iOS framework with the corresponding code for iOS. From a technical perspective, there are no more problems with using the same code on iOS and Android at the same time. When you debug your code, you only need to edit it once, and changes will happen on both platforms. However, on the native side of applications, it would be better not to share the following:

• the whole interface;
• binding the interface to the shared Viewmodel from the shared code library;
• platform-specific features: work with camera, NFC, Touch ID, or Bluetooth.

And in any case, sharing UI code across platforms is not necessary. This usually requires several iterations to make the user UI and behave more natively. This, in turn, requires additional development cycles.

Flutter uses canvas from native SDK of different platforms and draws its UI component on that canvas using Material design specifications. React Native uses native components mapped to js code. React makes it possible to update the application logic without rebuilding and re-uploading to the store (the js code is downloaded from the servers and immediately starts working on the device, without updating the entire application).

As for the business logic, it is also common in Flutter and React native, but written in Dart and JavaScript respectively, which mobile developers accustomed to the native stack are not familiar with. That is, these platforms will require a communication bridge between native and non-native code.

The design consistency for all versions of the operating system and between the operating system is the benefit of Flutter as well. This technology also allows you to easily create your own custom design. It is hardly possible to compare the high development speed and high productivity of Flutter with other technologies, as it is definitely its undoubted advantage.

There are no intermediate layers to deal with in Kotlin Multiplatform Mobile, which virtually eliminates any interop bottlenecks. And because Kotlin Multiplatform works with the native platform ecosystems, developers can use the tools and libraries they’ve always used, including SwiftUI and Jetpack Compose. You may code around the limitations with Kotlin, Swift, or any other language. But in the case of Flutter, we have to stick to Dart only and in React Native we have to stick with js only.

Kotlin Multiplatform doesn’t require a VM, while React Native does. Even though Flutter also doesn’t require a VM in production, you should write in a non-native language in a non-native ecosystem. At the same time, it is very easy to write native code at any level of coding and at any layer of the architecture in Kotlin Multiplatform.

Unlike Flutter or React Native, where you should proceed with their infrastructure, KMM has the power to get integrated with any existing project. ​​Kotlin Multiplatform does not become its own ecosystem but works with ecosystems of the native platform. You may use those tools and libraries you’re used to, including SwiftUI and Jetpack Compose. Any limitations you face can always be coded around using Kotlin, Swift, or any other language that is convenient for solving this specific problem with the least risk.

Implementation of KMM can be carried out step by step, without the need to stop the current development process. We are preparing a roadmap for expanding the use of KMM in the project so that after each step a release to the store can be carried out. It is also important that we are expanding the use of KMM with the current application code, which helps to save the project from new bugs.

In the KMM project, only one specialist is required to make the common code and the native side of its platform, and it will be required to connect a specialist from another platform only to embed UI to existing logic. The code is written only once, which eliminates the risk of having two sets of bugs instead of one, which you will get here.

As a result, the support and development of the application become much cheaper, more efficient, the implementation of various features will also be noticeably faster and at the same time, you will save full nativeness for the developer and user.

Read more about KMM in our blog.