The question behind the question
Most teams asking "React Native or native?" are really asking something else: can we afford to build this twice? A fully native product means one codebase in Swift for iOS and another in Kotlin for Android, usually written by different people. Every feature, every bug fix and every design change is done two times.
Sometimes that is the right price to pay. Usually it is not.
What actually differs
| React Native | Fully native | |
|---|---|---|
| Codebases | One, in TypeScript | Two: Swift and Kotlin |
| Team | One team ships both platforms | Typically two specialist teams |
| Interface | Native components | Native components |
| Platform features | Through libraries or small native modules | Direct, from day one |
| Feature parity | iOS and Android ship together | Easy for one platform to fall behind |
The row people expect to see — "performance" — is missing on purpose. A React Native app draws real native views. For ordinary screens (lists, forms, navigation, media) users cannot tell which approach was used.
When React Native is the right call
- The app is mostly screens and data. Accounts, feeds, forms, payments, messaging, maps. This describes the large majority of apps.
- You need both stores at launch. One team delivering both platforms together is the main reason the approach exists.
- You already have a React web product. API clients, validation rules and types can be shared, and the same developers can work on both.
- You are testing an idea. An MVP should spend its budget on learning, not on duplicate implementations.
When to go fully native
- The app is the hardware. Heavy use of the camera pipeline, Bluetooth peripherals, AR, or on-device machine learning.
- Graphics are the product. Games and complex real-time animation belong in native code or a game engine.
- You only need one platform, and already have the people for it.
- You must adopt new OS features on release day. Native gets them first; cross-platform libraries follow.
The middle path most people miss
It is not all-or-nothing. A React Native app can include native modules written in Swift or Kotlin for the one or two features that need them, while everything else stays shared. It works the other way too: React Native can be added to an existing native app one screen at a time, which is often the least risky way to modernise.
How we decide
Three questions usually settle it:
- What is the hardest thing the app does? If the answer is "show data and take input", cross-platform is fine. If it is "process video in real time", look closer.
- Who maintains it in two years? One team or two — and can you hire for both?
- What does being late on one platform cost you?
For most products the answers point to React Native, which is why it is our default for mobile app development. When they do not, we say so before anyone writes code.
Working on something like this? See how we approach mobile app development.
