Share the logic. Keep the UI native. Stop writing every rule twice.
Kotlin Multiplatform is the pragmatic middle ground: one implementation of your business rules, networking, validation and data models, with a real SwiftUI app on iOS and a real Compose app on Android sitting on top.
I've worked on exactly this setup in production — contributing to the shared KMP layer behind a national carrier's self-care app while owning the iOS side of the same product. I know where the seams are and how to keep the iOS experience from becoming a second-class citizen.
Models, repositories, API clients and business rules written once. Bug fixed once. Behaviour identical on both platforms by construction.
SwiftUI on iOS, Compose on Android. Users get platform-correct navigation, gestures and animation.
KMP can be introduced module by module into apps you already have. I'd rather move one domain across and prove it than pitch a big-bang rewrite.
The shared module becomes the agreement between iOS and Android engineers, which removes a surprising amount of recurring argument.
The customer selfcare app for a national mobile carrier, used by hundreds of thousands of people to top up, pay bills and track usage. I own the Top-Up, Payments and Dashboard modules, contribute to the shared Kotlin Multiplatform business layer, and automated the multi-environment release pipeline.
We look at your app and identify what is genuinely platform-independent. That's usually more than teams expect.
One feature moves into the shared module and ships to both stores. Real evidence before a wider commitment.
More domains move across as the pattern proves itself, with both native apps staying releasable throughout.
Your iOS and Android engineers end up owning it. That's the point.
Tell me what you're working on and where it's stuck. I'll be straight with you about whether I'm the right fit.
Get in touch