What affects React Native app development cost at each stage?

A React Native app costs between $20,000 and $200,000, and the range is that wide because scope sets the price, not the framework. A single-role build that tests one hypothesis starts at $20,000 and ships in 4 to 6 weeks. A product with several user roles, an operator dashboard, and its own integrations runs $80,000 to $200,000. This article follows a project from analysis to maintenance and shows which decisions move you from one band to the next.

We have shipped 20+ React Native apps since 2020, and the cost drivers below are the ones that keep coming up on those projects.

How much does a React Native app cost?

These are the three scopes we build most often. Design, tech stack, testing, and launch work the same way in all three; what changes is how much product you get.

Development is billed at $50 per hour, which is why these are scope estimates and not sealed packages. You can check the starting prices for cross-platform app development and every other service on our pricing page.

What an hourly rate does and does not tell you

Rates for React Native developers vary widely by region, and comparing them directly is the most reliable way to misjudge a budget. Two things make the comparison unfair. First, a rate is not always the same unit: some vendors quote a developer, others quote a team that already includes a lead, a project manager and QA, and the second number looks worse while covering more of the work. Ask what roles the rate contains before comparing it with anything. Second, the rate multiplies hours you cannot see from the outside. A team that has built the same feature before spends fewer hours on it, so a higher rate over a shorter estimate regularly lands below a lower rate over a longer one, and only the total tells you which happened.

This is why we publish scope prices rather than a rate card as the headline. Our development rate is $50 per hour and it includes the review chain and the release work described further down, not a lone developer billing hours. When you collect quotes, compare the total for the same written scope, and ask each vendor which parts of their estimate are fixed and which are hourly. If two quotes differ by more than a third, look at the hours and the scope behind them before you blame the rate. A regional rate gap can account for the whole difference on its own, and so can an estimate that assumes twice the work without saying so.

Why one React Native app costs less than two native ones

One React Native team ships iOS and Android from a single TypeScript codebase, so you pay for one product instead of two. Four things drive the saving.

• One team, one codebase. There is no separate Kotlin team for Android and Swift team for iOS, and no third group reconciling the two feature sets once they drift apart.
• A library ecosystem that has settled down. Maps, payments, push notifications, and camera access are configuration work now rather than research projects. React Native's New Architecture has been the default since version 0.76, and version 0.82 was the first release running entirely on it, so the ecosystem is no longer split between two ways of doing the same thing.
• Code you already own. If you run a React web product, validation rules, API clients, and business logic often move across with light edits. The screens get rebuilt; the reasoning underneath does not.
• Over-the-air updates. With Expo you can publish a compatible JavaScript fix without waiting for a new store review, so a bug found on Tuesday can be gone on Tuesday instead of next week.

“Founders ask me what an app costs, and my honest answer is that they choose the number themselves. Two flows and one user role land at the bottom of our range. Add a second app for couriers and an admin panel, and the product has tripled without anyone deciding to triple it. Work out what the first release has to prove, then buy exactly that.”

Roman Surikov, CEO at Ronas IT

What affects React Native app development cost at each stage

Every stage has its own cost drivers, and they are not equally dangerous. The stages below run in the order we work through them.

Analysis: an unwritten scope is the most expensive line item

The biggest cost risk on a React Native project is not the feature list. It is a team and a client picturing different products. Rework after the design is approved costs far more than the same work would have cost before it, and it almost always traces back to requirements nobody wrote down.

To avoid that, three things have to happen before anyone opens a code editor.

• Understand the business behind the request. What the company sells, how it operates today, and what job the app does inside that workflow.
• Break the product into flows and prioritize them. A written list of what the first release includes and, more usefully, what it leaves out.
• Estimate against that list. Design gets a firm number first; development gets a range until the interface is approved, then a firm number.

Our productized version of this is the analysis phase: $2,000 to $3,000 and 1 to 2 weeks, ending in user stories, flow maps, risk notes, and a detailed project estimate. The output is portable, so you can build with us or take it to another vendor. Our guide to the discovery phase in software development walks through what happens inside the stage.

