Kotlin Multiplatform migration
Is Kotlin Multiplatform worth it for your app? Start with the data layer
Kotlin Multiplatform lets Android and iOS share business logic and data while each keeps a fully native UI. I help teams decide whether it’s worth it for their product, then adopt it one module at a time, starting where sharing pays off first.
Opens Cal.com in a new tab.
- years building Android and iOS apps
- 13
- approaches shipped to production: native, Kotlin Multiplatform, React Native
- 3
- to rewrite two native apps into one React Native codebase
- 6 months
Who it’s for
Sounds familiar?
- Every feature is built twice, once in Kotlin and once in Swift, and the two drift apart.
- Business rules behave slightly differently on Android and iOS, and users notice.
- You’re weighing a full cross-platform rewrite, but don’t want to give up native UI.
- You’ve heard Kotlin Multiplatform is ready for production, but not how to start without stopping feature work.
How I build it
How I’d adopt it in your app
01
Decide what to share, and what stays native
Business rules, data models and storage are good candidates for shared code. Screens, platform features like the camera, and anything that has to feel native usually stay native. The right split depends on your product and team, not on the tool.
02
Start with the data layer
HelperBook keeps its records in a shared Kotlin Multiplatform module with a SQLDelight database, so the schema and queries are written once. It’s the lowest-risk place to begin: no UI changes, and the shared code is easy to test on its own.
03
Adopt it alongside the apps you have
The shared module is added to your existing Android and iOS apps. Nothing is rewritten in one go, and feature work carries on while more code moves into the module.
04
Make release builds safe
Shared code has to survive code shrinking and serialisation. HelperBook ships with R8 rules written for SQLDelight and kotlinx-serialization, so obfuscation doesn’t break the database layer or the export format.
05
Say so when it isn’t the right call
If your team works in JavaScript, or one codebase for the UI matters more than a native feel, React Native can be the better choice. I led the rewrite of two native apps into one React Native codebase at Pulse, and I’ll recommend it when it fits.
What you get
What’s included
- Deciding what to share and what stays native
- Shared module design with a SQLDelight data layer
- Incremental adoption alongside your existing apps
- Build setup for the shared module in your existing release process
How we start
Paid discovery
A fixed fee of ₹60,000 (US$900) for about a week: audit or product scoping, ending in a plan and estimate.
FAQ
Questions clients ask
Is Kotlin Multiplatform ready for production?
For sharing logic and data, yes. HelperBook’s data layer runs in a shared Kotlin Multiplatform module in production on Google Play. HelperBook ships on Android today, and the shared module means an iOS app can reuse that data layer instead of rewriting it.
Kotlin Multiplatform, React Native or Flutter?
I’ve shipped native Android and iOS apps, a shared Kotlin Multiplatform module and a full React Native rewrite, and I recommend one based on your team, timeline and which parts must be native. I haven’t shipped a Flutter app, so I won’t argue for or against it from experience.
Do we have to rewrite our apps?
No. Adoption is incremental: one shared module added to the apps you already have, then more code moves into it as it proves itself.
How does an engagement start?
With a paid discovery sprint: I review both codebases, recommend what to share first, and write a plan and estimate you can use with anyone.