Mobile app cost in 2026: typical US ranges

A simple custom app is often discussed at $25,000 to $80,000. In public agency and product discussions, that band describes one primary job, a modest screen map, accounts or a simple sign in, and a connection to an API that already exists or is small enough to build with the app. Examples that fit the description include a booking companion for a service the business already sells, a customer portal on top of an existing system, or an internal tool for a field team with a short task list.

The band assumes custom work. A spreadsheet exported to a phone, or a website pinched into a web view with no product decisions, is a different object and a different conversation. The $25,000 floor is still a real project: design of the flows, engineering, accounts, a test pass on devices, and a store submission. Owners who compare it with a $3,000 to $15,000 marketing site are comparing a site with an app. Both can be honest. They are not substitutes.

What usually sits inside that simple band is a single role or a very small set of roles, online use with ordinary loading states, and an admin path that might be a few screens or a lightweight web page. Payments, a marketplace, and a large offline mode push the work toward the next band. So does a backend that has to be designed from scratch, with its own data model, jobs, and permissions. If the quote is for the phone screens only, ask who is building the API.

A complex product is often discussed at $80,000 to $250,000 and up. The "and up" is part of the public description. Marketplaces, products with several user types, and workflows that have to be right the first time are often discussed above $250,000. The high number in the band is a reference point in those discussions. It is not a maximum we are reporting as a rule.

Four scope choices explain most of the jump. iOS only versus both stores is the first. Shipping to the Apple App Store and to Google Play means two review processes, two sets of device checks, and two release habits, even when a cross platform toolkit shares a large part of the interface. A single store is a smaller first release. Adding the second store later is a project of its own if the first release never planned for it. Accounts are the second choice. A single login is smaller than customers, staff, and admins with different permissions, password reset, and a way to remove a user. Offline is the third. Caching, conflict handling, and a written rule for what happens with no signal are product work. Admin tools are the fourth. If the office must edit content, refund an order, approve a user, or see a queue, those screens are part of the product even when they live on the web.

Integrations sit on top of those four. Payments, maps, SMS, calendars, and a CRM each add a vendor account and a test plan. Store policy work sits there too: privacy labels, account deletion, and the review notes Apple or Google send back. None of that is free because the screen design already looks finished.

Apple publicly lists the Apple Developer Program at $99 per year. Google publicly lists a one time Play registration fee at $25. Both are platform fees paid to those companies so the business can publish. Both can change, and other Apple programs are priced differently, so confirm the current figures on Apple's and Google's own sites before you lock a budget. Neither fee belongs inside the $25,000 to $80,000 or $80,000 to $250,000 build bands. Next to those bands they are small, and they still need to sit in accounts the business owns. An agency login that you cannot recover is a release problem waiting for a staff change.

Maintenance is often planned around a fraction of the build each year. Call that a planning habit, not a rule. Teams set money aside for operating system updates, store policy changes, bug fixes, and small improvements. Public discussions do not agree on one percentage, and this guide does not invent one. A fraction you choose with your eyes open can be a sensible reserve. A contract that presents a percentage as an industry law, with no list of what the year includes, is a slogan. A new feature, a redesign, or a second store is a new project. Defined support, with hours or a ticket scope, is the version of this conversation we prefer to price.

Also outside the build band unless the proposal names them: the devices used for testing, a separate design engagement if the quote is engineering only, legal review of a privacy policy, and the staff time to answer store review questions. Those items are real. They are easy to forget because they are not screens.

Compare the screen list, the stores, and the backend before you compare the headline number. A single price for iOS, Android, admin, and offline, with no screens named, is not a scope you can hold. A prototype price restated later as the production price has the same problem. A clickable demo and a shipped app with accounts, crash logs, and a store listing are different products.

Ownership is the next flag. Store accounts, the code repository, and the cloud project should be the business's. A build you cannot ship an update to, because the vendor holds the Apple and Google accounts, is more expensive than a higher quote you can leave cleanly. A maintenance percentage presented as a mandatory rule, with no description of updates versus new features, is the third flag. Timelines that ignore store review are the fourth. Review can add days, and a rejection can add a fix cycle. A plan that promises a public launch on a morning with no buffer is guessing.

We quote a fixed build after a call that settles the first release. The questions are concrete. Is version one iOS only, or both stores? Which accounts and roles exist? What must work offline? Which admin jobs are in the first version, and which wait? What API already exists? The written price follows those answers. Backend work is called out, either inside the same quote or as a separate API and backend scope, so the phone screens are not quietly assuming a server nobody is building.

Store fees stay listed as Apple's and Google's charges. We do not fold $99 a year or the $25 registration into an agency fee and call it the app price. Support after launch is a defined scope. We will talk through a reserve if you want a planning habit for the year. We will not print a universal percentage and call it a rule. CodeHunterz prices are confirmed in a written quote. They are not a mobile app rate and they are not researched app market data.

Related reading on this site: custom mobile app development, cross platform app development, and API and backend engineering. If you are still deciding between a site and an app, read the website cost guide first and compare the job, not only the dollar span.