Discover the wild world of mobile -- Why Choose Kotlin Multiplatform?

Whenever a mobile project begins, the first major decision is which technology to select. Should the project use native or cross-platform development? Native offers a clear advantage: access to the latest updates, direct interaction with native APIs, optimal performance and native look and feel. However, adopting a native approach requires two teams to work simultaneously, which increases the chance of discrepancies between the platforms' features, leading to duplication of effort and an increase in maintenance costs.

A cross-platform solution enables the development of an application for multiple platforms, allowing code reuse. However, you may not have immediate access to the latest development tools, you will have limited direct access to native APIs, might need third-party libraries to interact with hardware features, and the final application will likely be less performative than one built with a native solution.

The cross-platform market has two bigger players: React-Native and Flutter. React Native is a JavaScript framework, initially created by Meta and now supported by the community. Flutter is based on Dart and was created by Google. Both require a middle mechanism to connect with native APIs. In the React-native case, it's a JavaScript bridge, and for Flutter, it's a custom engine. I have never worked with Flutter, but I enjoyed working with React-native, despite facing numerous challenges, particularly with styling the UI and a significant dependency on third-party libraries.

Two years ago, I first heard about Kotlin Multiplatform(KMP). Initially, I thought it was a crazy idea to start a new project with a technology that was still in beta phase and a community that was still growing. But we gave it a chance, and so far, we have zero regrets. We don't have a strong dependency on third-party libraries, allowing us to utilise the full platform capacities. We haven't detected any performance issues, and we are using native UI. We encountered issues with iOS crash troubleshooting. The biggest issue yet to solve is how the team with two stacks should organise to avoid code conflicts.

You may wonder what sets KMP apart from other cross-platform options. To start, it doesn't have a middle solution to mediate the communication between the KMP code and the native APIs. The code is compiled into binaries for each platform, JVM bytecodes for Android and native binaries for iOS, allowing interoperability with Swift/Objective-C. KMP can be used in 3 ways:

• shared logic: The business logic is shared between platforms by reusing the code, but the UI remains native, Jetpack Compose and SwiftUI. It guarantees that business logic is consistent and reduces the development time. However, it doesn't prevent inconsistencies between UIs.
• share a part of logic: It is possible to use KMP just in a small part of the code and integrate with the existing native codebase. This may be used to create critical modules or features, with the same advantages and disadvantages as those mentioned above.
• UI and Logic are shared: With Compose Multiplatform, it is possible to have 100% of the code reused, as we have in other cross-platform solutions. This allows us to take advantage of 100% of the qualities of a cross-platform solution, including total reusable code and consistent behaviour, resulting in cost reduction in development and maintenance.

In contrast to the other cross-platforms, we can define the following differentiating points:

• Performance: because KMP compiles the code to native and doesn't need a middle solution, it often leads to performance closer to native apps.
• native interoperability: KMP offers seamless interoperability with existing native code and direct access to native APIs
• Flexible adoption: KMP modules enable the team to select the pace of adaptation, with less risk involved when stepping back (not as much for Compose Multiplatform). For Android, most can be converted to native, while for iOS, the main effort will be on rebuilding the business logic.
• Tooling: Both native IDEs, Android Studio and Xcode, can be used, taking advantage of each IDE's features.

Initially, I was sceptical about working with KMP, but now I am convinced I made the right decision by allowing myself to experience and learn from KMP. I am excited to see the community growing as more organisations consider KMP for their projects. I hope my articles about my journey contribute to that growth.convinced that I made the right decision in allowing myself to experience and learn from KMP. I am excited to see the community growing as more and more organisations are considering KMP for their projects. And I hope my articles about my journey can contribute to that growth.