Shawn G
October 8, 2026
9
min. read
and updated on:
October 14, 2026
An app is not a deliverable that stays delivered. Apple ships a major iOS release every year, Google ships Android releases and raises the Play Store's target API level requirement annually, third-party dependencies publish security updates, certificates expire, and store policies change. None of that waits for your roadmap.
Which means maintenance is not a service you may want. It is the cost of having an app, and 15 to 20 percent of build cost annually is the realistic floor.
What maintenance actually covers
Six categories, and a retainer that does not name all six is underspecified.
Operating system compatibility. Testing against each new iOS and Android release, ideally against the developer beta over the summer rather than after public release, and fixing what breaks. Roughly a fortnight of work annually on its own for a typical app.
Store policy compliance. Google Play's target API level requirement rises every year, and non-compliance eventually removes your app from distribution to new users rather than merely dating it. Privacy declarations must stay accurate as SDKs change. Both platforms periodically introduce new requirements, such as account deletion paths, that apply retroactively.
Dependency and security updates. Third-party libraries publish fixes, some of them security-relevant. A codebase four major framework versions behind has an upgrade project embedded in it whether you plan one or not.
Defect resolution. Bugs reported by users or surfaced by crash monitoring. A reasonable retainer includes a defined allowance rather than unlimited work.
Infrastructure and certificate management. Push notification certificates, signing certificates, provisioning profiles, SSL renewal, and backup verification. Individually trivial, collectively the cause of most avoidable outages.
Monitoring. Crash reporting, error tracking, and someone actually looking at it. Monitoring nobody reads is an expense rather than a control.
Note what is not on that list: new features. Those are development work and should be quoted separately, and conflating them is how a retainer becomes a dispute.
What happens to an unmaintained app
Degradation is gradual and then abrupt, and the sequence is predictable.
Months one to six: nothing visible. This is the period during which maintenance feels unnecessary.
Months six to twelve: a new OS release causes visual glitches, a deprecated API produces intermittent failures, and crash rates rise. Reviews begin mentioning it.
Year one to two: an SDK you depend on stops being supported. A third-party service changes its API and a feature silently stops working. Store policy changes require a submission you are not ready to make.
Year two onward: on Android, the target API level requirement makes the app undistributable to new users. On iOS, submitting an update requires a build toolchain upgrade that has itself become a project. What was 15 percent annually has become a rebuild-scale effort.
That final state is the expensive one, and it is reached by inaction rather than by any decision.
The compounding is the point. Fifteen percent of build cost annually, paid, keeps an app current. Skipped for two years, the catch-up work routinely exceeds three years of the maintenance you avoided, because upgrades that would have been incremental have to be done at once.
What a maintenance arrangement costs
| Arrangement | Typical cost | Suits |
|---|---|---|
| Reactive, hourly as needed | $150 to $200 per hour, no retainer | Simple apps, low change rate |
| Basic retainer | $1,000 to $3,000 monthly | Compatibility, dependencies, defect allowance |
| Standard retainer | $3,000 to $8,000 monthly | Above plus monitoring, minor changes, faster response |
| Retainer plus iteration capacity | $8,000 to $25,000 monthly | Products under active development |
The reactive option looks cheapest and frequently is not, because nobody is watching. Problems are discovered by users, and an annual OS release with no prior testing produces a scramble at the least convenient time.
Bolder Apps sells maintenance and staff augmentation alongside fixed-scope project work, and the questions worth settling with any firm before launch rather than during your first incident are what is covered, what it costs, what the response commitment is, and what is explicitly excluded.
Terms to agree before you need them
Five, and the response commitment is the one most often left vague.
A response commitment by severity. What counts as critical, meaning the app is unusable or data is at risk, versus routine, and what response time each carries. Business hours or extended, and in which timezone.
Included hours and the rate beyond them. A retainer with an unstated allowance becomes an argument the first busy month.
What is excluded. New features, major version upgrades, design changes, and third-party service migrations are commonly out of scope, and that is reasonable as long as it is written down.
Who holds the accounts. Developer accounts, cloud infrastructure, and third-party services should be under your ownership with the maintainer added as a user. This is what makes a maintainer replaceable.
Notice and handover. Thirty days is standard, with documentation and credential transfer defined. A maintenance relationship that cannot be exited is a dependency.
The annual OS cycle, planned for
Both platforms are predictable enough that maintenance can be scheduled rather than reactive.
Mid-year, developer betas appear for the autumn releases. This is when compatibility testing should happen, because problems found in the beta window are fixed calmly.
Autumn, public releases arrive and user adoption on iOS is rapid, which means incompatibilities surface within days rather than months.
Through the year, Google Play's target API level deadline and any new policy requirements have published dates. Both are calendar items rather than surprises.
An app on a maintenance retainer should have two scheduled work blocks annually for this, plus the ongoing dependency and defect work. A firm that treats OS releases as unexpected events is not doing maintenance.
Monitoring, and what to actually watch
Four numbers, reviewed at least monthly, distinguish maintenance from waiting for complaints.
Crash-free session rate, by app version and OS version. A drop after a release or after an OS update is your earliest warning and the one users would otherwise report as the app is broken.
Error rates on API calls, including calls to third parties. A silently failing integration is the most common invisible defect.
Store reviews and ratings, read rather than counted. Users describe defects in reviews before they report them anywhere else.
Dependency vulnerability status, from automated scanning with a process for acting on findings rather than a report nobody opens.
Bringing a neglected app back
Apps that have gone two years without maintenance are common, and the recovery is a project rather than a retainer.
Start with an assessment: current framework and dependency versions against supported ones, build reproducibility, whether the app compiles at all on current tooling, store compliance status, and whether anyone holds the signing credentials. That last item ends more recovery projects than any technical finding, because an app whose signing key is lost cannot be updated on iOS and requires a new listing.
Then sequence: get it building on current tooling, upgrade the framework and dependencies in steps rather than at once, bring store compliance current, and only then resume normal maintenance. Feature work waits.
Cost is highly variable and commonly 20 to 50 percent of the original build, occasionally more when a framework has moved several major versions. Which is the arithmetic behind the earlier point: two years of avoided maintenance at 15 percent annually saves 30 percent and costs considerably more than that to recover.
Bolder Apps sells code audits as a standalone engagement, and an audit is the right first purchase here rather than a maintenance retainer, because until someone has established what state the codebase is in, nobody can quote the recovery honestly.
Maintenance versus iteration, kept separate
Confusing these is the most common source of friction in maintenance relationships.
Maintenance keeps the app working as the world around it changes. Iteration changes what the app does. The first is a running cost with a predictable floor; the second is discretionary development with its own budget.
For a product under active development, the sensible arrangement is a maintenance retainer plus separately quoted iteration capacity, so that a busy month of feature work does not consume the budget that was meant to cover an OS release. For a stable product, maintenance alone is correct and iteration is commissioned when there is a reason.
Budget both. A realistic first-year figure is 15 to 20 percent of build cost for maintenance and a further 20 to 30 percent for iteration, and products that fund the first and not the second launch, learn something, and cannot act on it.
Sources
- Apple developer documentation on OS release cycles and SDK requirements, developer.apple.com
- Google Play target API level requirements and policy timelines, support.google.com/googleplay/android-developer
- Apple App Store Review Guidelines, including account deletion requirements
- OWASP Dependency-Check and dependency management guidance, owasp.org
- Firebase Crashlytics and platform crash reporting documentation
.svg){kind=icon}
