The floor: what you cannot avoid
Start here, because it is the only part of this article with exact numbers. To put an app in both stores you need two developer accounts:
- Apple Developer Program — $99 per year. Required to submit to the App Store at all, and it renews; let it lapse and your app is removed from sale.
- Google Play Console — $25, one time. Paid once per developer account, ever.
That is the real floor: about $124 in year one to be a publisher on both platforms. Everything else in the stack — build infrastructure, a backend, analytics, crash reporting, push notifications — has a free tier that comfortably covers an app before it has traction. A solo builder shipping their first app can genuinely reach both stores for close to the price of the accounts, and it is worth knowing that before you read anyone’s $30,000 starting estimate.
What actually drives the number
Cost tracks scope and ambiguity, not framework. Ranked by how much each one moves a real quote:
| Driver | Impact | Why |
|---|---|---|
| Screens with real logic | High | A list and a detail view are cheap; a booking flow with availability is not |
| Accounts and a backend | High | Auth, sync, permissions and a server to own — often the largest single line |
| Third-party integrations | High | Each one is an API, an edge case set, and a future breaking change |
| Payments or subscriptions | Medium | Store billing rules, restore flows, receipt validation, entitlement state |
| Custom design | Medium | A bespoke design system costs more to build and much more to maintain |
| Offline support | Medium | Conflict resolution is the expensive part, not local storage |
| iOS + Android vs one | Low–Medium | Shared code, but two test matrices and two review processes |
| React Native vs Flutter | Low | Hiring pool and existing team skills matter far more than the framework |
Notice what is at the bottom. Whether you build in React Native or Flutter is close to irrelevant to cost — it matters for hiring and for what your existing team already knows, which is a real consideration, but it is not a budget lever. If a quote changes materially based on the framework, the difference is that shop’s familiarity, not the technology. The framework comparison goes into what actually differs.
Four routes, and what each one buys
| Route | Money | Time to v1 | Fits when |
|---|---|---|---|
| Build it yourself with AI tooling | Developer accounts + a subscription or two | Days to a few weeks | Validating an idea, first version, founder who will keep iterating |
| Build it yourself, by hand | Developer accounts only | Weeks to months, depending on experience | You already write React, and the learning is part of the point |
| Freelance developer | Hourly or fixed bid; rate varies hugely by region | 1–3 months for a focused MVP | Clear scope, one accountable person, you can review the work |
| Agency | The high end, by a wide margin | 3–6 months plus contract time | Funded projects, compliance requirements, you need a team not a person |
Deliberately no dollar ranges in that table for the paid routes, because freelance and agency rates vary by an order of magnitude across regions and seniority — a number here would be a made-up anchor rather than information. Get three quotes on the same written brief; the spread between them tells you more about your brief than any published average will.
The one genuinely underrated option is the hybrid: build the first version yourself to establish exactly what the app is, then hire against a working artifact instead of a document. A developer quoting on something they can install and tap is quoting on facts, and the quote comes back lower and holds better, because most overruns are scope discovery rather than difficulty.
The costs nobody quotes
A build quote covers building. These arrive afterwards and continue indefinitely:
- Store commission. The platforms take a cut of in-app purchases and subscriptions. Rates depend on your revenue tier and programme enrolment, and both stores have changed their terms more than once — check the current rates for your situation rather than trusting a number in an article, this one included.
- Backend and infrastructure. Free at small scale, priced by usage after that. The step change usually arrives with growth, which is the good problem, but it does arrive.
- Maintenance. Two OS releases a year, SDK upgrades, dependency churn and store policy changes. 15–25% of the build cost per year is the common planning figure, weighted higher the more third-party services you depend on.
- Support. Reviews, refunds, bug reports, and the person who answers them. Cheap per incident, unbounded in aggregate, and almost never in a quote.
- Getting users. Routinely larger than the build. The app is the cheap part of having an app — worth internalising before deciding how much of the budget to spend on development at all.
This is the strongest argument for spending less on version one. Not because quality does not matter, but because the build is one line in a budget that keeps running, and money spent proving the idea is worth more than money spent polishing an idea nobody has validated.
Where React Native specifically saves money
The cross-platform saving is real, but it is worth being precise about which parts are shared and which are not, because that is what determines the actual discount versus building twice natively.
- Genuinely shared: screens, navigation, state, business logic, API layer, most of the design system. The bulk of an ordinary app.
- Partly shared: anything touching platform behaviour — permissions, notifications, background work, deep links. One implementation, two behaviours to verify.
- Not shared: store submission, review responses, device testing, and any native module you end up writing. Two of everything.
The larger saving is the one that does not appear in a build quote at all: for the next five years, one codebase, one release process, one team, one set of upgrades. That compounds in a way the initial discount does not.
The cheapest useful thing you can do next
Whatever route you take, the single highest-return move is turning the app in your head into something on a phone before anyone quotes on it. It resolves the ambiguity that inflates quotes, tells you which features you assumed you needed and do not, and is the difference between hiring against a document and hiring against a fact.
Describe the app in a sentence in ShipNative and get a real React Native app running on your own phone in minutes — screens, navigation, and the data model wired. Export the full Expo project whenever you want to hand it to a developer or keep going yourself. If you want a rough figure to argue with first, the app cost calculator estimates from your feature list.
Build it free
Describe your app in one sentence and have it running on your own phone in minutes at shipnative.dev. No credit card, full React Native source export whenever you want it.