App maintenance costs money in two ways. There are fixed bills you can look up: an Apple Developer Program membership at 99 USD a year, a one-time 25 USD Google Play registration, hosting, your domain and the services the app uses. And there is developer time, which is usually the bigger part, driven by yearly OS releases, app store rules that force updates, security fixes and bugs. Nobody can give you one honest number for your app, but you can build your own from the lists below.
You will see a rule of thumb online that maintenance costs a fixed percentage of the build cost every year. It is repeated everywhere and sourced nowhere. Your app's real cost depends on what it uses and how often the platforms under it change, and both of those can be checked.
The fixed bills
These are the costs that exist even if nobody touches the code.
| Item | Cost | How to check yours |
|---|---|---|
| Apple Developer Program | 99 USD per membership year (prices vary by region) | Apple's enrolment page |
| Google Play developer account | 25 USD, one-time registration | Play Console Help |
| Domain name | Varies by registrar and extension, renewed yearly | Your registrar's renewal price, not the first-year price |
| Hosting, database, storage | Depends on usage | Your last three invoices |
| Email sending, push, maps, analytics | Usually usage-based, often free at small scale | Each provider's pricing page against your real volume |
| AI APIs, if you use them | Usage-based, can grow fast | Your provider's usage dashboard |
The Apple and Google figures were checked in October 2026. The rest are yours to look up, and the most useful number is not the price list but your own invoices, because they show what your app actually uses.
The store rules that force updates
This is the part most people miss. Even an app that works perfectly has to be rebuilt and resubmitted regularly, because both stores raise their minimum requirements.
Apple. Since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later, using the iOS 26 SDK or later. (Apple's upcoming requirements) Apple has raised this minimum repeatedly over the years. In practice, any update you want to ship, even a one-line fix, first needs the project brought up to the current tools.
Google Play. From 31 August 2026, new apps and app updates must target Android 16 (API level 36) or higher, and existing apps must target at least Android 15 (API level 35) to stay available to new users on newer Android versions. Google offered an extension to 1 November 2026 on request. (Android target API requirements) Google publishes a new target each year.
Both were checked in October 2026. The practical meaning: budget at least one maintenance pass per platform per year, even for an app nobody is adding features to. Skip it and you eventually find you cannot ship an urgent fix, or that new users on new phones can no longer find the app.
The work that comes with each new OS
Every year's major iOS and Android release can change things under your app: permissions, notification behaviour, new screen sizes, APIs your code relies on being retired. Most years it is small. Some years it is not.
Then there are your app's own dependencies. Libraries and SDKs (payments, analytics, login providers) release updates, and some old versions stop working or stop receiving security fixes. A developer who updates them regularly does small, cheap updates. One who updates them every three years does one large, expensive one.
Bugs and small changes
Users find things testers never did: an odd device, a slow network, an unusual name in a form. Add a crash reporting tool on day one so you see these before the reviews do.
Small changes arrive too: a price, a text, a new field. Decide up front whether these are billed as they happen or bundled into a monthly arrangement.
How to budget the developer time
You cannot read this off a table, but you can get a defensible number in one conversation:
- Ask your developer for a yearly maintenance estimate in days: one pass per platform for store requirements, dependency updates, and a reserve for bugs.
- Agree a rate for that work, hourly or daily, with a monthly cap.
- Decide the arrangement. Ad hoc work billed as it happens, or a small monthly retainer that reserves time. A retainer costs more when nothing breaks and gets you a faster answer when something does.
- Put the yearly date in the calendar. Plan the update before the store deadlines, not the week after.
If you are still planning the build, include maintenance in the decision. A second platform brings its own store rules and its own yearly pass, which is part of why Flutter or React Native is a budget question as well as a technical one, and why the project cost estimator stops at launch: everything after it is its own line.
What it costs to skip it
Maintenance is easy to postpone because nothing visibly breaks at first. Then three things happen together: a new OS changes something, a store requirement blocks your next update, and the developer who knew the code has moved on. Each would be a small job on its own. Together they are a rescue project.
Treat maintenance as rent rather than repairs: a small, predictable amount paid regularly, so the app stays something you can update the day you need to.