How Much Does It Cost to Build a Mobile App in 2026?

The honest answer to "what does an app cost" is that it depends almost entirely on scope — and scope is precisely the thing that is not yet settled when most people ask. That is why almost every cost guide you will find gives you a range instead of a number.

There is a reason those ranges are so wide, and it is worth saying plainly: the people publishing them intend to quote you afterwards. A range that spans an order of magnitude commits the writer to nothing.

We do it differently, which is the only reason we can write this post without a range. Caliency publishes fixed prices for defined scopes on the mobile app development page. So rather than inventing market averages, this guide does the more useful thing: it explains what actually moves the number, what is never inside anyone's build price, and the recurring cost that the platforms impose on you whether your product changes or not.

Key Takeaways

• Quotes for "the same app" differ mostly because they are not the same scope. The spread is a specification problem, not a margin problem.
• The store takes 15% or 30% of digital sales depending on the programme and your earnings (Apple, Google Play).
• Maintenance is not discretionary: Apple requires apps uploaded after 28 April 2026 to be built with Xcode 26 or later (Apple Developer).
• A fixed price protects you only if the scope was fixed first. Otherwise it is an hourly contract with extra paperwork.
• Launching on one platform first is a legitimate way to halve the initial build.

Why quotes for the same app differ by a factor of ten

They are almost never quotes for the same app. Two proposals can describe what sounds like an identical product and price it ten times apart because they answer different questions silently.

Six questions account for most of the spread:

• Who writes the backend? An app that displays content is a fraction of the work of one that stores, syncs and secures user data. If one proposal assumes you already have an API and the other includes building it, they are not competing.
• Is there an admin panel? Somebody has to moderate content, refund an order, or fix a broken record. If that is not in the scope, it becomes your problem on launch day.
• How many user roles? One kind of user is one set of screens and one permission model. Customers plus staff plus administrators is three of each, and the interactions between them.
• One platform or two? A price for iOS is not a price for iOS and Android, and the difference is not a rounding error.
• What happens when the scope changes? A quote that is silent about change requests has not eliminated them. It has deferred the conversation to the point where you have the least leverage.
• Who pays for post-launch fixes? Bugs that only appear with real users on real devices are not a possibility, they are a certainty. Whether fixing them is billable is a contract question, not an engineering one.

Ask two agencies these six questions and their "identical" quotes will stop being identical. That is the useful exercise — far more useful than comparing headline numbers.

The mobile app development guide covers what each of those scope decisions involves in engineering terms.

What is never inside a build price

Whatever you pay to have the app built, four costs sit outside it. These are the ones with published numbers, so they are the ones this guide can be precise about.

The store's commission. If your app sells anything digital, the store takes a permanent share. Apple's App Store Small Business Program charges 15% rather than the standard rate, for developers whose proceeds were up to $1 million in the prior calendar year (Apple Developer). Google Play charges a "15% service fee tier" on "the first $1M (USD) revenue earned by the developer each year" and "30% for earnings in excess of $1M (USD)", with auto-renewing subscriptions at 15% regardless of revenue; Google states that "99% are eligible for a fee of 15% or less" (Google Play Console Help).

One thing to watch if you sell in Europe, the UK or the US: from 30 June 2026 Google applies a different structure to new installs in those markets, beginning at "10% + 5% billing fee" for the first $1M in annual earnings. If your revenue model is built on today's percentages, that is a line worth re-checking.

Developer accounts. The Apple Developer Program costs $99 a year (Apple Developer) and Google Play charges "a US$25 one-time registration fee" (Google Play Console Help). Trivial amounts, but they belong in the first budget conversation because they are recurring commitments rather than one-off purchases.

Infrastructure. If the app has a backend it has a hosting bill, and that bill scales with your success — and what the backend meters decides whether that bill tracks your users or your screens. This is a good problem, but budgeting zero for it is still budgeting wrong.

Testing across real devices. Google no longer publishes a public breakdown of which Android versions are running in the wild — the developer dashboard now reports graphics capabilities and points developers to their own Play Console data instead (Android Developers). The practical consequence for a budget is unchanged: the range of devices your app must work on is a real cost, and it is larger on Android than on iOS.

Timeline is the other question everyone asks. The waits the stores impose and a week-by-week build plan are in how long does it take to build an app.

The cost nobody quotes: the platform makes you rebuild

This is the section we most wish clients heard before signing anything, because it is the one that turns a finished app into an unfinished commitment.

An app is not a building. It sits on two platforms that change underneath it on their own schedule, and both of them enforce that schedule with deadlines.

Apple's published upcoming requirements state that from 28 April 2026, "Apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26" (Apple Developer). Read that as a budget line. Every app that needs to ship an update after that date needs an engineer to rebuild it against a new SDK — regardless of whether your product changed, your users asked for anything, or your business had a reason to touch the code.

Compliance moves too, and with sharper consequences. On the same page, Apple states that apps without EU Digital Services Act trader status "will be removed from the App Store in the European Union (EU) until trader status is provided and verified". That is not a rejected update. That is your app leaving a market over an administrative field.

So the question "what does it cost to keep the app alive?" has a shape even when it does not have a number: it is whatever it costs to have someone competent available when a platform deadline arrives. An app nobody maintains does not gradually degrade. It stays fine, and then one day it cannot be updated at all.

A fixed price only protects you if the scope is fixed first

Fixed-price contracts are sold as client protection, and they can be. But the protection comes from the sequence, not the label.

A fixed price attached to a scope that is still moving is an hourly contract with extra paperwork: every change becomes a negotiation, and you are negotiating from inside a project you have already committed to. The number on the contract stops meaning anything the first time someone says "while we're in there, could it also…".

The real value of fixing the price first is that it forces every feature decision into the one week when decisions are still cheap — before architecture is set, before anything is built on top of them. That week is uncomfortable. It is also the highest-leverage week of the project.

This is why our own pricing fixes scope and price together in the contract, and why the discovery conversation happens before the number does, not after.

What to ask before you sign anything

You can evaluate any proposal, ours included, with a short list. None of these questions require you to be technical.

1. What exactly is in scope, written as a list I can check off at delivery? If it is described in adjectives rather than items, it is not a scope.
2. Who owns the source code, and where does the repository live? The answer should be "you" and "your account", from day one.
3. What happens when I change my mind mid-build? Not whether — when. A good answer describes a process, not a prohibition.
4. Is the backend included, and if not, who is writing it?
5. What is covered after launch, and for how long?
6. Who will actually write this code? The gap between the people in the pitch and the people on the keyboard is where most agency disappointment comes from.
7. What is not included? The most useful question on the list, and the one most rarely asked. A proposal that cannot answer it crisply has not been thought through.

If a proposal answers all seven without hedging, the price on it means something. If it cannot, the price is a guess wearing a suit. How to read a quote in person-months, against the sector's average personnel cost, is in how to choose a software development company.

In short

An app costs what its scope costs, plus a permanent share of any digital revenue, plus the ongoing cost of staying publishable on two platforms that move on their own schedule. Anyone who gives you a firm number before knowing your scope is guessing; anyone who gives you a ten-times range is deferring the conversation.

We publish ours: the mobile app development page lists what each fixed price includes and what it does not.

If you want a real number for your actual scope, tell us what you are building — and if we think what you need is smaller than what you asked for, we will say so before quoting, not after.