React Native vs Kotlin Multiplatform: choosing for your team, not the trend

Both let you ship iOS and Android from shared code. They disagree fundamentally about what should be shared. That difference — not benchmarks — is what should decide your choice.

The essential difference

React Native shares the UI as well as the logic. You write components once in TypeScript and they render on both platforms through native views.

Kotlin Multiplatform shares business logic only. Networking, data models, validation and offline storage live in shared Kotlin. The interface is built natively on each platform — SwiftUI on iOS, Jetpack Compose on Android.

Choose React Native when…

• Your team already writes React. This is the strongest single argument. Existing JavaScript and TypeScript skill transfers almost entirely.
• Speed to market matters most. One UI codebase means features land on both platforms together.
• The app is largely standard. Lists, forms, navigation, media, auth — well-trodden ground with mature libraries.
• You want over-the-air updates. Shipping JavaScript fixes without a store review cycle is a real operational advantage.
• The team is small. One codebase is genuinely less to maintain.

What you should be honest about

The bridge between JavaScript and native has overhead. The New Architecture has narrowed the gap considerably, but for heavy animation, complex gestures or sustained high-frequency updates you will still occasionally drop to native. Adding native modules means writing Swift and Kotlin anyway — so “we won’t need native developers” is not quite true in practice.

Choose Kotlin Multiplatform when…

• Your team already writes Android in Kotlin. The shared layer is a natural extension of what they do.
• The interface must feel unmistakably native. SwiftUI on iOS and Compose on Android will always match platform conventions more precisely than an abstraction.
• The app is logic-heavy. Fintech, health, logistics — complex rules, offline sync, careful state. That is exactly what benefits from being written and tested once.
• You depend on platform capabilities. Deep hardware, background processing and OS integrations are simply more direct.
• You are adding to existing native apps. KMP adopts incrementally — share one module without rewriting anything.

What you should be honest about

You are building every screen twice. That is real, recurring cost, and it needs people fluent in both SwiftUI and Compose. The ecosystem is smaller than React Native’s, and iOS build tooling still asks more of you.

How the decision usually resolves

In practice the answer follows the team, not the technology:

• Web team, no mobile specialists → React Native, comfortably.
• Existing Android team → Kotlin Multiplatform.
• Existing native iOS and Android apps → KMP, adopted gradually.
• MVP under time pressure → React Native.
• Regulated, logic-heavy product with a long life → KMP.

Questions that beat benchmarks

1. Who maintains this in three years? Pick what you can hire for and keep.
2. Where does the complexity live — interface or logic? Interface-heavy favours React Native; logic-heavy favours KMP.
3. Does it need to feel platform-native, or just good? Be honest. Most apps need “good”.
4. Are you starting fresh or extending? Existing native code points firmly at KMP.
5. How often do you need to ship? Frequent releases favour over-the-air updates.

What does not decide it

Ignore framework benchmark videos. Both render through native views; both are comfortably fast enough for the overwhelming majority of applications. Performance becomes decisive only in narrow cases — sustained 60fps custom animation, real-time audio or video processing, heavy on-device computation. If that is your app, you likely knew already.