There is no figure in this article. We do not have verified American price data to publish, and a range built from impressions of what other studios charge would be a made-up number presented as research. What we can do is explain the decisions that determine the number for your project — and in this category, unusually, one decision dominates everything else and it gets made before anyone designs a screen.
One codebase or two: the decision worth the most money
Building natively for both platforms means writing the same features twice, in two languages, by two sets of people, and then maintaining both forever. Building once on a cross-platform framework and compiling to both stores means writing them once. The difference is close to a doubling on the build, and it compounds on every change you make afterwards for the life of the app.
So the question is only ever whether your app genuinely needs native. The honest test is whether it leans hard on platform-specific hardware or interface convention — heavy camera or sensor work, tight OS integration, performance at the edge of what a phone can do, or an interface that must feel unmistakably native to each platform. If that describes your app, pay for two codebases and do not let anyone talk you out of it. If it does not — and for most business apps, marketplaces, booking tools and internal systems it does not — paying twice buys you nothing a user will ever notice.
Our own published apps are built this way, which is why one of them went from an empty repository to users' hands in six weeks. We have written separately about the framework choice itself if that is the part you are weighing.
What is specific to shipping to American users
An app binary does not know where its users are. Three things genuinely differ once they are American, and each one has a cost attached that build quotes routinely omit.
Store review is a project phase, not an afterthought. Apple rejects for reasons that have nothing to do with whether the code works: a missing or inaccurate privacy label, no way to delete an account from inside the app, a required sign-in option absent, screenshots at the wrong sizes. Each rejection costs days. A quote that treats submission as something that happens to you after handover is a quote with an unpriced phase in it. Ask explicitly who owns review and what happens if it is rejected twice.
Privacy declarations interact with state law, and that is not your developer's call. Both stores require an accurate account of what you collect and who you share it with. Building the mechanism is cheap. Deciding whether your disclosure satisfies the state privacy statutes that now apply to you is a legal question, it varies by state, and any studio that answers it confidently in a sales call has not read them either. Budget for your own counsel to look at it — it is a real cost of shipping here and it lands outside the build invoice.
How you take money changes the economics entirely. Sell a digital subscription inside the app and the platforms take their cut, with specific and enforced rules about steering users elsewhere. Sell physical goods and you must not use in-app purchase at all, and the flow looks completely different. Getting this wrong is the most expensive available mistake in this category, because it is architectural rather than cosmetic. It is decided at scoping or it is discovered at rejection.
The costs that outlast the build
Apps are worse than websites for this, and it is the half of the question most buyers do not ask.
Both platforms ship a major OS release every year, and an app left untouched breaks eventually — a deprecated library, a policy change, a permission model that shifts under it. An app is not a thing you buy once. Then there is the backend: an app is a window onto a system, and the system has hosting, a database and probably notifications, all of which cost monthly and scale with your users. Then developer program fees on both stores. Then, if the app succeeds, support — because users who can leave a public review expect answers.
A useful way to sanity-check a quote is to ask what year two costs. A studio that has thought about it will answer with a structure. One that has not will treat the question as unusual, which tells you what the first year is going to feel like.
What actually moves the build quote
Beyond the codebase decision, in rough order.
The backend, not the screens. This is consistently underestimated. Accounts, roles, notifications, an admin side for whoever runs the business, and an API that will not need rewriting when the second feature arrives. Projects that budget for screens and not for what sits behind them run out of money exactly when the app starts being useful.
Whether the design exists. An app built against a finished design system moves fast. One where design happens during the build moves at the speed of the slowest decision-maker, and that cost lands on you.
How many external systems it must talk to, and whether they have documented APIs. The exotic one is never the well-known service — it is the internal system with no API that nobody mentioned until week six.
Whether you have decided what version one is. The commonest way an app budget doubles is that version one was specified from a pitch deck rather than from a real user. A first release should do one thing for one kind of user well enough that somebody uses it daily.
How to compare quotes
Ask for the exclusions list — a proposal without one is an opening position. Ask whether store submission and up to two rejection cycles are included. Ask what the backend hosting will cost monthly at your expected user count. Ask who owns the Apple and Google developer accounts, where the correct answer is your company, with your billing, from the start — an app published under an agency's account is an app you cannot update without them. And ask for a released app the client has kept updated since handover.
If you want the British version of this question we have written it, and if you want a number for your own app rather than for the category, that is a quote rather than an article. Ours begins with a free written teardown inside 48 hours, and you keep it either way.
