What building an app actually costs in 2026.

An app is not a product, it is a wrapper. Inside it sits everything from a sequence of screens with no data storage to a system with user accounts, payment processing, offline operation and a connection to inventory management. Both are called an app. The effort differs by a factor of fifty.

The Clutch database, which aggregates pricing from verified first-party client reviews, reports 10,000 to 49,999 US dollars as the most common project bracket. The average sits well above that at 90,780 US dollars, because a small number of large projects pull the mean upward. That gap between median and mean is exactly where most budget misjudgements happen.

This guide makes the spread legible. No marketing language, no hidden surcharges. Sourced data with named origin, and where no reliable source exists, we say so.

AI will build you an app in minutes today. It will not build you one that sits on the App Store. That is not a judgement about AI. It is in Apple review guidelines, last updated 8 June 2026.

The distance between a running app and a published app is the single most underestimated item in the whole project. It consists of requirements that all live in the same guidelines and all cost working hours.

A demo account and a live backend. Guideline 2.1 requires credentials for the reviewer or a fully featured demo mode, and that back-end services are live and accessible during review. Switch the server off overnight and you are rejected.

Account deletion inside the app. Guideline 5.1.1 requires that an app supporting account creation also offers account deletion within the app. That is not a button. It is a chain of confirmation, deletion in the backend and handling of any active subscription.

Privacy policy, purpose strings and age rating. Guideline 5.1.1 requires a privacy policy that is linked and reachable inside the app and that states what data is collected, how, and for what. Every permission needs a purpose string a human can understand.

Screenshots that show the app in use. Guideline 2.3.3: not merely title art, a login page or a splash screen.

None of this is design, none of it is programming in the narrow sense, and none of it can be skipped. In a budget, this is why the last ten per cent of an app project is rarely ten per cent of the time.

Building twice natively doubles the price. That is not an agency opinion, it is what Clutch writes in its own pricing guide: creating one native iOS app and one native Android app doubles the overall price, because each operating system requires separate code and often separate design elements, which effectively makes it two distinct projects. Maintaining and updating two native apps raises costs further over time.

That is why at ALVÉRA cross-platform is the default and native is the justified exception. One codebase produces both store builds. That saves not only the build but every later change, every bug fix and every adaptation to a new operating system release.

We build natively when the project forces it. Deep hardware access, sustained background processing, watches and wearables, heavy graphics. In those cases we say so up front and price the doubled effort openly instead of hiding it in a flat rate.

And in many cases the right answer is no store app at all. A web app runs in the browser, can be placed on the home screen, and needs no review, no membership and no commission. It can have accounts, payments, invoices and an admin surface. What it lacks is reliable push notifications across all devices, deep offline operation and full access to device features.

Clients compare proposals by counting screens. What gets built is what sits behind them. Clutch names features and functionalities, the complexity of the UX design and the backend development process as the biggest influences on total cost. Two of those three are not in the interface.

Take an example everyone knows: a sign-in. On screen it is two fields and a button. Behind it sit password handling, reset by email, session management across devices, lockout after failed attempts, deletion of the account with all its data, and the question of what happens to an active subscription when the account disappears.

Which is why how many screens does the app have is the wrong question, just as how many pages does the website have is. Price follows the data logic, not the number of views.

And it is why an agency that comes from the web is not a disadvantage on app projects but frequently an advantage: backend, database and interfaces are the same work, whether the result later lives in a browser or in a store.

Frequently not, and Apple says it more plainly than any agency will. Guideline 4.2 requires features, content and a user interface that elevate an app beyond a repackaged website. Guideline 4.2.2 adds that, other than catalogues, apps should not primarily be marketing material, advertisements, web clippings, content aggregators or a collection of links.

Translated: if your plan is to present content and collect enquiries, the app is not merely more expensive than necessary. By Apple own standards it is not approvable.

The memberships are cheap. The commission is not, if you sell something.

An app is not a project with an end date, it is an operation. That is the difference from a website, and it is the most common reason app budgets break later.

• Servers, database and services: EUR 50 to 400 per month depending on usage, more with large data volumes.
• Maintenance and security updates: EUR 200 to 600 per month for libraries, dependencies and monitoring.
• Adaptation to new operating system releases: the most frequently forgotten item. Apple and Google ship new major versions every year, and Guideline 2.5.1 requires apps to run on the currently shipping operating system and to phase out deprecated technologies. Budget nothing here and eventually you have an app that is no longer in the store.
• Store membership: 99 US dollars a year with Apple, nothing further with Google after the one-time registration.

For an app of moderate scope, EUR 400 to 1,200 per month is realistic. Complex applications with many users and third-party systems sit above that.

These ranges are experience values from our own costing, not a surveyed market figure. We found no reliable survey of ongoing app costs in the German-speaking market, and we therefore quote no third-party number we cannot verify.

You will see proposals at a fraction of our prices. They are not invented. They come from a different market.

Clutch reports hourly rates of 25 to 49 US dollars for app development. In the same country table India sits below 25 US dollars, Canada at 50 to 99, Australia at 100 to 149. Germany does not appear in that table, and the United Kingdom is listed as unknown. The global average is shaped by offshore markets.

A note so the figure does not confuse you: in our Web Design Costs Guide we cite Clutch with hourly rates of 100 to 149 US dollars. That is not a contradiction, they are two different directories with different provider populations. Putting both numbers side by side shows one thing above all: a global average says very little about any single market.

For Germany there is a firmer anchor. The Vergütungstarifvertrag Design is negotiated between the Allianz deutscher Designer and the Selbstständige Design Studios under section 12a of the German Collective Agreements Act and is registered with the Federal Ministry of Labour and Social Affairs. It distinguishes strategic, conceptual and operational design work and treats the licence for usage rights as a separate, fourth fee component. Anyone who builds, supports and warrants in Germany prices in that order of magnitude, not in that of an offshore average.

On top of that comes something no hourly rate table shows: availability in your time zone, contracts under German law, liability, and a point of contact who is still there in two years when Apple changes a guideline.

This chapter exists because you would rightly ask otherwise. Our other guides show case studies. This one shows none, and there is a reason for that.

What we have built: full web applications with everything that makes up an app backend. For Indian Culture, a platform with payment processing, a voucher system, automatically generated PDF invoices, an admin surface, user management, analytics and a monthly revenue report. That is not a website with a contact form. It is the larger part of what also sits behind an app.

What we cannot yet show: a published app on the App Store and Google Play under a client name. We could paper over that. We do not, because a guide built on sourced material cannot start making claims at exactly this point.

What that means for you, practically: on the backend, on data model, permissions, payments and administration, you get demonstrable experience. On the path through Apple and Google review, you get an agency that knows the guidelines in their own wording and plans that step as its own part of the project rather than treating it as a formality. Ask us about it in the first conversation and we will tell you plainly where we stand.

If that is not enough for you, that is a legitimate decision. We prefer it to a project that starts on an expectation we did not set.