WhatDrivesReactNativeAppDevelopmentCostin2026?

Everything on this page comes from building and shipping React Native apps, including real-time tracking work where background execution and native modules stop being a theoretical concern. What you won't find here is a price table. A number pulled off a web page is worthless until somebody has looked at what you are actually building, and the ranges you have already read were written to rank rather than to help you. What you will find is the mechanism, in enough detail that you can sanity-check any estimate you are holding, including one of ours.

Start from the claim that got you here. One codebase, two platforms, so roughly half the cost. The first half of that sentence is true and the second half does not follow from it. On an ordinary product the shared portion is large and the saving is real. The trouble is that the unshared portion is not spread evenly through the app, it is concentrated in exactly the features that make your product worth building. That is why two React Native apps with the same number of screens can differ threefold in effort, and why an estimate can look padded when it is simply honest about where your app touches the platform.

What Actually Gets Shared in a React Native Build, and What Does Not

This table is the whole argument of the page in one place. Work down the right-hand column and count how much of it your product needs. That count, not your screen count, is your budget.

Does React Native Itself Cost Anything to Use?

No. React Native is open source under the MIT licence. There is no licence fee, no per-seat charge and no revenue share, and the same is true of Expo's core tooling. People ask this often enough that it deserves a direct answer rather than a paragraph of throat-clearing, so there it is.

The layer around the framework is where the small recurring items live, and they are worth knowing about because they are yours rather than a development partner's. Apple runs a yearly Developer Program fee and Google a one-time Play Console registration, both paid directly by you. A handful of widely used libraries are commercially licensed, with reliable background geolocation the example most teams meet first, and that is a genuine line item on a tracking or delivery product. Managed build and update services bill by usage once you outgrow their free tier. None of this is large next to engineering effort. It's simply the part nobody mentions until the invoice arrives, and a dependency list is worth auditing for it before you commit.

Is a React Native App Really Half the Work of Two Native Apps?

Not half, but genuinely less, and the saving is real wherever the app is ordinary. On a typical product the large majority of the code is screens, navigation, forms, state, business logic and API calls, and every line of that is written once. If somebody has told you cross-platform is a false economy, they're wrong about that part.

Here is the part that gets left out. The unshared work is not sprinkled evenly across the app. It clusters precisely around the things that make your product distinctive. A note-taking app is almost entirely shared. A field-service app that scans equipment over Bluetooth, keeps working in a basement with no signal and tracks a vehicle in the background is shared for the screens and close to full price twice for everything that matters. Both are React Native. They're not remotely the same project.

So when the estimate comes back higher than the half you expected, the useful question is not whether you are being padded. It is which line items sit in the right-hand column of that table above, and whether each one truly has to be there. That's a conversation an honest partner will happily have with you, and one a padded estimate can't survive.

What Actually Drives a React Native App's Cost?

Six factors, in rough order of how hard they move the number. Screen count is not among them, which is the first thing worth internalising if you're comparing quotes.

• The native module surface. How many capabilities need platform code nobody has already wrapped well. This is the biggest single swing factor and the one most often discovered late.
• The Expo decision. Managed or bare. It sets whether build, release and update infrastructure is something you configure or something you own and maintain.
• Whether the New Architecture is behind you or ahead of you. Irrelevant on a new build in 2026 and occasionally decisive on an inherited one, depending entirely on the dependency tree.
• Offline and sync. The most underestimated requirement in mobile. Reading cached data offline is modest work. Editing offline and reconciling conflicts when two people changed the same record is a distributed systems problem wearing a mobile app costume.
• The release and update process. Two of everything after the code is written, plus an over-the-air pipeline that stopped being free infrastructure in 2025.
• The Android device floor. Not the count of devices, the worst one you have promised to support. A low-end handset with little memory and an aggressive battery manager is where optimistic timelines go to die.

Timeline tracks the same six. A straightforward app over an existing API is 6 to 10 weeks with two engineers. Offline sync, payments and a couple of native integrations puts you at 3 to 5 months. Hardware access, background work or heavy real-time data is 5 to 8 months with a full team including QA. The sections below take the ones that cause the most surprise and explain the mechanism, so you can price your own build rather than trusting anyone's table.

When Do You Have to Write a Native Module, and What Changes When You Do?

You need one when the app requires a platform capability that no existing library wraps well enough to trust in production. The usual triggers are Bluetooth Low Energy against a specific piece of hardware, a payment or identity SDK the vendor ships only as native code, background location that has to survive the operating system deciding to reclaim memory, health and fitness data, camera work past the point of taking a photograph, and anything over USB or NFC.

