How Much Does It Cost to Maintain a Mobile App?

Because the platforms won't let you — and this is the single most misunderstood fact in app ownership. Both stores enforce moving compliance targets. Apple requires new uploads to be built with a recent SDK: since 28 April 2026, submissions must use the iOS 26 SDK, and that requirement rolls forward with each major iOS release. Google Play requires your app to target an Android API level within one year of the latest major Android version, with apps that fall too far behind becoming undiscoverable to new users on newer devices.

Read those rules together and the consequence is stark: an app nobody has touched for eighteen months is very likely not shippable as-is. The day you need to fix a bug or add a feature, you first pay for the deferred modernisation — new SDK, new target level, dependency updates that cascade from both — before your actual change ships. Neglect doesn't save maintenance money; it converts small scheduled payments into one large surprise invoice with a deadline attached.

This is also why "maintenance" is not an agency upsell, whatever your last vendor made it feel like. It is the platforms' explicit operating model — they push the ecosystem forward and expect every live app to keep up. The honest question is never whether to budget for it, only whether you pay it as a calm annual routine or as an emergency.

Here is the floor — the costs that exist even for a small, stable, well-built app that users are happy with. Everything above this floor is proportional to ambition; the floor itself is non-negotiable.

Above the floor, cost tracks three things: how much backend your app has, how fast its dependency surface moves, and how actively you iterate. A content app with no accounts sits near the floor. An app with logins, sync, payments, and notifications has a live backend to patch and monitor, third-party services whose APIs evolve, and store policies (payments, privacy, permissions) that periodically demand changes.

As a budgeting envelope, the industry rule of thumb — roughly 15–20% of the original build cost per year — is a fair planning number for a typical small-business app, covering the floor plus modest fixes and small improvements. We prefer to make it concrete rather than percentage-shaped: on our model, maintenance is a defined annual scope on a fixed written quote — the compatibility release, monitoring and triage, and an agreed allowance of fixes — so it's a known line item, not an hourly meter you fear invoking. Feature work beyond that rides as separately-quoted sprints, exactly like the original build.

One honest asymmetry to internalise: maintenance cost is mostly determined before launch. A well-architected app on a boring, mainstream stack — one codebase via Flutter, disciplined dependencies, tests, CI — makes every yearly release a small, predictable job. A rushed build with an exotic stack and no tests makes the same yearly release an archaeology project. That's why the cheapest maintenance decision you'll ever make is choosing how the app gets built — the argument we lay out in cross-platform vs native, where one codebase halves every future compliance cycle by construction.

We can describe the neglect trajectory precisely because rescue projects arrive at our door somewhere along it. Months one to twelve: nothing visibly breaks, which is exactly what makes neglect feel free. Somewhere after the first year: the store deadlines pass — new uploads now require SDK and target-level modernisation, so even a one-line fix has a toll gate in front of it. Meanwhile OS updates subtly change behaviour (permissions, background execution, notifications), and the crash rate creeps on new devices nobody tested.

The compounding is the expensive part. Dependency updates that would each have been trivial now interact: the new target API needs a new version of a library, which needs a build-tool update, which surfaces deprecations elsewhere. What a yearly routine would have absorbed in days becomes weeks of modernisation — priced as a rescue, because that's what it is. And if the app matters to revenue, the timing is never yours: the forcing event is a critical bug or a store policy email, with users watching.

The store-facing risks are quieter but real too: Play's rules can make severely outdated apps undiscoverable to new users, and both stores periodically prune or flag stale listings. An app that took months to build and rank can lose its compounding store presence simply by being left alone. None of this argues for gold-plated retainers — it argues for the boring minimum, done on schedule.

Timing the yearly work to the platform rhythm is free money, because the ecosystem moves on a broadly predictable cycle: Apple ships its major iOS release each autumn (with the SDK requirement for uploads typically rolling forward the following spring), and Google's target-API expectations advance annually behind each major Android release. Plan around that rhythm and each deadline arrives as a diary entry, not a surprise.

The calendar we run for our own apps: a light quarterly pass — dependencies reviewed, crash dashboard triaged, store policy inbox cleared — plus the substantial compatibility release scheduled shortly after the autumn OS releases settle, when the new SDKs are stable and beta devices have become real devices to test on. That slot catches both platforms' requirements in one well-tested release and leaves months of slack before any enforcement date.

Two extra beats worth putting in the diary: click through your app on the OS betas each summer (an hour on a beta device catches most behaviour changes before your users do), and re-check store policy announcements twice a year — privacy and data-safety requirements have a habit of adding a form or declaration that costs minutes when planned and a rejected release when discovered late.

Our maintenance economics come from the same place as our build economics: decisions that make the yearly work small, made before launch. One Flutter codebase means each store's compliance deadline is handled once, not twice. Boring, mainstream dependencies mean updates are well-trodden. CI produces every release, an internal testing track receives it first, and production promotes the exact tested artefact — so a maintenance release follows the same safe rails as a launch. Crash reporting and structured analytics ship from day one, so "is anything wrong?" is a dashboard, not a guess.

What a maintenance year with us looks like in practice: monitoring with triage (you hear from us when something needs a decision, not a meter running), the scheduled compatibility release with release-build testing on real devices, store housekeeping (policy forms, privacy declarations) handled, and small fixes inside the agreed scope. Larger improvements queue into fixed-quoted sprints whenever you choose — informed by the analytics, not guesses. It's deliberately unexciting, which is the point: we run this exact routine on our own live store apps, so the checklist you're buying is the one we already run for ourselves.

If you're budgeting a new app, put maintenance in the plan from day one alongside the build cost and the launch timeline — the three numbers together are the honest total cost of ownership. And if you have an existing app that's been sitting untouched and you're bracing for the modernisation bill: get it assessed before the next store deadline passes, not after. A scoped catch-up now is reliably cheaper than a rescue later.