Moving to Kotlin Multiplatform (Part 1/4)

Starting the journey

At Interpolis, we noticed that it was getting time-consuming to implement business logic twice. Once for Android and once for iOS. This meant we had to look for a solution to tackle this problem and eventually it boiled down to three possible technologies, Xamarin, Flutter, and Kotlin Multiplatform Mobile(KMM). The first two technologies were discarded quite quickly. We did not choose Xamarin because we wanted to keep both apps native and there is a lack of C# knowledge in the team. We did not choose Flutter because none of the developers felt confident that moving the Flutter was the right choice and it would mean a full rewrite. So in the end we chose KMM because we could keep our current UI, gradually move business logic to KMM, and actually keep two native apps. With our choice made, an iOS colleague and I started playing around with KMM to create a shared library for one of our smaller apps, this was a year ago.

Struggles

Our first attempt was not very successful, KMM was not mature enough and we ran into a lot of issues. Problems with the IDE, compilation times for iOS, threading, Gradle, etc etc. This was all before Kotlin 1.4 and we stopped working on our first attempt after 6 months. When Kotlin 1.4 was released we gave it another try, and boy it was different! My iOS colleague mentioned that working on our first attempt the framework felt “ghetto”, and I cannot agree more. But since everything worked real smoothly now, we got really excited and we started working on our second Proof of Concept (PoC). This PoC would eventually grow to a production-ready library and would be added to one of our apps.

Onboarding the team

We planned regular meetings with the whole development team to make them part of every major decision. For example, the iOS team wanted to keep using RX-Swift and the Android team Coroutines. So together we came up with an architecture that supports both. We expose use cases that encapsulate shared business logic and sent events back to the native apps, this all can be wrapped nicely for the iOS RX-Swift implementation. That architecture will be covered in part 2.

To get everyone onboard I believe that it is paramount that everyone is involved, from junior-developer to architect. That does not mean that everybody should start working on a PoC but moving to another tech can be daunting and everybody should have the opportunity to speak their mind when they are worried or got a better idea.

For our team, it took about a year from our first PoC where most developers were still cautious to the point where we are now and everybody is on board. Even the iOS developers now say “Wow, this actually works really well!”.

Where are we going

We have split up the move to KMM into three phases. In short, it are the following phases.

• Phase 1: Move shared business logic to a KMM library and implement it with an agreed-upon architecture. Add the KMM library directly to the app.
• Phase 2: Push the KMM library to Azure’s Artifacts Feed and pull the library into the app from Azure.
• Phase 3: Extract generic components that can be re-used in other KMM libraries and use this as a so-called “core” library for our apps.

This series is about phase 1.

Next:

Part 2: Our architecture and tech-stack.

Part 3: Using a custom HTTP engine with Ktor.

Part 4: Final thoughts.