Pros and Cons of Developing an App in Kotlin Multiplatform

After the recent success of mobile frameworks like Flutter and React Native, a new contender for multi-platform development is slowly getting more and more popular. Kotlin Multiplatform (KMP) promises to harness the power of shared code for multiple platforms like Flutter and React Native while still having the possibility of platform-specific code for more advanced features.

Even though this sounds very promising, like all things, it has its advantages and drawbacks. Let us analyze them in this article.

Pros of developing an app in Kotlin Multiplatform

Sharing code

The greatest thing about KMP is something that it shares with the aforementioned frameworks – it allows you to write code once and have it working on multiple device types. But KMP does so in a very distinct way:

• It’s easily expendable. To achieve certain behaviors on both Flutter and React Native platforms, you mostly use the API prepared by the framework creators. Adding platform-specific code can be difficult and error-prone. But in Kotlin Multiplatform, you can create your own common API for some platform-specific functionalities with ease.
  For example, for drawing graphics, Android uses its native Canvas whereas desktop uses the Skia rendering engine. If there is a need, you can craft a common API that will draw the same things for the user, but underneath will use the technology appropriate for theplatform in question.

• You can scale an existing application with KMP. For example, if an Android and an iOS application already exist, and a certain new functionality needs to be added for both, this can be done in Kotlin Multiplatform to reduce the development time needed for implementation.

Platform specific code

In KMP, you have a lot of freedom when it comes to using platform-specific code. You can write an Android UI in Jetpack Compose, an iOS UI in SwiftUI, and make them both use a common codebase for business logic.

But you could also use a KMP library like Compose Multiplatform to share both UI and business logic code. Even with such an approach, if you find that two platforms require very different approaches for a feature, Kotlin Multiplatform provides you with an easy way to tackle them independently and add them to your common codebase for future use.

Kotlin language

When working in KMP, Android and some backend developers will feel right at home since the code is all written in the Kotlin language. According to the Stack Overflow Survey 2022, Kotlin is more popular (9.16% vs 6.54%) and more loved than Dart – the language of Flutter.

Kotlin also offers more compile-time safety than JavaScript – the language of React Native, which means that the developers get notified if something is wrong as soon as they compile the app rather than after it has been run. Thanks to that, developers can find bugs early and it improves their productivity. Also, since Kotlin is very well regarded in the programming community, a lot of people are willing to work with it.

Cons of developing an app in Kotlin Multiplatform

Beta version

At the time of writing this article, Kotlin Multiplatform is in its beta phase. According to JetBrains - the company behind the Kotlin language, it should be safe to use in your projects already. Despite that, it’s important to keep in mind that this technology is still not fully matured. Some changes to the API are possible, but there is a great focus on minimizing potential migration issues.

Small community

Kotlin Multiplatform is still in its beginning phase, so there are noticeably less resources online to learn from. Sometimes it might take a developer a lot of time to find a solution to their problem, as they could be one of the first people to encounter it.

Despite that fact, JetBrains regularly puts out detailed documentation on their official website, where it’s possible to find answers to the most important questions and better understand how KMP works.

Years of trial and error on different platforms have led to an established way to write clean architecture. With Kotlin Multiplatform, code architecture is still being explored in different ways, and only with time will the best approach be discovered.

You can of course achieve clean code in KMP, but there are no mainstream well-tested architectural guidelines, so an experienced developer is often needed to establish them by oneself.

Swift limitations and code magic

When using KMP for an iOS app, at the time of writing this article, there are still some limitations and unexpected behaviors when Kotlin code is translated to Objective-C (the language of iOS). For example, default method parameters in Kotlin don’t work after being translated, as Objective-C doesn’t support default parameters at all. JetBrains are currently working to resolve this problem.

The translation process from Kotlin to Objective-C at the moment is a bit time-consuming, which might slow down the iOS part of development. Also, you can sometimes expect underscore characters to be added to your translated Objective-C code. This is one of the most odd bugs – it will not break your application, but may cost you several hours of wondering what and why is happening to your mobile application.

Thankfully, these issues are not something stopping you from creating a fully functional multiplatform application, but rather they are small annoyances that should be fixed or improved with time by the JetBrains team.

Choosing Kotlin Multiplatform for the right project

Kotlin Multiplatform is a technology that already provides developers with powerful tools. Although it has some small issues, KMP can already be used to create applications for multiple platforms and reuse a lot of existing code, speeding up development times.

Its flexibility gives KMP an advantage over its main competitors, React Native and Flutter. Using KMP, you have better control over the functionalities on individual platforms, and you can even extend an existing application with a multiplatform module. In fact, Kotlin Multiplatform might just be the future of multiplatform development.