Design: starts at $8,000

Interface design for a React Native app starts at $8,000 and 2 weeks, and a full MVP interface usually needs more than that floor. It costs less than design for two native apps because there is one interface to draw rather than two, and you finish the stage with mockups, a clickable prototype, and a UI kit the design can scale on.

The stage gets longer as soon as you ask for any of this.

• Extra screen formats. Tablets and landscape orientation each need their own layout, so supporting them is separate design work and not a setting.
• Per-platform behavior. iOS and Android share one design system, but we adapt navigation, gestures, controls, safe areas, and permission dialogs for each platform. The more of the product that has to feel native on both, the more passes the screens take.
• Every state a screen can be in. Empty, loading, error, offline, and permission-denied screens are separate frames, so one screen in the estimate usually becomes several frames in Figma. If the designer skips them, developers invent them mid-sprint.
• Languages that change the layout. Every extra language needs room for longer strings, and Arabic or Hebrew mirrors the interface: navigation, icons, and reading direction all flip. Each of those needs its own pass over the screens.
• Animation. Motion that guides users has to be designed and engineered together, or the designer draws something that costs far more to build than it looks like it should.
• Custom illustrations. Onboarding and empty states look far better with them, and each one is drawn by hand.

Dark mode is the one founders expect to see on that list. We build screens on Figma variables, so a second color scheme comes out of the same design system instead of a second pass over every screen.

Development: the largest share of the budget

What a feature costs comes down to one question: does React Native already have a solution for it, or do we write one? The table below groups the features we are asked about most by that answer.

The Lainappi rental marketplace app shows how quickly this adds up on a small product. Its chat carries the whole rental: system notifications, the payment notice, and the action that lets a renter collect the item. Item owners are verified through Stripe Connect before they can take payments, and an availability calendar lets them mark months of dates at once. That is three integrations, a chat that behaves like a workflow, and a calendar well past a standard date picker, and none of it comes out of a component library.

There is a third answer between “a library exists” and “we write it”, and it is the one that surprises first-time owners: a library exists, and making it work on both platforms is its own piece of work. Because we generate the native projects from configuration rather than committing them, that work takes the shape of Expo config plugins. On one fintech app we maintain there are fourteen of them. Some are platform details that no library ships for you, such as Android manifest entries, a notification service, navigation bar colour and the app's behaviour under forced dark mode. The rest wire in native SDKs for card payments, bank account linking, identity verification and fraud scoring. Every one of those plugins is a small, testable file rather than a hand-edited Android project, which is the reason the next framework upgrade does not undo them.

“When a feature costs more than a founder expects, it is usually because the platform gives us nothing to start from. A payment library is a day of configuration. A custom native module is Swift plus Kotlin plus a JavaScript layer, tested on both, and maintained through every OS release after that. We flag those during analysis, because the honest answer is often to drop the feature from the first release rather than pay for it twice.”

Evgeny Leonov, CTO at Ronas IT

Release: cheap in fees, expensive in surprises

Store accounts cost 99 USD a year for the Apple Developer Program and a one-time $25 for a Google Play developer account. What costs money is a rejection, because it spends a release cycle and sometimes a piece of the build.

A rejection also rarely arrives for the reason you prepared for. In September 2021, review held the OddsCrowd iOS build with a single sentence: an app that offers a third-party login has to offer Sign in with Apple as an equivalent option. Nothing was broken and no rule about betting content was involved. We shipped the change and the app was through in three days, and the awkward part was not the work. The Android build had already passed its own review, so the fix had to reach iOS without pushing a new Android version and starting that clock again. One codebase does not mean one release: the two stores keep separate queues, and a plan that treats them as a single event will lose a week somewhere.