When it happens, three things change at once. Someone writes Swift and someone writes Kotlin, so you are paying for platform expertise you may have hired React Native specifically to avoid. You take on the bridging layer between that native code and your JavaScript, which is where the subtle bugs live because it is the seam between two memory models. And you own that module for the life of the app, against two operating systems that each ship a major version every year.

The expensive version of this story is always the same. The requirement is not identified during scoping, the architecture is set on the assumption it is not needed, and it surfaces in month four when a stakeholder asks why the app stops recording when the screen locks. By then the fix is not writing a module, it is writing a module and unpicking the four months of decisions that assumed you would never need one. Ask the question at scoping. It costs an hour and it's the highest-return hour in the project.

For context on what this looks like at the serious end, Geminate Solutions has shipped a fleet platform tracking more than 30,000 vehicles, where background location and battery behaviour are the product rather than a detail of it. Read the fleet tracking case study if you want the shape of that work.

Should You Build on Expo or the Bare React Native CLI?

Start with Expo unless you already know a specific reason you cannot. The managed workflow gives you builds, over-the-air updates, push notifications and a large library of vetted modules without anyone opening Xcode or fighting Gradle. For most products that represents weeks of setup you simply never pay for, and weeks you never pay for again each time the tooling changes underneath you.

The legitimate reasons to go bare, or to run a prebuild with config plugins, are narrow and concrete. A native dependency the managed workflow does not support. A build step you have to control yourself for compliance or for an internal distribution channel. A native module you are writing anyway, which changes the calculation because you are already in that world.

The expensive path is the one nobody decides on purpose. A developer picks bare in week one because it feels more professional, or because a tutorial did, and the project inherits build infrastructure, signing configuration and an update pipeline that it now maintains forever. Nobody costs that decision because it never appears as a line item. It just shows up later as a release process that takes a day instead of an hour. Make the call deliberately, write down the reason, and revisit it only when something concrete forces you to. If you want the longer version of this argument, we wrote it up in taking an Expo app to production.

What Does the New Architecture Migration Add to an Existing App?

On a new build in 2026, nothing at all. The New Architecture has been the default since React Native 0.76 in October 2024, and the legacy bridge has since been removed outright rather than merely deprecated. If you're starting today you're already on it and there's no migration to budget for.

On an inherited app the cost is real, and here's the thing worth understanding: it is almost never in your own code. Application code mostly moves across untouched. The cost is in the dependency list. Every native library still written against the old bridge has to be upgraded, replaced, or maintained by you, and which of those three it is depends entirely on whether anyone upstream is still looking after it.

That produces two wildly different projects wearing the same name. A well-kept app on popular, maintained dependencies moves in days. An app carrying two or three abandoned native libraries is not migrating at all, it is adopting and rewriting somebody else's unmaintained module, and that is open-ended work by nature. The audit that tells you which one you have takes a few hours. Nobody should quote you a date for this migration before doing it, and if someone has, that's the first question to ask them.

Can You Ship Updates Without Going Through the App Stores?

Yes for JavaScript, no for native, and the ground moved here recently enough that plenty of estimates are still quietly wrong about it. Over-the-air updating pushes new JavaScript directly to installed apps, which covers most bug fixes, copy changes and small features, and turns a week of waiting into minutes. Anything touching native code, a new permission or an upgraded native dependency still needs a full store release.

The detail that matters for a 2026 budget is that this stopped being free plumbing. Microsoft retired App Center on 31 March 2025 and the hosted CodePush service went with it, and the open-source server repository is archived rather than maintained. Teams now run Expo's EAS Update, which works in bare React Native too, self-host something, or move to a smaller hosted provider. All three are workable and none of them is the free default that older guides assume.

Two practical consequences for planning. If you inherited an app whose release process was built on hosted CodePush, that migration is already overdue and belongs in your scope rather than in a footnote. And if your estimate assumes free over-the-air updates without naming which service provides them, it was written against a world that ended in March 2025 and is worth a second look.

What Does App Store Review Actually Cost You?

Schedule, not engineering, and the distinction matters because schedule is the thing you promised somebody. Review is usually quick now and often lands within a day. The average is not the problem. The variance is, because a rejection resets the clock at the least convenient possible moment, which is generally the week you told the board it would be live.

Two platforms means two binaries, two signing and provisioning chains, two sets of store metadata and screenshots, and two independent review queues that are perfectly free to disagree with each other. None of that is difficult work. All of it is work, and it is invisible on a wireframe, which is why it is missing from most estimates.

The planning rule is simple. Engineering finishing on a Tuesday does not mean users have it on Tuesday. Teams that prepare store assets early and give one person the release checklist lose very little time here. Teams that discover the requirements in launch week lose days, and they lose them in public.

