The now and the future of Kotlin Multiplatform – is it worth it?
In the second part of the interview about Kotlin Multiplatform, our mobile developers, Grzegorz and Mikołaj, answer some more questions and dispel doubts about cross-platform mobile development with KMP. If by any chance you have missed part 1 – “Kotlin Multiplatform: Expectations vs. Reality for iOS and Android developers” – click here to catch up!
Why should Kotlin Multiplatform be better than, for example, Flutter?
Mikołaj: I would not compare Kotlin Multiplatform to Flutter – the latter is a solution dedicated to other purposes. Flutter works well when you want to have the entire mobile application created just once – by “entire” I mean both the user interface and the business logic of the app.
Kotlin Multiplatform, on the other hand, will prove itself when you want to provide the user with a native interface. You can notice and feel when a given application is written natively, at least in most cases. The key here is sharing the business logic of the application, that is, all the algorithms behind what the user sees. What is shown on the screen is one thing, and what processes the data that the user enters is another.
In my opinion, this is a significant advantage, as the user does not know what is working as the backend – it is a shared code. As a result, the quality of our software, which is still a cross-platform mobile application, increases dramatically.
Is Kotlin Multiplatform production ready?
Grzegorz: Using Kotlin is associated with challenges like the ones we discussed earlier. However, these are not insurmountable obstacles. Sometimes it’s a little more demanding to do something, for sure, but it is far from impossible and does not affect the final product in terms of its quality. Kotlin Multiplatform is worth considering for cross-platform mobile development.
How to start working with Kotlin Multiplatform? How to talk to iOS and Android developers?
Mikołaj: First of all, you need to define the vast majority of business requirements – defining all of them is unrealistic, I know. Those that are the basis of a given mobile application should be crystal clear for everyone though.
Proper analysis is also crucial – a well-done analyst’s job means less work for the developer. This is especially important considering the Kotlin Multiplatform – it will make the shared code more efficient and effective.
The design of the application also matters, it allows us to see and understand what should be included in the common code. Thanks to this, we can save time by avoiding many corrections later on. These, although implemented in one place, can affect two platforms simultaneously in different ways.
What kind of mobile applications is Kotlin Multiplatform best suited for?
Mikołaj: At Speednet, we created smaller applications using KMP, such as event apps and booking services. Now, while still applying Kotlin, we are working on more complex projects, like advanced applications for mobile banking. An interesting example of a smaller Kotlin Multiplatform implementation is RESQL, a solution that allows reporting incidents of peer violence in schools. KMP did very well there – it reduced the amount of work needed to integrate everything.
Kotlin can also decide what to render – this is the way we went on a big multiplatform project. However, it can also be responsible just for, let’s say, communication and cache management, which is ideal for smaller cross-platform projects.
Another example of using Kotlin Multiplatform for a smaller app is an algorithm that is needed to draw some complicated graph or to calculate some tax contributions. It makes perfect sense when it comes to implementations like this one – possible future corrections of such an algorithm, which may be very complicated, will therefore be easier due to shared code.
What kind of mobile applications is Kotlin Multiplatform best suited for?
Grzegorz: In larger hopefully-to-be multiplatform projects, you first need to decide if the common code will even work. For example, if the project has many repetitive screens, maybe it will be worth doing something that will allow us to render the entire application using Kotlin Multiplatform.
You also need to know exactly what the app is supposed to do. You may find that a photo editing app, despite its size and complexity, does not have much space to apply the shared code. Using Kotlin for this project may not pay off.
The bottom line is, that you don’t choose the technology first, you choose the technology according to your requirements. These come first. Given pros and cons will help you to wisely define the proportions between native technology and shared code in the project.
What will the future of Kotlin Multiplatform look like?
Mikołaj: In my opinion, if the project is large, starting with KMP is worth it. If you know that this particular project will last at least 3 years, then during this time the technology will probably get rid of all rough edges. Also… 3 years is a huge time gap in terms of tech knowledge.
However, Kotlin Multiplatform is not only for iOS and Android apps. It is also backend, web applications… You can create teams of programmers writing in Kotlin that can cover the entire stack – everything can be combined. Also, using one language leads to better communication. Some things are better to be shared.
Compiling everything written in Kotlin depends on where it gets deployed – the possibilities are almost endless. Objective-C for iOS, Java for Android, backend native code, as well as binary code. When writing scripts in Kotlin, we do not limit ourselves to just web applications – we can also manage large amounts of data.
Grzegorz: The client also gets many business benefits from Kotlin Multiplatform – the development process of the application itself can be faster and its maintenance becomes easier. Everything is consistent.
Kotlin Multiplatform is something that should be on everyone’s radar. Looking for a solution on how not to duplicate business logic? Kotlin may be the right answer.
