What an iOS App Actually Costs in 2026 — and the Four Line Items Missing From Your Quote

The Number You Were Quoted Is a Build Estimate

Ask five agencies what an iOS app costs and you will get five numbers between $30,000 and $250,000, all defensible, none comparable. Published 2026 breakdowns put a basic MVP as low as $10,000 and enterprise-grade applications above $300,000, which is a range wide enough to be useless as a planning figure. The spread is not vendor dishonesty. It is that every quote answers a different question, and almost none of them answer the one you are actually asking, which is what this app will cost me over three years.

What a build estimate contains is labour to first release: design, implementation, a QA pass, submission. What it excludes, structurally, is everything that happens because iOS is not a static platform and your app does not stop existing after launch. Apple ships a major OS version annually and enforces a submission floor against it. Regulators in both the EU and individual US states have started legislating app distribution and age verification directly. Your dependency tree ages at a fixed rate whether or not you ship features.

The mistake this produces is predictable and expensive. A founder budgets $120,000, spends $118,000 reaching the App Store, and discovers in month fourteen that keeping the thing alive and submittable costs another $30,000 to $50,000 a year before a single new feature is built. The project was not mis-scoped. It was mis-modelled: a capital expense was budgeted for something that behaves like an operating one.

The rest of this piece is the four line items that separate a build estimate from a cost model, with the 2026 numbers attached to each. If you want to sanity-check a proposal against them, our software development cost calculator models scope, seniority and region against comparable engagements rather than a generic rate card.

The Rate Table, Honestly

Rates are the part everybody researches and the part that matters least, but you need them anchored before the rest makes sense.

Lemon.io's 2026 rate data puts iOS developers between $20 and $96 an hour globally, with US-based seniors averaging near $73 and Eastern European engineers delivering comparable Swift and SwiftUI work at roughly $43. Agency rates sit higher than individual rates everywhere: North American iOS shops commonly quote $100 to $150 an hour, Western European ones $70 to $120, and the premium end of the UK and US market reaches $250 for specialist teams.

Composition moves the number more than geography does. A lean MVP team — one developer, one designer, part-time QA — burns somewhere between $47 and $190 an hour combined depending on where it sits. Add a project manager and a business analyst and the same team is $187 to $540 an hour. This is why two quotes for identical scope can differ by 3x with neither being wrong: one is selling you three people, the other is selling you six, and the six-person version genuinely does absorb more of your coordination overhead.

Where rate arbitrage stops working is seniority. A junior iOS developer at $25 an hour who needs four rounds of review on a Core Data migration is more expensive than a senior at $50 who ships it once. That was always true; it is more true in 2026, when AI assistance has compressed the cost of writing plausible-looking Swift to nearly zero and shifted the entire cost of the project onto judgment, architecture and review — the things juniors do not yet have. The practical planning rule: price seniority, not headcount, and treat any quote whose blended rate is below regional junior rates as a staffing model you have not been shown.

Line Item One: Apple's Platform Maintenance Floor

This is the line item that surprises non-technical buyers most, because it costs real money and buys the user nothing.

From 28 April 2026, every app or game uploaded to App Store Connect must be built with the iOS 26 and iPadOS 26 SDK or later, and compiled with Xcode 26 — with matching floors for tvOS, watchOS and visionOS. Apple published the requirement in its upcoming requirements notice and confirmed it in February. It applies to new submissions and updates, not to apps already live — which sounds reassuring until you need to ship a bug fix.

That is the mechanism worth internalising. An app that receives no maintenance does not fail slowly; it fails at the moment you need it to change. The day a payment provider deprecates an SDK, or a customer reports a crash on the newest iPhone, you discover that shipping the one-line fix requires an SDK bump, a toolchain upgrade, a dependency cascade, and a re-test of every screen. Work you deferred for eighteen months arrives as a single blocking bill, usually in the same week as the incident that triggered it.

