Adopting Kotlin multiplatform: a personal experience in production code.

What is Kotlin Multiplatform?

A 'tool' that empowers app developers to share code across Android and iOS.

Kotlin Multiplatform became Stable and Ready for Production Nov 2023.

We incrementally adopted Kotlin multiplatform mobile in Nov 2022 with the following rules in mind:

1. Don't share UI. No matter how tempting it is. UI should be as tied as possible to the look and feel of it's ecosystem.
2. Negotiate sharing things like database & http clients.
3. Share as much business logic as possible.

Business logic after all, is just pure arithmetic and logic. Writing it more than once is nonsense.

Key benefits:

1. Enforces a cleaner architecture by obligating you to write platform agnostic code.
2. Eliminating some of the ‘it works on android but it doesn’t work on iOS' kind of bugs.
3. The time needed to write business logic for native apps is slashed by 25% to 30%.
4. Less lines of code to maintain.
5. And most importantly not giving up the benefits of native programming.
6. Written in Kotlin. You're not introducing a new programming language to your Native App technology stack & in the worst case scenario you're sacrificing only one platform.

Can't say the same about other cross-platform solutions.

1- A cleaner architecture:        

Enters the?Inward Dependency Rule:

• ?Inner layers (business logic) has to be ignorant of?the actual implementation of the platform specific outer layers (UI / DB / etc..).?

• We can achieve that by utilzing the Dependency Inversion Rule which can be achieved by?Dependency Injection.

Injecting is simply passing an instance of an object to a method instead of initiating it in the method body itself.

Inversion is simply injecting such dependency as an abstraction instead of the actual implementation. ie. declaring the type of the injected parameter as an interface instead of a class.

for more check this & Chapter 11 in this.

2. Eliminating some of the ‘it works on android but it doesn’t work on iOS kind of bugs.        

• We started by sharing all API calls. From preparing the request headers query params etc.. to processing and/or persisting the response.
• We then shared the logical sequencing of different API calls. ie (call sign in endpoint then call sync endpoint) or (pressing on a notification marks it as seen and retrieve more details in some cases).
• We did so by deferring threading & the actual network calls to the respective OS http client. There are consideration to adopt Ktor in order to unify the http client. I still believe that background work mechanisms should be deferred to the OS.
• Depending on kotlinx.serialization to convert the Json response to relevant business entities.
• Using dependency inversion to persist the response when needed by using the respective database mechanism (CoreData & Realm for Java in our case)

Now any endpoint consumption related bug is likely to be common in both platforms, meaning that on an organizational level, it's easier to test, spot defects earlier, and fixing them once.

3. App development time is slashed by 25% to 30%.        

With UI out of the equation; one would have expected time to be slashed by 50%, but you still need to write implementations twice for each platform whenever there's an abstraction of a platform dependency injected into the shared code. Code that depends on abstraction can be slower to write but it's more stable and easier to maintain long term. Also If your iOS code base contains Objective-c code (like ours) this can lead to mild challenges as well. Still absolutely worth it.

4. Less lines of code to maintain.        

That's an obvious one, but It becomes even more beneficial if you're in the process of migrating some of your existing code from Objective-c to Swift. You can choose to migrate it to Kotlin instead and using it in Android. Or if you already have it implemented for Android you can choose to use it in iOS and get rid of Objective-C code straight away.

5. You're not introducing a new programming language to your Native App technology stack.        

Android Apps already uses Kotlin, meaning that as a Native App team you already have the know how. You're not introducing TypeScript, C#, darts, or any other new language.

Can't say the same about other cross-platform solutions.

Down sides:

• Trickier debugging in XCode.
• Could lead to over abstraction.
• Depending on generated code.
• You might end up with more workload for the Android team.
• iOS tech leads could arguably be reluctant to adopt such technology.

Summary:

Adopting Kotlin multiplatform in production has been a success story from a personal experience. It can also help getting the Android & iOS teams closer together without sacrificing any of the native development perks. If you're going to adopt it you need to do so responsibly. Stir away from sharing UI code. Threading mechanisms should be kept separate for each OS. If you manage to abstract running work in the background then you're good to go. Consider sharing http clients by depending on Ktor. Sharing Database solutions can be worth it if you have a lot of queries going on, can be justifiably skipped tho. The main downside has been debugging shared code from XCode -some plugins can help mitigate this-. Removing some autonomy from iOS developers. -Can't finish a feature end to end without a kotlin developer- which can be looked at as a perk or as a downside.

Over and out.