React Native vs Native iOS and Android: When Cross-Platform Is the Wrong Call

Every founder eventually hears it from someone: "Real apps are built natively." Sometimes that's sound advice. More often it's a reflex from a time when cross-platform meant slow, odd-looking apps.

This guide is about React Native vs native development in 2026: building one React Native app for iOS and Android versus two apps in Swift and Kotlin. I'll be specific about when native genuinely wins, because there are real cases, and about the middle path most serious React Native apps take anyway.

Key takeaways

• React Native wins when you need both iOS and Android, share business logic, want one team, and ship often.
• Native wins for apps whose core value is a platform feature (widgets, watch apps, AR, advanced camera pipelines), for single-platform apps, and for games, which belong in game engines anyway.
• It isn't all or nothing. React Native apps call Swift and Kotlin directly through native modules, so platform-specific features can live inside a cross-platform app.
• Performance is rarely the deciding factor for business apps. React Native's New Architecture renders real native views and calls native code directly.
• The biggest difference is team cost: two native codebases usually need two specialist skill sets for the life of the product.

The honest comparison

React Native vs Swift and SwiftUI for an iOS app

If you'll only ever ship on iOS, Swift with SwiftUI is a strong default: first-class access to every Apple API on day one, the native look by construction, and no bridge to another language. React Native earns its place on iOS when Android or the web is coming later, when your team is stronger in TypeScript than in Swift, or when you want over-the-air updates for fixes. The two aren't exclusive: React Native apps use Swift for native modules, and Expo UI can render SwiftUI controls from React.

React Native vs Kotlin for Android

The same logic applies on Android. Kotlin with Jetpack Compose is the native standard and the best fit for Android-only products or deep platform work. React Native shares most of the code with iOS, which usually matters more than any single-platform advantage. And "React Native vs Android Studio" is a false choice: Android Studio and Xcode are the IDEs and build tools you still use to build, debug and profile React Native apps.

When native is the right call

I'd recommend going native in these cases, even though I build with React Native:

1. The product is a platform feature. If the core experience is a home-screen widget, an Apple Watch app, CarPlay, a keyboard extension or Live Activities, you'll write most of it natively anyway.
2. Advanced camera, audio or AR pipelines. Real-time video processing, custom audio engines or ARKit-heavy experiences sit close to the metal. React Native can host them, but the hard part is native code.
3. Only one platform matters. An iOS-only app for an iPhone-heavy market doesn't benefit much from cross-platform. SwiftUI alone may be simpler.
4. Your team is already native. If you have strong iOS and Android engineers, retraining them buys you little.
5. Games. Use Unity, Godot or a game framework. Neither React Native nor UIKit is the right tool.

When React Native is the right call

• You need both iOS and Android, and most of the app is screens, forms, lists, payments and data.
• You want features to land on both platforms at the same time.
• You have, or plan, a React or Next.js web app and want to share types, API clients and logic.
• You want to fix JavaScript bugs over the air instead of waiting for store review.
• You'd rather hire from the JavaScript and React talent pool.

That describes most marketplaces, booking apps, fintech apps, social apps, SaaS companions and internal tools.

The middle path most apps actually take

Cross-platform doesn't mean "no native code". A healthy React Native app calls native code wherever it's the best tool:

• Native modules in Swift and Kotlin for device features, SDKs without JavaScript wrappers, or performance-critical work. With the New Architecture, JavaScript calls them directly through JSI.
• Native UI components when a platform view does something special (a custom camera preview, a map, a chart drawn natively).
• App extensions like widgets or share extensions written natively and bundled with the React Native app.
• Brownfield: React Native screens embedded in an existing native app, so a native team can move faster on some features.

From the field: I write native modules in Swift and Kotlin when JavaScript alone won't do. For the SuraSole smart-insole app, real-time pressure data streams over Bluetooth Low Energy from both feet and renders as live heat maps at 60fps. That's the kind of app people assume must be native, and it's built with React Native.

The cost difference, roughly

For a typical app on both platforms, the main cost isn't the first build. It's maintaining two codebases for years.

Native isn't "twice the price" in every case, because some work (backend, design, product) is shared. But it's rarely close to the same price.

Already built one? How to change course

Choosing "wrong" isn't fatal, and the fix is rarely a rewrite from scratch.

You have two native apps and they're drifting apart. You don't need a big-bang migration. React Native can be embedded in an existing native app (brownfield), so you can build new features once in React Native and show them inside both native apps, screen by screen. The native code you already trust keeps running. Over a few releases, more of the app becomes shared.

You have a React Native app that needs a deep platform feature. Don't rewrite the app. Build that feature natively, as a native module, a native view or an app extension, and keep everything else shared. This is exactly what the New Architecture and the Expo Modules API are designed for.

You have a React Native app that feels slow. Before blaming the framework, profile it. When I cut load time by about 60% across eight apps, the wins came from Hermes, image optimisation and cache-first fetching, not from leaving React Native. Fixes like these take weeks. A native rewrite takes months and brings its own bugs.

Whichever direction you move, move incrementally: one screen or one feature per release, with crash reporting watching each step.

A quick decision guide

Answer honestly:

1. Is the core value a platform feature (widget, watch, AR, camera engine)? Native.
2. Is it a game? A game engine.
3. Is it one platform only, with no web app? Native is reasonable.
4. Both platforms, mostly screens and data, maybe a web app? React Native, with native modules where needed.

FAQ

Is React Native as fast as native?

For typical business apps, users can't tell the difference. React Native renders real native views, and the New Architecture calls native code directly without the old bridge. Native still wins for extreme cases like real-time video processing or 3D, which React Native apps usually handle with native modules anyway.

Can React Native apps use native Swift or Kotlin code?

Yes. Native modules let JavaScript call Swift and Kotlin directly, and native UI components let you embed platform views. Expo's Modules API makes writing them straightforward, and app extensions such as widgets can ship alongside a React Native app.

Should a startup build native or cross-platform first?

Most startups that need both iOS and Android should start cross-platform, because one codebase ships features to both at once and costs less to maintain. Go native first if your core value is a platform-specific feature or you're targeting a single platform.

Next steps

If you're weighing native against React Native for a real product, send me the core features and I'll give you a straight answer, including when that answer is "go native". Get in touch, or see how I work as a React Native developer.

Sources

• About the New Architecture, React Native docs
• Turbo Native Modules, React Native docs
• Expo Modules API overview, Expo
• React Native showcase, React Native