The only honest number in this entire conversation is $99. That is what Apple charges per year for the Apple Developer Program, and it is the price of the thing the question literally asks about: getting an app onto the App Store. One account, unlimited apps, renew every twelve months or Apple pulls your listing. Everything else you have read about the cost of making an app is answering a different question than the one it pretends to answer — and usually answering it badly.
The question smuggles in a second question
"How much does it cost to make an app on the App Store" is two questions wearing one coat. Question one — what does the store cost — is trivial: $99 a year, plus Apple's cut of anything you sell. Question two — what does it cost to build software good enough that shipping it to the store isn't embarrassing — is the one people actually mean, and it has no single answer because "an app" describes both a weekend to-do list and a two-sided marketplace with payments, real-time sync, and a compliance surface. Quoting one price for that spread is like quoting one price for "a building."
So the listicle answer — "somewhere between $10,000 and $500,000" — is technically true and completely useless. It is the range of all software. It tells you nothing, which is why every agency site repeats it: a range that wide can never be wrong, and never has to be defended.
Apple's cut is the App Store cost everyone forgets
Here is a real store cost that almost no build quote mentions: Apple takes a commission on everything sold through the App Store. The standard rate is 30%. If you earn under $1 million a year you qualify for the Small Business Program and it drops to 15%, and subscriptions fall to 15% after a subscriber's first year. Physical goods and services fulfilled outside the app are exempt. That commission is not a line item in your development estimate, but it is the single largest recurring cost of "being on the App Store" for any app that makes money — and it dwarfs the $99. If your revenue model runs through in-app purchase, price the 15–30% before you price the engineers.
The build quote is a down payment, not a price
When a studio quotes you a number to build the app, they are pricing version one. Version one is the cheapest version of your app you will ever ship. It is the version with the fewest edge cases, the smallest data set, no real users doing unexpected things, and no accumulated history to migrate. The number is real, but it is the price of the starting line, not the race.
For grounding, our own project bands: a genuine MVP runs $40,000–$100,000, a production SaaS $60,000–$150,000, a two-sided marketplace $80,000–$200,000. What moves you inside those bands is not the app's screens — it is what sits behind them. A read-mostly app with a REST API and Apple sign-in lands near the floor. Add Stripe and payouts, add real-time features, add a HIPAA workflow or a second platform to keep in sync, and you climb, because each of those is its own subsystem with its own failure modes, not a feature you bolt on.
Cross-platform is a budget decision disguised as a technical one
The native-versus-React-Native argument is usually framed as engineering religion. It is mostly a cost lever. One React Native codebase serving iOS and Android is cheaper than two native codebases doing the same job — until the app leans hard on platform-specific behavior, heavy graphics, or tight OS integration, at which point the "savings" turn into a second set of bugs you pay to chase on both platforms. The right call depends on what the app does, not on what's fashionable. The wrong call is picking the stack to hit a number and discovering the number was fiction six months in.
Version one is where the money starts, not where it stops
An app is not a purchase. It is a subscription to your own decision. iOS ships a major version every autumn and deprecates things on its own schedule; your dependencies move; Apple's review rules shift; a library you built on gets abandoned. None of that is optional maintenance — it is the cost of the app continuing to run at all. Plan on spending 15–20% of the original build every year just to stand still, before a single new feature. An app that isn't worth that annual spend is an app that shouldn't have been built.
This is why the single-number quote is worse than useless — it trains you to think of the app as a thing you buy once. We have built for the App Store for a decade, and the projects that worked were the ones treated as multi-year commitments from day one. We built MyFlyRight's platform from scratch on React, Laravel, and PostgreSQL and have been its engineering partner for roughly ten years; the platform we built has since processed over a million claims. That is not a build cost. That is a decade of the same team keeping software alive as the ground moved under it.
The lowball has a business model
When someone quotes you a suspiciously clean, suspiciously low single number, they are not being generous. They are running one of two plays. The first is the change-order play: win the deal on a lowball, then bill every gap between the fiction and the reality as new scope. The second is the MVP-factory play: ship you a thin throwaway that demos well, collect the check, and let the thing rot the moment real users touch it. Both hit the number. Neither gives you an app that survives its first birthday.
We are not an MVP factory, and the discipline that follows from that changes the estimate. When we took over Meal4U — a stalled build the previous team never delivered — we spent a week deconstructing scope and re-estimated it roughly ten times, cutting 30–50% each pass until we found the smallest thing worth shipping. That is what honest estimation looks like: not a big round number that makes the client comfortable, but a small defended one that survives contact with production. Every pull request we merge is reviewed by another senior engineer before it lands, because the cost that actually kills apps is the one that shows up eighteen months later as a codebase nobody can safely change.
We've made the long version of this case in our full breakdown of when staff augmentation is worth it. For team composition, rates, and how engagements start, our staffing services cover it.
So what should you actually budget?
Budget the $99 a year for the store and forget about it — it is a rounding error. Budget 15–30% of your in-app revenue to Apple if you sell through the store. Budget $40,000–$150,000 to build a real version one, landing higher the more payments, real-time behavior, compliance, and second platforms you carry. Then budget 15–20% of that build every year, indefinitely, to keep it alive. If you cannot fund the fourth number, do not spend the third.
The apps we have shipped that reached scale — one we built from scratch reached roughly two million installs and a number-two App Store ranking in its category — got there because someone funded the whole curve, not just the launch. The $99 buys you a listing. What determines whether the app is worth having is the money you are willing to keep spending after the confetti. Anyone who answers "how much does it cost to make an app on the App Store" with a single figure has told you nothing except that they haven't maintained one.