Every mobile engagement starts with this question and most of the writing about it is useless, because it is either written by someone selling a framework or it compares a hello world app.
We have shipped fourteen production mobile apps in the last four years, eight cross platform and six native. This is what the data says, with the caveat that it is our data from our projects and your workload may differ.
The honest summary
For apps that are mostly forms, lists, API calls and navigation, React Native costs roughly sixty percent of two native builds and ships about six weeks sooner. That covers a large share of business software.
For apps that lean on camera, Bluetooth, background location, real time audio or video, or complex gesture driven interfaces, the cross platform saving disappears entirely, and on two of our projects it went negative.
The interesting part is where the line sits and how to tell which side you are on before you commit.
What the projects actually cost
Six comparable projects, normalised to engineer weeks for a first production release with roughly equivalent scope.
| Project | Approach | Eng weeks | Notes |
|---|---|---|---|
| Field service app | React Native | 34 | Forms, offline sync, photo capture |
| Patient portal | React Native | 28 | Auth, appointments, documents, messaging |
| Fleet driver app | React Native | 61 | Background location was 40% of total effort |
| Retail loyalty | Native, both | 52 | 26 iOS, 26 Android |
| Warehouse scanner | Native, both | 44 | Deep camera and Bluetooth scanner integration |
| Wealth dashboard | React Native | 26 | Charts, read heavy, no device integration |
Three of the cross platform builds landed clearly ahead. The fleet driver app is the cautionary one, and it is worth spending time on.
Where cross platform stopped paying
The fleet driver app needed continuous background location while the driver was on shift, surviving app termination, with battery drain low enough that a ten hour shift did not flatten the phone.
Background execution is the area where iOS and Android are most different from each other, most restrictive, and most prone to changing between OS versions. React Native does not have a good abstraction over that, because there is not a good abstraction to have. The platforms genuinely behave differently and the differences are the point.
What happened: we wrote a custom native module for iOS in Swift, a custom native module for Android in Kotlin, and a JavaScript bridge to coordinate them. That is two native implementations plus an integration layer, which is more work than two native apps, not less. Then we spent three weeks on battery optimisation that required profiling in Xcode Instruments and Android Studio anyway, so the team needed native tooling skill regardless.
Retrospectively, that app should have been native. We said so in the retrospective and we say so to clients now.
The four conditions that push you native
We use these as a checklist during the architecture sprint. Two or more and we recommend native.
Sustained background execution. Location tracking, health data collection, audio processing while backgrounded. The platform APIs diverge sharply and there is no useful common denominator.
Deep hardware integration. Bluetooth Low Energy with custom peripherals, camera work beyond taking a photo, NFC, secure enclave key operations, external accessory protocols. Every one of these means writing a native module, which means paying the native cost plus the bridge cost.
Sixty frames per second on complex interaction. Custom gesture driven interfaces, real time drawing, interactive maps with thousands of markers, animation tied to scroll position. The new React Native architecture has closed much of this gap, but the ceiling is still lower and the debugging is harder.
A regulated review process you cannot risk. Medical device companion apps and certain financial applications go through review cycles where an unexpected framework behaviour costs you weeks. Native is more predictable under that kind of scrutiny.
Conversely, if none of those apply, cross platform is usually the correct commercial decision and the argument against it is often aesthetic rather than financial.
Performance, measured
On a Pixel 6a and an iPhone SE second generation, both mid range devices that represent a large slice of real users better than a current flagship does.
| Metric | React Native | Native | Difference |
|---|---|---|---|
| Cold start to interactive | 1.9s | 1.2s | +0.7s |
| Warm start | 0.6s | 0.4s | +0.2s |
| Scroll, 500 item list | 58 fps | 60 fps | negligible |
| Scroll, complex cards with images | 47 fps | 59 fps | noticeable |
| Memory, steady state | 142 MB | 98 MB | +45% |
| Install size, Android | 24 MB | 11 MB | +13 MB |
Cold start is the number users feel and it is the honest cost of cross platform. Seven hundred milliseconds is perceptible. Whether it matters depends on how often people open your app, which is a product question rather than a technical one. For an app opened twice a day it is irrelevant. For one opened forty times a day by a warehouse picker, it is a real productivity cost.
The complex scroll number is the one that surprises teams. Simple lists are fine. Lists of cards with images, badges and multiple text styles are where the gap shows, and that is exactly the design most product teams want.
Flutter, briefly
We have shipped two Flutter apps and it is a good framework. The rendering approach means the scroll performance gap largely disappears, and the tooling is genuinely excellent.
We recommend it less often than React Native for one commercial reason: hiring. In our market and in most of our clients' markets, the pool of engineers who can maintain a React Native codebase is several times larger than the Dart pool. When we hand a project over, the client's ability to staff it matters more than a few frames per second.
If your team already writes Dart, that reasoning inverts and Flutter is the better choice.
What we recommend by default
Start cross platform if your app is primarily CRUD over an API, you need both platforms at once, your team already writes TypeScript, and none of the four native conditions apply. This describes most B2B mobile work.
Start native if two or more of the native conditions apply, or if one platform is clearly dominant for your users and you can sequence the second one later. A great iOS app followed by a great Android app six months later often beats two mediocre ones at once.
Consider a hybrid where the shell, navigation and standard screens are cross platform and one or two demanding features are native modules. This works when the demanding surface is small and well bounded. It works badly when it is diffuse, because you end up maintaining three codebases with unclear ownership.
The question that actually decides it
Not "which is better" but "what does the second year cost".
A cross platform app with three custom native modules needs a team that can maintain JavaScript, Swift, Kotlin and the bridges between them. That is a broader skill requirement than two native apps, not a narrower one. Teams underestimate this because the first release does not expose it. The second year does, usually the first time an OS update breaks a module and nobody currently employed wrote it.
Count the native modules you expect to need. If it is zero or one, cross platform saves you real money. If it is four or more, you have chosen native without noticing, and it is cheaper to choose it deliberately.