React Native vs native vs PWA: what the choice means for your budget

Ask three developers and you will get three confident answers with genuine feeling behind them. That is not because one of them is wrong. It is because they are optimising for different things, and none of those things is usually your budget.

Translated into business terms, the React Native vs native vs PWA choice comes down to three questions: how much of the device you genuinely need, whether you must be in the app stores, and how many codebases you are prepared to maintain forever. Everything else follows.

React Native, native and PWA in plain terms

• Native means building twice, once for each platform, in the language each was designed for. Best performance, full access to everything the device can do, and two of everything to maintain.
• React Native, and its cross-platform equivalents, means one codebase producing real apps for both stores. Most of the device is available, performance is very good for ordinary business apps, and you maintain one thing with occasional platform-specific work.
• A PWA is your website, built well, installable to the home screen, working offline and able to send notifications. No stores, no review, instant updates, and the least access to the device.

What it means for money and time

What you actually give up with each

The honest limitations, since every option has them and suppliers tend to describe only the ones belonging to options they do not sell.

• A PWA cannot be found by browsing an app store, which matters less than people expect for a business whose customers already know them, and matters a great deal if store discovery is part of the plan.
• A PWA has limited background access. Location tracking while the app is closed, deep integration with the operating system, and some hardware are restricted or unavailable, and this is the genuine dividing line.
• React Native adds a layer, so the very smoothest animation and the most demanding graphics are harder. For a booking app, a portal, a field tool or an ordering app, nobody will notice. For a game or a camera-heavy product, they will.
• React Native depends on the ecosystem for access to newer device capabilities, which occasionally means waiting or writing a small piece of platform-specific code.
• Native costs you twice, forever. Every feature, every fix and every platform change happens in two places, and this is a permanent operating cost rather than a build decision.

How to decide in five minutes

1. Does it need the device in a serious way? Continuous background location, Bluetooth to hardware, heavy camera use, augmented reality. If yes, that rules out a PWA and often points at native.
2. Do you need to be in the stores? For discovery, for credibility with your customers, or because a client requires it. If no, a PWA is dramatically cheaper and faster.
3. Will people use it weekly? If not, they will not keep an app installed, and the store presence you paid for buys you nothing.
4. Is performance a product feature? Games and graphics-heavy tools, yes. Almost everything else, no, and believing otherwise is where budgets go.
5. Can you fund two codebases indefinitely? Not the build, the next five years. If the honest answer is no, native is a decision you will regret in year two.

For most business apps the answers are no, sometimes, yes, no, and no, which points at one shared codebase or at a PWA. That is not a fashionable answer and it is usually the right one. Do you need an app or a website is the prior question and worth settling first, because a good number of these projects should not be apps at all.

The hiring question nobody asks

A consideration that outlasts the technical one, and it is rarely raised at the decision.

Whatever you choose, somebody has to maintain it in three years, and that may not be whoever built it. A PWA is web development, so the pool of people who can work on it is enormous and includes whoever already looks after your website. A cross-platform app draws on a large and mainstream pool. Native draws on two smaller and more expensive ones, and you need both.

For a business without an in-house engineering team, that difference in the hiring pool is frequently a bigger long-term factor than any performance argument, and it points the same way as the cost.

What users notice, and what they do not

Worth separating from the engineering argument, because the things developers care about and the things customers complain about overlap less than you would expect.

• They notice how long it takes to open, every time. This is the most common real complaint and it is more about how the app is built than which technology built it. All three can be slow if nobody paid attention.
• They notice when a tap does nothing for half a second. Responsiveness matters and it is achievable in all three. The difference shows up in unusual cases rather than ordinary ones.
• They notice offline failure immediately and unforgivingly. Handled well or badly in any of the three, and it is a design decision rather than a platform one.
• They do not notice the framework. Nobody has ever left a review complaining about the rendering approach. They complain about being logged out, about not finding what they wanted, and about a form that lost their input.
• They do notice a phone getting warm and the battery dropping, which is usually about what the app does rather than how it was written.

The practical implication is that the money saved by choosing a shared codebase is better spent on the things above than on the platform difference. An app built carefully in the cheaper option beats one built carelessly in the expensive one, and that comparison is far more common than the technical debate suggests.

When native genuinely wins

So this is not one-sided, the cases where we would tell you to build twice and mean it:

• Games and anything graphics-heavy, where frame rate is the product.
• Deep hardware access: continuous scanning, specialist Bluetooth devices, augmented reality, sustained background tracking.
• The app is your entire business and small differences in polish are competitive rather than cosmetic.
• You already have native engineers, in which case the argument is settled by what your team can maintain.
• A platform capability the moment it launches, if being first genuinely matters to you.

If two or more of those apply, build natively and budget for two of everything indefinitely. That is customer apps work done properly rather than cheaply, and it is the right call for a small number of businesses.

You can change your mind, at a price

Since this decision feels permanent, it is worth knowing how reversible each direction actually is. It is not symmetric.

• PWA to a store app is the cheapest move, because the web application you built is the thing that gets published. That is why starting there is a low-risk decision: you can validate demand and add a store presence later without discarding the work.
• Cross-platform to native is a rewrite, though the design, the logic you have proven and everything you learned about your users carry over. Expensive but not starting again.
• Native to cross-platform is also a rewrite, and the one people are most reluctant to fund because the existing apps work. It usually happens only when maintaining two codebases has become visibly unaffordable.
• Anything to anything keeps your back end, which is frequently most of the value. The interface is the part being replaced, not the system underneath.

The practical consequence is a bias toward the cheaper option when the requirements are genuinely uncertain, because being wrong in that direction costs an upgrade while being wrong in the other costs a rewrite plus the two years of double maintenance you already paid for.

Not for you if

The question to put to any supplier: what would have to be true for the cheaper option to work here? A good answer is specific and names a capability. A vague answer about future-proofing or scale is a preference wearing a business argument, and you are entitled to ask which it is.