What React Native actually saves
Cross-platform changes the arithmetic on one line item and leaves the rest where they were. Here is the honest version of the math.
- $15K – $90K
- What most cross-platform projects cost
- 35%
- Less application development than two separate native apps
- $55 / hr
- Blended across design, engineering, QA, and management
The pitch for React Native is that you build once and ship twice. That is broadly true and routinely oversold. One codebase does mean one application to write, but application development is roughly a third of a typical project, and nothing else on the invoice cares how many codebases there are.
The saving is real and worth having. It is about 20% of the project, which is a long way from the half the pitch implies. Knowing which 20% is the difference between a plan that holds and a plan that discovers in week six that QA was budgeted as though there were one platform.
What cross-platform projects cost
These are the same ranges as any custom mobile work, because cross-platform is the baseline this calculator prices from. Going native and separate is priced as an addition on top of them.
$15,000 – $25,000
Focused first version
About 9–15 weeks
One workflow, one kind of user, a new backend, shipped to both stores from one codebase. The band a first release should be aiming at, and the one where the cross-platform decision pays back fastest.
$30,000 – $55,000
Production build
About 3–5 months
Several workflows, multiple user types, an admin application, and both platforms in the QA plan from day one instead of as an afterthought at the end.
$55,000 – $90,000
Complex build
About 4–6 months
Offline and sync, hardware, or a native module or two that has to be written and tested twice. React Native still helps here. It helps less, and the estimate should say so.
These are the three shapes of project that show up most often. Treat the boundaries as soft: work lands between the bands constantly, and a project can sit at the top on one dimension and the bottom on every other. The calculator prices the description you give it instead of sorting you into a box.
What shrinks
Application development is the line that moves, and it moves a lot. Building two separate native applications costs about 55% more in that workstream than one cross-platform codebase covering both platforms. Across the whole project, once design, backend, integrations, QA, and management are counted, going native and separate adds roughly 20%. More when the app itself is the bulk of the work. Less when it is a thin client over a large backend, where the platform decision barely registers.
- +55%
- Application development, if you build the two apps separately
- −35%
- The same decision read from the other end: one codebase against two
The second thing that shrinks is the one that compounds: maintenance. One codebase is one dependency tree, one set of upgrades, and one place a bug gets fixed. Over three years that difference is usually larger than the saving on the initial build, and it is almost never what people compare when they choose.
Worth stating plainly: the comparison that applies is React Native against two native apps, and there it wins. Against a single native app for a single platform it is a wash, because that is also one app to write.
What does not shrink at all
Cross-platform budgets go wrong in the same five places every time.
- Design
- You are still designing for two platforms. Navigation patterns, system typography, date pickers, share sheets, and the back button all differ, and an app that ignores that reads as foreign on at least one of them. A shared codebase gives you one implementation of a design; you still have to do the design. The design workstream in this model shrinks by zero hours when you pick one.
- QA
- One codebase, two device families, both of which have to be tested. Shared code behaves differently across platforms: permissions, keyboards, background execution, text rendering, and file handling all diverge. The test plan is therefore the union of both platforms. Budgeting half the QA because there is half the code is the most expensive mistake available here.
- Backend and integrations
- Identical, to the hour. The server has no idea what the client was written in, and the twenty-year-old ERP on the other end of the integration has even less of one.
- Store submission and release
- Two stores, two sets of metadata and screenshots, two review processes, two sets of rejection reasons, two release cadences. All of that happens once per store, however the app was built.
- Project management
- Scales with how long the project runs. A shorter project does cost less management, and that is the schedule paying off rather than the framework.
Where you still need native code
React Native’s escape hatch is the native module: platform code, written once per platform, called from JavaScript. Most non-trivial projects need at least one, and a good estimate says which ones out loud in week one rather than discovering them in week six.
Bluetooth and hardware peripherals. Connection lifecycle, pairing, permissions, and protocol handling behave differently enough on each platform that the abstraction leaks almost immediately.
Heavy graphics, augmented reality, and real-time video or audio processing, where the framework bridge is the bottleneck and the platform APIs are the point.
Deep operating system integration: home screen widgets, live activities, complex background location, share extensions, watch apps, and anything that runs when your app is not open.
Vendor SDKs that ship native only. Payment terminals, industrial scanners, and a lot of medical and industrial devices publish an iOS library and an Android library and nothing else.
The module itself is rarely the expensive part. The shape it creates is: a slice of work written, debugged, and tested twice, sitting inside a project budgeted as though everything happened once. Two native modules in an otherwise shared app can quietly consume most of the saving that justified the approach. Identify them during estimation and the arithmetic still works.
The honest limits
React Native is the wrong answer for a graphics-heavy game, for a product whose entire value is a platform-specific capability on the day it launches, for a team that has native engineers and no JavaScript ones, and for anything where you would spend the majority of the work fighting the framework rather than a corner of it.
It also carries an upgrade treadmill that native projects carry more gently. Framework releases are frequent and consequential, and a codebase left alone for two years has accumulated a migration. Budget an upgrade pass at least annually, in the same conversation as the OS releases, and it stays a routine cost. Skip it three years running and it becomes a project.
Flutter is the other serious option, and it makes a similar trade with a different set of edges and its own ecosystem. The choice between the two matters far less than the choice to go cross-platform at all, and it should usually be settled by which one the people maintaining the app can maintain.
Common questions about React Native cost
How much does a React Native app cost?
The same ranges as any custom mobile project: $15,000–$25,000 for a focused first version, $30,000–$55,000 for a production build with several workflows and an admin portal, and $55,000–$90,000 when hardware, offline operation, or regulated data are involved. Cross-platform is the baseline these numbers assume, so native-and-separate is priced as an addition on top of them.
Is React Native cheaper than native development?
Cheaper than building two native apps, yes: about 35% less in application development and roughly 15% less across the whole project. Against a single native app for a single platform it is a wash, since that is also one app to write. The larger saving is in maintenance, where one codebase means one dependency tree, one upgrade path, and one place each bug gets fixed.
Does a React Native app feel worse than a native one?
For ordinary business and consumer applications, a well-built React Native app is indistinguishable to users. The places it shows are heavy animation, complex list performance with very large datasets, and anything graphics-intensive. If your product is a game or a creative tool, the trade goes the other way.
Can I add a native feature later?
Yes. Native modules are a first-class part of the approach instead of a workaround, so Bluetooth, a vendor SDK, or a widget can be added to an existing app. The cost is that the module is written and tested once per platform, so identify it during estimation. Two unbudgeted native modules can consume most of the saving that justified cross-platform in the first place.
React Native or Flutter?
The difference between them is much smaller than the difference between either one and building twice. React Native reuses JavaScript and React skills and has an enormous library ecosystem; Flutter renders its own UI, which gives more consistency across platforms and less of the underlying system for free. Choose by which one your team, or the team maintaining it after launch, can work in.