Why I Chose Native Over React Native (and When I'd Use RN)

I get this question from every client: "Should we build with React Native to save money?" And every time, my answer depends on what they are building.

I have shipped apps on both stacks. I started with React Native in 2021 before transitioning to fully native development at MishoraStudio. This is an honest account of why I made that change and the specific conditions under which I would still recommend React Native today.

Why I Left React Native

The breaking point came during a project that needed a custom camera interface with real-time filters. In React Native, this meant writing a native module in Swift, bridging it to JavaScript, and handling the asynchronous communication carefully. The module itself was 80 lines of Swift. The bridge code was 150 lines of TypeScript. The debugging involved two separate runtimes.

In native Swift, the same feature was 120 lines of code with direct access to AVFoundation, no bridging, and Xcode's debugger showing me exactly what was happening.

That project made me question every abstraction layer I was relying on.

The Real Cost of Cross-Platform

React Native's value proposition is code sharing. Share business logic, share UI components, ship on two platforms with one codebase.

In practice, what I observed across multiple projects:

Business logic sharing works: Networking, data models, validation — these genuinely are shared
UI sharing is fragile: Platform-specific navigation patterns (tab bars on iOS, bottom navigation on Android), different fonts, different spacing conventions, different safe area handling — each difference adds a conditional

After the first year of maintaining a React Native app, the codebase accumulated enough platform-specific conditionals that the shared UI was barely 40% of the total. The maintenance burden of the abstraction layer outweighed the benefit.

Where Native Wins

Performance predictability: Native SwiftUI and Compose are compiled to platform code. There is no JavaScript bridge, no hermes engine, no async boundary between your code and the system. Every animation, every scroll, every transition is predictable.
Platform feature access: When iOS 26 ships with a new API — say, the Liquid Glass material effects — native developers use it on day one. React Native developers wait for a community package, a type definition update, and a version bump.
Debugging simplicity: An iOS crash in a native app gives you a stack trace in Swift. The same crash in a React Native app may originate in JavaScript, the bridge, a native module, or hermes. Each layer adds ambiguity.
App size: A minimal React Native app is 40-60MB. A native SwiftUI app doing the same thing is 5-10MB. For users in markets with slow connectivity, that difference matters.

Where React Native Still Makes Sense

Despite my preference for native, there are scenarios where React Native is the better choice:

You already have a React web app: If your team is strong in React and you need a mobile presence quickly, React Native lets you leverage existing skills. The app will not be optimal, but it will exist.
Simple CRUD apps: If your app is essentially forms and lists hitting a REST API — dashboards, admin panels, data entry tools — React Native is perfectly adequate. The abstraction overhead is minimal because the UI is simple.
Tight budget, low performance requirements: If budget is the primary constraint and the app does not need smooth animations, camera access, Bluetooth, or real-time processing, React Native can deliver 80% of the quality at 60% of the cost.
Prototyping and MVPs: For proving an idea exists, React Native's development speed is real. You can iterate faster. Just plan to rewrite natively if the product gains traction.

My Hybrid Approach Today

At MishoraStudio, I use a pragmatic split:

Shared API layer: I design REST endpoints and data models that both platforms use. This is where "cross-platform" actually delivers value
Native UI on each platform: SwiftUI for Apple devices, Jetpack Compose for Android
Common design system: Figma components that map to native implementations on each platform

The design system is shared. The architecture patterns are similar. The actual code is platform-native.

The Verdict

If I am building a production app that real users will depend on — an app that needs to feel at home on each platform, perform well, and use the latest OS features — I build native. Every time.

If I am building an internal tool, an MVP, or an app where "good enough" is genuinely good enough, React Native is a reasonable choice.

The mistake is assuming React Native is free. It is not free. It trades platform quality and long-term maintainability for short-term development speed. Sometimes that trade is worth it. Often it is not.