Decide What Stays Native

KMP rewards sharing logic, but not every line should move. The real skill is deciding what goes shared and what stays comfortably native.

Calculations, validation, networking and parsing belong in shared code. They behave identically everywhere, so writing them twice only invites drift.

A polished, platform-true interface is often worth writing twice. Jetpack Compose and SwiftUI let each app feel native while sharing the brains beneath.

ViewModels and state can be shared, yet many teams keep presentation native for flexibility. It is a deliberate trade, not a rule carved in stone.

Cameras, sensors, biometrics and deep OS features are easiest in native code. Wrap them behind expect/actual when shared code must reach them.

Crossing the Kotlin-to-Swift bridge has friction. If exposing something shared makes the Swift side ugly, leaving it native can be the kinder call.

Mature pieces, like core logic, are safe to share. For areas still evolving, such as cutting-edge UI, staying native avoids fighting young tooling.

If your iOS team loves SwiftUI, forcing shared UI may slow them. Honest team preferences are a legitimate input to the share-or-not decision.

Ask one question: would this behave the same on every platform? If yes, share it. If it is about feel, hardware or look, lean native.

The boundary is not permanent. Start native, then promote stable code into commonMain later. KMP lets the share line shift as confidence grows.

There is no purity prize for sharing one hundred percent. The best KMP apps share what truly benefits and stay pragmatic about the rest. 🙂

Which kind of code is the strongest candidate to keep native?

You learned to share logic, models and networking while keeping UI and hardware native, using a simple heuristic and shifting the line as confidence grows. 🎉