React Native vs. native: which should you build?
React Native/Expo vs native Swift/Kotlin: a founder's decision guide. When cross-platform wins, when native earns its cost, and why you can mix.
What are React Native and native, exactly?
Native means building a separate app per platform with each platform's own tools: Swift (often with SwiftUI) for iOS, Kotlin for Android. Two codebases, ideally two areas of expertise, full access to everything the OS offers.
React Native is a framework that lets you write your app once in TypeScript and render it as a real native app on both platforms. Expo is the toolchain on top of it that handles builds, updates, and the common native APIs (camera, push, location, secure storage) so you're not wiring each one by hand. It's the same React mental model used on the web, which is why a single team can own web and mobile together.
A key point people miss: React Native isn't a web view in a wrapper. It drives the actual native UI components. The user is using a real app, not a website pretending to be one.
When is cross-platform the right call?
For the large majority of products we see, React Native/Expo is the better default. Choose it when:
- You need to launch on iOS and Android without doubling the build.
- Your app is mostly screens, forms, lists, auth, payments, and API calls — which describes most apps.
- You want one team and one codebase to maintain, so fixes and features ship to both platforms at once.
- Speed to market matters, and you'd rather get a real app in users' hands and iterate.
The maintenance math is the quiet reason this wins. Two native codebases means every feature, bug fix, and design tweak gets built twice, forever. One codebase is cheaper to evolve long after launch — and most of an app's life is after launch.
When does native earn its cost?
Native is the honest answer when the platform itself is the product. Reach for it when:
- The app is performance-critical in a way users feel: heavy 3D, real-time audio/video processing, high-frame-rate graphics, large-scale games.
- It depends on deep device and hardware features — advanced camera pipelines, Bluetooth peripherals, ARKit/ARCore, background sensors, complex offline sync.
- You want platform-perfect UX that follows each OS's latest design language and animations to the pixel.
- You're shipping a small, focused app for one platform only, where a second codebase was never on the table.
If that's you, native is a feature, not overhead. We won't talk you out of it.
React Native vs. native at a glance
| Factor | React Native / Expo | Native (Swift / Kotlin) |
|---|---|---|
| Codebases for iOS + Android | One | Two |
| Time to first launch | Faster | Slower |
| Long-term maintenance | Lower (one codebase) | Higher (built twice) |
| Raw performance ceiling | High, sufficient for most apps | Highest |
| Hardware / device-API depth | Strong, extendable via native modules | Complete |
| Team needed | One (shared with web) | iOS + Android skills |
| Best fit | Most products, MVPs, dual-platform apps | Performance- or hardware-heavy, single-platform |
Isn't it really either/or?
No — and this is the part that defuses most of the debate. React Native lets you write native modules: drop into Swift or Kotlin for the few screens or features that need raw native power, while the rest of the app stays in one shared codebase. So a fitness app can keep its whole UI in React Native and hand only the live-workout sensor loop to native code.
That's how we approach it. We build React Native/Expo with TypeScript by default, reach for native modules surgically, and go fully native when the product genuinely calls for it. Either way you own the full repository on delivery — no lock-in, your code and IP.
So which should you build?
Default to React Native/Expo unless your app is heavy on performance or hardware, or you're targeting a single platform. The cost difference shows up most in the years after launch, when one codebase is simply cheaper to keep alive.
If you're not sure where your app lands, that's a 30-minute conversation, not a guess. See mobile development, read own your code, or start a project and we'll tell you straight which way we'd build it.