Regulated categories are where this bites. Finance, health, and gambling apps carry extra rules about who may publish them and what has to be disclosed inside the app, and learning those rules after the interface is finished is the expensive way to learn them. Reading the store requirements for your category during analysis costs nothing.

Regulated apps also carry hardening work that a consumer app can skip, and it belongs in the budget rather than on a checklist at the end. Tokens and credentials move out of ordinary storage into the iOS Keychain and, on Android, into storage encrypted with a key that never leaves the Keystore. The app pins the certificates of the APIs it trusts, so ordinary proxy interception fails. Builds that handle money also check whether the device has been rooted or jailbroken. Both checks raise the cost of an attack without ending it: on a device the attacker fully controls, the pinned certificate and the root check can both be patched out, so treat them as layers of defence. None of this is a large piece of work on its own, and all of it is cheaper to design in than to add later: retrofitting certificate pinning into a released app means an update every user has to install, and from then on every certificate rotation has to be coordinated with your release schedule. Banks and insurers often ask for an external penetration test before launch as well, and that arrives as a third-party invoice on top of the build.

A fixed external date changes the price too. The client behind the OddsCrowd app for sports bettors asked us for a mobile app 10 weeks before the Super Bowl, which turned the brief into a scaling problem: build something robust and easy to scale, in a window that could not move. When the date is fixed, either scope gives or the team grows. Our urgent MVP track starts at $45,000 and 6 weeks, with an expanded team and the full feature set, so we compress the calendar before we touch the scope. If you do have room to plan, our note on how long app development takes gives realistic windows by scope.

Maintenance: the cost first-time owners forget

React Native ships a new version every few months, and iOS and Android each get a major release every autumn. Post-launch spending has three sources.

• Staying current. Moving up one React Native release is routine work. Catching up across four, especially across the switch to the new architecture, is a project of its own.
• Every platform you support. Each one has its own release, review, and QA pass, so Android TV or tvOS is a small addition once and a recurring line afterwards.
• Rules that change under you. Store policies and privacy requirements move, and an app that ignores them stops being publishable.

Staying current is not only a bill. Some of those releases hand you performance you would otherwise have paid an engineer to find: React Native 0.84 made Hermes V1 the default engine on both platforms and shipped precompiled iOS binaries, which cuts the build time your team pays for on every release. An app three years behind gets none of that and pays for the optimisation by hand.

Two numbers are worth watching for the same reason, because both quietly raise cost later. Download size decides how many people finish installing your app, and it grows every time a dependency is added and never removed. Track the figure the stores report, in App Store Connect and the Play Console: native code, bundled assets, per-architecture builds and store compression all sit outside the JavaScript bundle. Expo Atlas covers the JavaScript side of that number. It shows which package is responsible, so removing weight there is a decision rather than a guess. Startup time is the other: it is the first thing a user experiences and the last thing anyone budgets for, and it degrades gradually as the JavaScript loaded before the first screen grows. Neither shows up in a feature list, and both are cheaper to hold steady than to recover.

Post-launch support starts at $1,000 per month, or you can work on time and materials at $50 per hour. Our overview of mobile app maintenance services covers what a support contract normally includes.

Where AI lowers the price, and where it does not

Our development estimates now carry two columns: the standard price and an AI-assisted price. We quote the AI-assisted number, and the split shows which work the discount applies to.

• Endpoints and admin screens that follow a pattern. CRUD APIs, search and filters, list views, an admin back-office for your ops team. The shape of that code repeats across projects, so an engineer prompts, reviews, and tests instead of typing it out. This is the biggest single cut we quote: about a quarter off the API line.
• Screens built against an approved design. Once the design system and the UI kit exist, laying out screens is mechanical enough to draft with AI. On our most recent MVP estimate that took 14% off the mobile app line.
• Localization plumbing and marketing pages. String extraction, right-to-left wiring, a landing page next to the app: same mechanism, 10 to 16% off.

Three kinds of work carry the same price in both columns.