This cadence is annual and it is not negotiable. Budget a platform maintenance allocation — realistically two to four engineering weeks a year for a mid-sized app, more if you carry heavy third-party dependencies — as a recurring line, the same way you budget cloud hosting. Teams that treat it as scheduled work spend less than teams that treat it as an emergency, and the gap is not small: the same SDK migration handled deliberately in a quiet sprint routinely costs a third of what it costs when a production incident is forcing it.

Line Item Two: Distribution Stopped Being One Thing

For fifteen years, iOS distribution was a solved problem with exactly one answer. That ended in Europe and it is now visible in the codebase.

Under the Digital Markets Act, iOS supports distribution through alternative app marketplaces, the operation of third-party marketplaces, and payment processing outside Apple's In-App Purchase system. Apple's notarisation and marketplace authorisation processes sit between you and that freedom. For most companies the correct decision is still to ship only through the App Store — but it is now a decision, with engineering consequences, rather than an assumption.

The cost lands in three places. Build and release configuration multiplies: separate entitlements, separate distribution pipelines, separate review paths per channel. Payments stop being a single integration, because an external payment path means you own the compliance, tax handling, receipt validation and refund flows that IAP previously absorbed. And your analytics and entitlement logic have to reconcile users who acquired the same app through different channels with different receipt formats.

There is a version of this that is genuinely worth doing — a subscription business paying a 15% or 30% commission on meaningful revenue can build a serious case for an external payment path. There is also a version that is pure cost, undertaken because someone read a headline. The test is arithmetic: model the commission you would actually avoid across twelve months against the build plus the ongoing operational burden of running payments yourself. Below roughly a few hundred thousand euros of European subscription revenue, the honest answer is usually that App Store distribution alone is still correct, and the useful output of the exercise is a quote that says so explicitly rather than one that silently assumes it.

Line Item Three: Compliance Is Now Product Work

The third line item is the one moving fastest, and it is the one least likely to appear in a build quote at all.

Age assurance is arriving jurisdiction by jurisdiction. Texas SB2420 introduced age-verification obligations on app marketplaces, with comparable requirements following in Utah and Louisiana, and the enforcement picture has been shifting month to month through 2026. In Europe, obligations around minors, dark patterns and data minimisation attach at the product level. Whatever the final shape, the engineering implication is stable: an app that touches user accounts now needs an age signal, a way to act on it, and evidence that it did.

Add to that the EU-side obligations most European apps already carry — GDPR lawful basis and data-subject request handling, accessibility requirements under the European Accessibility Act, and for anything sold as a connected product, the security update obligations arriving under the Cyber Resilience Act. Each is individually modest. Together they represent a permanent compliance surface on a product whose quote assumed a login screen, a feed and a checkout.

Two practical consequences follow. First, compliance work has to be scoped as product work with its own estimate, not absorbed into a QA line. Second, it changes what you should ask a vendor. "Have you shipped iOS apps?" is a 2015 question. The 2026 version is: which of our target markets impose age assurance, what does that add to the build, who owns the data-subject request flow after launch, and what happens to the estimate if a jurisdiction we sell into legislates mid-project.

A vendor with a real answer will have thought about the architecture — where the age signal lives, how consent state is stored and audited, whether feature gating is centralised or scattered across view controllers. A vendor without one will quote you the cheapest number on your shortlist, because they have priced a smaller app than the one you need.

Line Item Four: The Maintenance Curve

The last line item is the largest, and the easiest to model, which makes its absence from most budgets slightly baffling.

A reasonable planning figure for annual maintenance on a live iOS app is 15% to 25% of the original build cost, and it does not decay to zero — it is a floor set by things outside your control. The annual OS release. The annual SDK and toolchain floor. Third-party dependency churn, including the payment, analytics and authentication SDKs that ship breaking changes on their own schedule. Certificate and provisioning-profile renewals. Crash triage on device and OS combinations that did not exist when you shipped. None of this is feature work, and all of it is mandatory.

