App budgets go wrong in a specific and predictable way. The build is estimated carefully, negotiated, approved and delivered — and then nobody has budgeted for the fact that an app is not a deliverable. It is a subscription to two platforms that change their requirements every year, whether or not you have changed your product.
The build first. A focused first version — accounts, one core flow, a back end, both platforms — sits in the fifteen to forty thousand band. A real consumer product with payments, notifications, offline behaviour and a designed interface rather than a functional one belongs in forty to a hundred. Above that you are building something with synchronisation, real-time state or regulatory weight, and the app is the visible tenth of the project. Below fifteen you are either buying a very small app or buying somebody's first one.
Within the build, the distribution is not what people expect. Product definition and interface design take more than a third, because two platforms means two sets of idioms and every screen is decided twice even when it is drawn once. The application itself is around a third. The back end and API — the part nobody sees and every app needs — is a quarter, and is the line most often left out of a cheap quote on the assumption that it already exists. Testing across a device matrix and preparing store submission material takes the remainder, and takes longer than anyone plans for.
Then the standing costs, which is where this piece earns its keep. The store fees are trivial and worth stating anyway: the Apple Developer Program is an annual fee, ninety-nine dollars at the time of writing, and Google Play charges a one-off twenty-five dollar registration. Nobody has ever been hurt by those. What hurts is everything they imply.
Two operating system releases a year, each of which can change layout behaviour, permission prompts or a deprecated API you depend on. Google Play's target API level deadline, which forces every app to be rebuilt against a recent SDK annually or be delisted from search for new users. Apple's periodic requirements — privacy manifests, the account deletion rule, sign-in requirements when third-party sign-in is offered — each of which arrives with a date and no exceptions. None of these are features. All of them are engineering days, and they occur whether the product changed or not.
On top of that sit the running services: push infrastructure, crash and performance monitoring, the back end's hosting and database, and analytics. The realistic rule of thumb is fifteen to twenty-five per cent of the build cost per year simply to stand still, before a single new feature. An app maintained at zero per cent is not stable — it is quietly rotting toward the version where it stops launching after an OS update, which is the most expensive possible moment to discover it.
Four things make an app disproportionately expensive, and it is worth knowing them before scoping. Offline synchronisation with conflict resolution, because two people editing the same record on two phones with no network is a genuinely hard computer science problem and not a feature toggle. Real-time collaborative or live state. Sustained background location. And in-app purchase of digital goods, which brings platform commission — thirty per cent, or fifteen under Apple's Small Business Program and for subscriptions after the first year, with the EU's Digital Markets Act still reshaping the terms as this is written. Note the important exemption: physical goods and services consumed outside the app are not subject to in-app purchase at all, which is why a retail or booking app can take payment through Viva Wallet, Everypay or Stripe and keep its margin.
The cheapest app remains the one that was not built. The second cheapest is the one that shares its API, its types and its team with the web platform, so a feature is specified once and the two surfaces cannot drift. That is not a cost-cutting measure applied at the end. It is an architecture decision made before anyone writes a line, and it is worth more than any negotiation over a day rate.
Common questions
- How much does it cost to build a mobile app in Greece?
- A focused first version for iOS and Android with accounts, a core flow and a back end typically costs €15,000–40,000. A full consumer product with payments, notifications, offline behaviour and considered interface design costs €40,000–100,000. Products with real-time synchronisation or regulatory requirements go above that.
- What are the annual costs of keeping an app in the App Store and Google Play?
- Budget fifteen to twenty-five per cent of the build cost per year before any new features. That covers two OS releases a year, Google Play's annual target API level requirement, Apple's periodic policy changes such as privacy manifests and account deletion, dependency and security updates, push and monitoring services, and back-end hosting. The store fees themselves — Apple's $99 a year and Google's one-off $25 — are the smallest part.
- Does Apple take 30% of everything an app sells?
- No. Platform commission applies to digital goods and services bought inside the app — 30%, or 15% under Apple's Small Business Program and for subscriptions after the first year, with EU Digital Markets Act terms still changing. Physical goods and services consumed outside the app, such as retail orders, bookings or travel, are exempt and can be charged through any payment provider.
- Is React Native cheaper than building two native apps?
- Materially, yes — one codebase, one team, one specification per feature instead of two. The saving is largest in maintenance rather than in the initial build, because every OS release, policy change and bug fix afterwards is handled once rather than twice.
The service behind it
Mobile App Development
Native and cross-platform applications for iOS and Android, with the interface work held to the same standard as the engineering.