How Much Does an iOS App Actually Cost to Build?
Why published iOS cost ranges disagree by 2.7x, what actually drives the number, and the 2026 platform facts that change the math.
Search for iOS app development costs and you’ll find dozens of confident ranges. Almost all of them are published by companies that sell iOS development, and almost none explain how they got their numbers. Here is what can actually be verified, and how to reason about the rest.
The published ranges contradict each other
Start with what the market says, because it’s the first thing anyone finds. The agency-published ranges for a “simple” iOS app disagree with each other by a factor of 2.7 — one floor sits at $15,000, another at $40,000. Neither publishes a sample size or a definition of “simple.”
One of them, TekRevol, contradicts itself inside a single article: a headline range of $10,000–$700,000+ against body text saying $15,000–$300,000. That isn’t sloppy editing so much as evidence that the number was never measured. It was chosen.
This matters more than the figures. A cost range with no methodology is a marketing artifact, not data. Treat every published number — including any you find here — as attributed opinion until someone shows you the sample.
So rather than add another invented range to the pile, the rest of this post separates two things: platform facts with primary sources behind them, and estimation method. The facts constrain the budget. The method produces the figure.
What actually drives the number
Four things move an iOS estimate far more than anything else, and none of them are “how many screens.”
Scope, defined as decisions not features. A screen that displays data is cheap. A screen where the user changes data that other systems depend on is expensive, because it drags in validation, conflict handling, error states, and offline behaviour. Count the state transitions, not the mockups.
Backend. An app that talks only to Apple’s frameworks and one vendor API is a fundamentally different project from one that needs authentication, a database, an admin surface, and someone on call. The backend frequently costs more than the app.
Integrations. Every third party you add is a dependency with its own auth model, rate limits, breaking changes, and review implications. Payments, health data, maps, and analytics each carry their own compliance surface.
Design. Not the visual pass — the number of states that need designing. Empty, loading, error, offline, permission-denied, and first-run states are where design budgets actually go, and they’re the states most commonly missing from a cheap quote.
Maintenance is not optional, and there’s a hard date proving it
The most common client assumption worth dismantling: build it once, then leave it alone.
Since 28 April 2026, App Store Connect rejects uploads that weren’t built against the iOS 26 SDK. That’s a primary-source fact from Apple, not a best practice. It means shipping a one-line bug fix requires a current toolchain, and keeping a current toolchain means periodically absorbing whatever changed in the SDK.
The practical consequence is that “can I stop spending after launch?” has an evidenced answer: no. Even an app you never intend to improve needs a maintenance path, because Apple’s minimum SDK moves and the ability to ship anything moves with it.
When you’re comparing quotes, ask what the annual figure is for keeping the app buildable and submittable — separate from any new features. A quote without that line item is incomplete, and the gap will surface the first time you need an urgent fix.
The AI feature cost most estimates get wrong
“Add an AI feature” usually reads as an open-ended operating cost: every user interaction becomes a metered API call, and the bill scales with success.
Apple’s own Small Business Program page changes that math for a specific class of app. Members under 2 million first-time downloads can use Apple Foundation Models on Private Cloud Compute with no cloud API cost. On-device inference has never had a per-call price; this extends the same to Apple’s server-side models for qualifying developers.
That reframes an AI feature from an unbounded operating expense into a bounded build expense — which is one of the few genuinely useful cost insights available for 2026 iOS work, and it appears in almost none of the published ranges.
The constraint is capability. Apple’s models are not a drop-in substitute for every frontier model, and the choice between them and a third-party API is a product decision with a cost consequence, not the other way round. If the feature genuinely needs a specific external model, that’s a recurring line item and should be budgeted as one. Deciding this early is worth real money.
Revenue mechanics: proceeds, not revenue
Two things prospective clients routinely get wrong when modelling the business side.
First, the Small Business Program’s $1 million threshold is measured in proceeds, not revenue. Proceeds are what Apple pays you after commission — so the threshold is further away than a revenue-based reading suggests. Model it correctly before you assume you’ve crossed it.
Second, US commission is currently mid-litigation. The Ninth Circuit reversed Apple’s stay on 28 April 2026, and the fee question is back before a lower court. Any financial model that assumes a permanent 0% on external link-outs is placing a bet on an unresolved case, not writing down a budget line.
The same caution applies to EU terms. Those changed on 1 January 2026 and are likely to change again, which is why you won’t find a fee table here. If your revenue model depends on a specific EU fee structure, verify it at the source on the day you build the model — not from a blog post, including this one.
A method instead of a number
Given that the published ranges don’t agree, the honest deliverable is a method for getting to your own figure.
Start by writing down the smallest version that a real user would pay for or rely on. Not the roadmap — the first thing that has to work. Then list every state that version needs to handle, including the failure states. That list, not the feature list, is the estimable unit of work.
Next, separate build from run. Build is the one-time cost of getting to that first version. Run is what it costs annually to keep it submittable, keep dependencies current, keep any backend alive, and pay for any metered service. Get both numbers from anyone bidding.
Then price the unknowns explicitly. If a third-party integration has undocumented behaviour, or a compliance question hasn’t been answered, that’s a time-boxed investigation with its own cost — not a line item to absorb silently into a fixed price. Studios that hide unknowns in a fixed bid recover the money later through change requests.
Finally, treat any estimate produced before the state list exists as a conversation starter. That’s true of the ranges you find online and it’s true of a first call with us. The estimate gets real when the scope does.
What we’re still verifying
Two gaps are worth naming, because a cost post that pretends to completeness is the thing this post is arguing against.
The first is Liquid Glass, the iOS 26 design language. It’s plausibly the most 2026-specific design cost driver — adapting an existing interface to a new system look is real work — but we haven’t verified its specifics against primary sources, so there’s no section on it here rather than a section written from memory.
The second is developer rate data. The rate figures circulating in cost articles come from the same unmethodological agency sources as the ranges. Primary labour data exists at the source, and until that’s checked, quoting hourly rates would just be laundering marketing copy.
We’d rather publish the constraint than fill the space. That’s the same standard we apply to estimates: the parts we can evidence, clearly separated from the parts we can’t, so you know which is which before you commit a budget.