Moving to Kotlin Multiplatform (Part 4/4)

Final thoughts

Ronald Van Duren
2 min readMar 23, 2021

For most apps, Kotlin Multiplatform can be considered production-ready at the moment. It is not difficult to set up the project and important components like serialization, storing data, and making network requests work great! However, there are somethings that can be improved. Like threading in Kotlin Native, the conversion of Kotlin to objective-c, and compilation times for the iOS binary. All of these things are on the roadmap of Kotlin so that will be tackled in the near future!

Investment

When I look back at where we started and where we are now, we have come a long way. Because we moved shared business logic to KMM we have got a codebase that is easier to maintain and has less chance of making mistakes twice. But if you start this journey with both an Android and iOS team, you have to understand that at first it will not save time and it will take time to onboard the team. It is truly an investment that in the end pays off.

We have got a solid foundation now but there are several things that we want to implement/refactor and we will start working on soon.

Core

Currently, we have created two main packages. One where we have put everything that belongs solely to the context of the app, the use cases and HTTP services for example. And one where we have put components that are more generic(a core package), as our generic networking components with Ktor. These generic components will eventually be moved to a separate repository so they can be reused in other KMM libraries of other apps. But to do so, we need a means of distributing the artifacts.

Distributing

The artifact that is created is currently included directly in the native apps. This is fine as a short-term solution, but one of the next things we are going to pick up is pushing our artifacts to Azure’s Artifacts Feeds. This will give us more control and flexibility over what is included in our apps. For example, if there is a bug in one of our library releases, then a platform can temporarily downgrade the version and continue with developing.

Once we have got the distributing flow in place, it will also allow us to distribute generic KMM libraries that are used across all our (future) apps.

Done!

I hope you had fun reading and maybe picked something up for your own KMM project!

Previous parts

  • Part 1: Starting the journey
  • Part 2: Our architecture and tech-stack
  • Part 3: Using a custom HTTP engine with Ktor

--

--