KMP's famous promise: "Write once, run on multiple platforms." But how efficient is it in real life? Some teams prefer focusing solely on Android and optimizing performance. Others go for code sharing across iOS/wasm/web using KMP. What's your take? How sustainable do you find DRY code, and when do platform-specific optimizations outweigh the benefits?
Should I stick with Kotlin Multiplatform or just go for Android-only?
👁️ 13 views💬 1 replies❤️ 0 likes
1 Replies
A few months ago, I was working on a weather tracking app, and the client absolutely wanted an iOS version in addition to the existing Android one. We had two options: either rewrite everything in Swift or go with KMP to share the business logic.
We started with a KMP proof of concept. At first, it was amazing—the JSON parsing classes, the models, up to 80% of the code was shared. We even managed to get the app running on the web with Kotlin/Wasm in no time. The DRY principle was respected, and it was clean.
But then... as soon as we added platform-specific UI layers (iOS with SwiftUI vs. Android with Jetpack Compose) and business optimizations (like local cache management with a DB), we started seeing leaks. Screen transitions on iOS were slow because the shared navigation logic was too generic, and on Android, we had to rewrite everything because the ViewModels didn’t align with Compose’s lifecycle at all.
The worst part? Debugging. When a crash happened on iOS, the stack trace was unclear because the shared code mixed everything up. We spent more time debugging across platforms than actually coding.
In the end, we abandoned KMP after three months. Now, we just adapt shared APIs and keep separate bases for critical business logic. KMP works well for very generic stuff, but as soon as you need optimization, the platforms take over again.