Which Devices Do You Actually Have to Test On?

The code is shared. The device matrix is not. This is where cross-platform savings quietly leak back out, and it's the line item that gets cut first because it looks like overhead rather than engineering.

iOS is narrow and predictable. A current phone, an older supported one, and a tablet if you've claimed tablet support, covers most of what you need. Android is the actual work, because you are not testing one platform but a span of screen sizes, memory ceilings, manufacturer skins and battery managers that will terminate your background tasks with considerable enthusiasm and no warning.

One rule saves more money than any other here. Buy the worst Android phone you have promised to support and test on it weekly from the first sprint, not the last. An emulator on a developer laptop with plenty of memory will never show you the jank, the out-of-memory kill or the background task that silently stopped running. Real hardware finds those in week two, when fixing them is ordinary work rather than an emergency.

What Does It Cost to Keep a React Native App Alive After Launch?

More than a web app of comparable size, for a reason that has nothing to do with React Native being fragile. Two platforms move underneath you on a schedule you do not control. iOS and Android each ship a major version every year, each raises the minimum SDK level the stores will accept for new submissions, and each occasionally breaks a native dependency you rely on. React Native itself releases frequently. Certificates and provisioning profiles expire on their own timetable.

The planning assumption that survives contact with reality is a standing annual allowance expressed as a percentage of the original build effort, plus one deliberate upgrade window booked in the calendar every year. The allowance covers the ordinary flow of fixes and small features. The upgrade window covers the platform moving.

Skipping the upgrade window does not save the work. It defers it and charges interest. A single-version jump is a routine week. A three-version jump, forced on you by a store deadline, is a month of archaeology through breaking changes in libraries whose maintainers moved on two years ago. We have been called in for both. The first is a maintenance task. The second is a rescue.

Who Should Not Build in React Native?

Plenty of people, and saying so costs us nothing, because the projects below would go badly and a bad project is worse for us than no project.

• Your product is one long native interaction. A serious camera app, a real-time audio tool, a 3D game, or anything that needs the newest platform APIs the week they ship. Build native. You'll spend the cross-platform saving on fighting the abstraction and then some.
• Your app is genuinely a website in a shell. No offline requirement, no push, no hardware access. A progressive web app may be all you need, and it ships without a review queue.
• You are one developer who already knows Swift or Kotlin well and only ever intend to ship one platform. Your existing fluency is worth more than the theoretical saving. Use it.
• You have no users yet and no validated demand. This is the one we say most often. A web app you can change hourly beats a mobile app gated behind store review while the product is still changing shape every week. Get to the point where people are asking for the app, then build the app.

If you are weighing this against Flutter rather than against native, that is a different comparison and we have written it out honestly in Flutter versus React Native and in native versus cross-platform.

Where Do Companies Waste Money on React Native Development?

Five patterns, all of which we have been brought in to clean up rather than read about.

• Finding the native module requirement in month four. Covered above, and it remains the most expensive mistake available on a React Native project, because you pay for the module and for unpicking the architecture built around not needing one.
• Choosing bare for no stated reason. Paying to own build, signing and update infrastructure that the managed workflow would have handed you configured.
• Hand-rolling offline sync. Conflict resolution feels bespoke and almost never is. Mature libraries have solved the ninety percent case and you will not beat them on a product timeline.
• Deferring the annual upgrade until a store deadline forces it. Converts a planned week into an emergency month, reliably.
• Designing for iOS and retrofitting Android. A designer delivers iOS mockups, the Android build is bent to fit them, and you pay twice for the parts where the conventions genuinely differ. Design both up front, even roughly.

How Do You Get an Accurate React Native Estimate?

Answer these five before anybody quotes you anything. They're the questions we ask, and you're welcome to take them to whoever else you are talking to.

1. Which capabilities touch hardware or a platform SDK, and does a maintained library already wrap each one? This single question moves the number more than the rest combined.
2. Does the app work offline, and if so, does data sync back and can two people edit the same record? Read-only offline is modest. Bidirectional sync with conflicts is a different project.
3. New build or inherited codebase? If inherited, what is in the dependency tree and is the New Architecture already in place.
4. How often do you intend to release, and does that need over-the-air updating? If yes, name the service, because it is no longer free by default.
5. What is the Android device floor for your actual users? Not the devices you own. The worst device your users have.

An estimate produced without those five answers is a guess with a number attached to it. If someone quotes you before asking them, you've learned something useful about how the rest of the project will go.

React Native App Cost: Frequently Asked Questions

The questions we are asked most often when scoping a React Native build, answered the same way we would answer them on a call.