The failure pattern is not that teams cannot afford maintenance. It is that they staff it wrong. Maintenance for a single mobile app is roughly a quarter to a half of an engineer's time — an awkward quantity. Hire a full-time iOS engineer and you overpay for idle capacity while they slowly lose context on a codebase with too little to do. Go back to the original agency ad hoc and you pay a re-engagement premium every time, because someone has to reload a codebase they last touched nine months ago, and the minimum viable re-engagement is never four hours.

This is precisely the profile that staff augmentation against a named engineer handles better than either extreme: a specific person who keeps the codebase in their head, available at a defined allocation, who does the April SDK migration as scheduled work rather than as a rescue. Whatever model you pick, the three-year number is what should drive the decision. A $120,000 build with 20% annual maintenance is a $192,000 three-year commitment before a single new feature. Compared on build price alone, a $95,000 quote wins. Compared on three-year total cost of ownership, it frequently does not — and the ranking flip is common enough that our outsourcing cost analysis treats TCO, not headline rate, as the only figure worth comparing.

Native, Cross-Platform, and the Decision That Actually Saves Money

The native-versus-cross-platform argument is usually framed as a cost question and answered with a slogan. It deserves better, because it is one of the few architectural decisions that genuinely moves the three-year number.

The honest version: if you need both iOS and Android, a cross-platform stack such as Flutter or React Native typically lands a comparable feature set for meaningfully less than two native builds, and the saving is real. If you are iOS-only, cross-platform saves nothing and costs you platform fidelity — you take on a framework's release cadence in addition to Apple's, which is one more upgrade treadmill for zero benefit.

Where cross-platform gets expensive is depth. Heavy use of platform-specific capability — background processing, HealthKit, complex camera or media pipelines, widgets, live activities, tight watchOS integration — drags you into native modules on both sides, at which point you are maintaining three codebases and paying a bridge tax rather than saving on two. The practical heuristic that has held up: if more than about a fifth of your roadmap is platform-specific capability, native wins on three-year cost even though it loses on build price.

This decision should be made explicitly, in writing, with the reasoning attached — and it should be made by someone who does not have a commercial interest in the answer. An agency staffed entirely with Flutter developers will recommend Flutter. That is not corruption; it is what a team recommends when it only has one thing to sell. It is a legitimate reason to prefer a partner who staffs native iOS engineers and cross-platform engineers both, and can therefore afford to be indifferent about which one you need.

How to Read the Quotes on Your Desk

Here is the shortest reliable procedure for turning a stack of incomparable proposals into a decision.

Normalise the scope before you look at any price. Take the most detailed proposal, extract its feature list, and send that list to every vendor as the fixed scope. Most price variation on a shortlist is scope variation in disguise, and this single step removes it. Then ask each vendor for four numbers rather than one: build cost, year-one maintenance, year-two maintenance, and the cost of the April SDK migration specifically. Any vendor who cannot produce the last one has not maintained an app across an OS transition.

Ask who, by name, and for how long. The single strongest predictor of what a mobile engagement will actually cost is whether the same engineers stay with the codebase. Rotation forces re-learning, and re-learning is billed to you at senior rates. A partner who assigns named engineers and keeps them on your product for the duration will beat a cheaper bench-staffed alternative on twelve-month cost more often than not.

Then price the three-year total: build, plus annual maintenance at 15-25%, plus a compliance allocation for your target markets, plus one platform migration per year. Rank on that. The ordering will differ from the build-price ordering roughly half the time, and when it does, the build-price winner is usually the vendor who scoped the smallest app.

At StepTo we have run senior engineering teams out of Serbia since 2014, and mobile engagements have shifted markedly over the past two years — away from build-and-hand-over and toward long-lived product ownership, precisely because the platform maintenance floor made hand-over an expensive fiction. Our nearshore development model assigns engineers by name, keeps them with the codebase, and operates in European business hours, which matters more than the rate differential when an App Store rejection needs an answer the same afternoon. For teams that want the product owned end to end rather than staffed by the hour, a dedicated development team is usually the cleaner structure.