<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/why-we-chose-kmp-over-react-native-it-s-an-architecture-bet-not-a-framework-preference-gjuzubyyt" -->

---
title: Why We Chose KMP Over React Native: It’s an Architecture...
description: A mobile team explains their decision to adopt Kotlin Multiplatform (KMP) over React Native, framing it as an architectural choice rather than a framework...
canonical: https://daily.dev/posts/why-we-chose-kmp-over-react-native-it-s-an-architecture-bet-not-a-framework-preference-gjuzubyyt
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Why We Chose KMP Over React Native: It’s an Architecture Bet, Not a Framework Preference | daily.dev
og:description: A mobile team explains their decision to adopt Kotlin Multiplatform (KMP) over React Native, framing it as an architectural choice rather than a framework...
og:url: https://daily.dev/posts/why-we-chose-kmp-over-react-native-it-s-an-architecture-bet-not-a-framework-preference-gjuzubyyt
og:image: https://api.daily.dev/og/posts/GjUZuByyT.png
og:image:alt: Why We Chose KMP Over React Native: It’s an Architecture Bet, Not a Framework Preference
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Why We Chose KMP Over React Native: It’s an Architecture Bet, Not a Framework Preference

**[Medium](https://daily.dev/sources/medium_js)** · 5 min read · 1 upvotes · 0 comments

## Summary

A mobile team explains their decision to adopt Kotlin Multiplatform (KMP) over React Native, framing it as an architectural choice rather than a framework preference. The core argument is that React Native bundles a JavaScript engine and relies on a bridge layer, introducing performance overhead and type-safety gaps, while KMP compiles shared Kotlin code directly to native formats (JVM bytecode on Android, LLVM-compiled native framework on iOS). A concrete battery-level API example illustrates how KMP's expect/actual mechanism enables synchronous, fully-typed native API access without bridge boilerplate. The post also argues that sharing business logic (networking, state, database) while keeping native UIs (SwiftUI on iOS, Jetpack Compose on Android) is superior to forcing a shared UI layer that compromises platform-specific UX conventions.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://medium.com/@Y4583L/why-we-chose-kmp-over-react-native-its-an-architecture-bet-not-a-framework-preference-e9ad0a7dffd5>

## Questions this post answers

### How does Kotlin Multiplatform access native APIs compared to React Native's bridge?

Kotlin Multiplatform uses expect/actual declarations to define a contract in shared code and implement it natively per platform, so Swift consumes the compiled Kotlin code as a local library with synchronous, typed calls. React Native instead requires writing separate native modules, bridging them through NativeModules, and calling them asynchronously via promises, adding boilerplate and losing type safety across the JS/native boundary.

_daily.dev surfaces architecture comparisons like KMP versus React Native for teams weighing native performance against shared UI convenience._

### Why does React Native have a performance overhead that Kotlin Multiplatform avoids on iOS?

React Native bundles a JavaScript engine, Hermes, inside the app binary, so every call to native device features or UI updates must serialize data across a bridge or JSI layer. Kotlin Multiplatform instead compiles shared code directly into native formats: JVM bytecode on Android and a native framework via LLVM on iOS, eliminating the extra runtime engine and bridge entirely.

_engineers picking a cross-platform mobile stack can track architecture trade-offs like this one on daily.dev._

### What is the downside of sharing UI code between iOS and Android in React Native?

Forcing iOS and Android to share the same UI layer creates UX compromises, since iOS users expect native scroll physics and Apple HIG behavior while Android users expect Material design, leading to tangled platform if/else checks inside components. It also creates dependency conflicts, since upgrading React Native or npm packages frequently breaks native builds when Xcode or Gradle are updated.

_teams debating shared UI versus shared logic in mobile apps can follow this kind of architecture debate on daily.dev._

## Similar posts on daily.dev

- [Why we love multiplatform with Kotlin and Compose](https://daily.dev/posts/why-we-love-multiplatform-with-kotlin-and-compose-ygw5twyaa) · Q42 Engineering · 0 upvotes · 0 comments
- [Kotlin Multiplatform Is Not Cross-Platform: Understanding the Real Difference](https://daily.dev/posts/kotlin-multiplatform-is-not-cross-platform-understanding-the-real-difference-feksv6re1) · Medium · 0 upvotes · 0 comments
- [Helping Decision-Makers Say Yes to Kotlin Multiplatform \(KMP\)](https://daily.dev/posts/helping-decision-makers-say-yes-to-kotlin-multiplatform-kmp--ts09b63zw) · JetBrains · 1 upvotes · 0 comments

---

Tags: [#mobile](https://daily.dev/tags/mobile), [#react-native](https://daily.dev/tags/react-native), [#kotlin](https://daily.dev/tags/kotlin)

[View this post on daily.dev](https://daily.dev/posts/why-we-chose-kmp-over-react-native-it-s-an-architecture-bet-not-a-framework-preference-gjuzubyyt)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Why We Chose KMP Over React Native: It’s an Architecture Bet, Not a Framework Preference","url":"https://daily.dev/posts/why-we-chose-kmp-over-react-native-it-s-an-architecture-bet-not-a-framework-preference-gjuzubyyt","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/why-we-chose-kmp-over-react-native-it-s-an-architecture-bet-not-a-framework-preference-gjuzubyyt"},"datePublished":"2026-08-03T10:32:58.340Z","dateModified":"2026-09-13T20:56:01.951Z","description":"A mobile team explains their decision to adopt Kotlin Multiplatform (KMP) over React Native, framing it as an architectural choice rather than a framework...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f84903afb9c66c258f456324095c808d?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f84903afb9c66c258f456324095c808d?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Medium","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Medium","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/medium","url":"https://daily.dev/sources/medium_js"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/why-we-chose-kmp-over-react-native-it-s-an-architecture-bet-not-a-framework-preference-gjuzubyyt","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"mobile,react-native,kotlin","timeRequired":"PT5M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Medium","item":"https://daily.dev/sources/medium_js"},{"@type":"ListItem","position":3,"name":"Why We Chose KMP Over React Native: It’s an Architecture Bet, Not a Framework Preference"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/why-we-chose-kmp-over-react-native-it-s-an-architecture-bet-not-a-framework-preference-gjuzubyyt#faq","mainEntity":[{"@type":"Question","name":"How does Kotlin Multiplatform access native APIs compared to React Native's bridge?","acceptedAnswer":{"@type":"Answer","text":"Kotlin Multiplatform uses expect/actual declarations to define a contract in shared code and implement it natively per platform, so Swift consumes the compiled Kotlin code as a local library with synchronous, typed calls. React Native instead requires writing separate native modules, bridging them through NativeModules, and calling them asynchronously via promises, adding boilerplate and losing type safety across the JS/native boundary. daily.dev surfaces architecture comparisons like KMP versus React Native for teams weighing native performance against shared UI convenience."}},{"@type":"Question","name":"Why does React Native have a performance overhead that Kotlin Multiplatform avoids on iOS?","acceptedAnswer":{"@type":"Answer","text":"React Native bundles a JavaScript engine, Hermes, inside the app binary, so every call to native device features or UI updates must serialize data across a bridge or JSI layer. Kotlin Multiplatform instead compiles shared code directly into native formats: JVM bytecode on Android and a native framework via LLVM on iOS, eliminating the extra runtime engine and bridge entirely. engineers picking a cross-platform mobile stack can track architecture trade-offs like this one on daily.dev."}},{"@type":"Question","name":"What is the downside of sharing UI code between iOS and Android in React Native?","acceptedAnswer":{"@type":"Answer","text":"Forcing iOS and Android to share the same UI layer creates UX compromises, since iOS users expect native scroll physics and Apple HIG behavior while Android users expect Material design, leading to tangled platform if/else checks inside components. It also creates dependency conflicts, since upgrading React Native or npm packages frequently breaks native builds when Xcode or Gradle are updated. teams debating shared UI versus shared logic in mobile apps can follow this kind of architecture debate on daily.dev."}}]}
```