• Payments and third-party SDKs. A payment gateway, an auth provider, a maps SDK: the behavior comes from the vendor, and getting it wrong costs your users money. We write and review those lines the slow way.
• Anything safety-critical. An SOS button or a geofence alert has to work when someone is in trouble. We do not discount that code.
• Infrastructure, release and handover. Environment setup, store submission, and the documentation you inherit depend on judgment and process rather than typing speed.

Design has no AI column, and our designers use AI every working day. It changes what they can consider rather than how many screens they draw.

• Reading a new domain quickly. Before drawing screens for insurance claims or logistics dispatch, a designer has to understand the workflow. AI shortens that reading and the review of competing products, and the designer still checks the conclusions with your team.
• A sparring partner for the solution. Arguing a flow through with a model, and generating rough variants to reject, is cheap. A designer can throw away five layouts before hand-building the one that goes into the UI kit.
• A first-pass reviewer. Screens go through an AI check against the design system and accessibility rules, contrast, tap-target sizes, and missing states, before a second designer reviews them. The dull mistakes surface early.
• Assets and interface copy. Illustrations, placeholder imagery, and first drafts of button, empty-state and error text start with AI, then the designer who owns the screen edits them.

None of that removes drawing hours. It widens the set of options a designer considers and catches mistakes earlier, which is why the design price is the same in both columns.

Across a whole recent MVP estimate the AI-assisted column took about 10% off the development budget. That is less than the “AI builds your app” pitch promises, because the parts that break in production are still ours to write.

Send us a few lines about the product and the flows it needs, and we will come back with a range, a timeline, and both prices.

Get a rough estimate

When React Native is not the cheaper option

We are a React Native team, and we still tell some founders to build native. React Native stops paying for itself in three situations.

• The product is iPhone-only and will stay that way. With no Android ever in the plan, you are paying for cross-platform machinery you will not use. Native iOS development starts at $25,000 and 8 weeks.
• The device is the product. Continuous camera processing, AR, custom audio pipelines, and anything doing heavy work on the GPU live in native code anyway, so React Native adds a layer without removing one.
• You already run two healthy native teams. Consolidation pays off when the codebases are drifting apart or one team is a hiring problem. If neither is true, a migration is a cost with no matching saving.

If your product sits in one of those, we would rather say so on the first call than after you have paid for an estimate.

How we estimate a React Native project

You get two numbers, in this order.

• A free rough estimate. Send four lines about what you want to build and a range with a timeline comes back within 24 hours. It is enough to tell whether we are in the same ballpark.
• A paid analysis phase. The $2,000 to $3,000 stage described above, which ends in a scoped estimate. The second number is sharper and more reliable than the first, because it prices a written scope instead of a description.

The analysis phase usually pays for itself, since the rework it prevents costs more than the phase does. Our walkthrough of how we estimate mobile app development shows what goes into the numbers, and our React Native app development page lists what each scope includes.

What to do next

Six decisions do most of the work of keeping a React Native budget under control.

1. Write down the one thing the first release has to prove. Then cut every flow that does not serve it. This single decision is what moves a project between the $20,000 and $80,000 bands.
2. Choose the band before the feature list. Decide whether you are buying a validation build or a market-ready product, and shape the scope to fit the number instead of discovering the number at the end.
3. Approve the design before asking for a firm development price. An estimate against approved screens is the first one worth planning around.
4. Treat a custom native module as its own decision. Anything the platform does not already provide gets written twice and maintained forever, so it deserves a separate yes or no.
5. Budget maintenance from day one. Support from $1,000 a month is cheaper than the upgrade project you inherit from ignoring four React Native releases.
6. Ask for the AI-assisted column. Our development estimates come with one, and comparing the two columns tells you which parts of your product are pattern work and which are the careful, expensive ones.

If you are weighing a mobile release against a web one for a retail product, our piece on React Native ecommerce app development works through the same trade-offs with a storefront in mind.

Tell us what the first release has to prove and what you can spend, and we will tell you which scope fits.

Get a project estimate