What App Maintenance Really Involves
Last updated:
Why apps decay and websites do not
A website runs in a browser that goes to great lengths to keep old pages working. An app runs on an operating system that deprecates APIs, and in a store that periodically raises its minimum requirements.
The consequence is uncomfortable and worth stating plainly at the point of purchase: an app is not a thing you buy once. It is a thing you keep, and keeping it has a cost.
The question is not whether your app will need maintenance. It is whether you will pay for it annually or in one large bill when it stops being publishable.
The forced work
- Annual OS releases. Two a year to test against. Usually small fixes; occasionally a real change.
- Minimum SDK requirements. Both stores periodically require apps to target a recent version. Miss the deadline and updates are blocked.
- Deprecated APIs. Something you relied on is removed, with notice.
- Store policy changes. New privacy disclosures, new permission rules, new consent requirements.
- Dependency updates. Security patches in libraries, which must be applied and tested.
The ongoing work
- Crash triage — new devices and OS versions surface new crashes
- Support for issues that turn out to be one specific device model
- Backend maintenance, which continues regardless
- Certificate and key renewals, which expire silently
- Review monitoring, since a one-star pattern is a bug report
Certificates deserve their own mention. A push notification certificate expiring quietly is a classic: notifications simply stop, nobody notices for a fortnight, and by then users have stopped expecting them.
What it costs
| Level | Annual cost | Covers |
|---|---|---|
| Minimum viable | 10–15% of build | Compliance updates and critical crashes only |
| Standard | 15–25% | The above plus OS testing, dependencies, small improvements |
| Active development | 30–50% | Continuous feature work |
The minimum keeps the app in the stores. It does not keep it good, and users notice the difference within a year.
The cost of skipping it
An app untouched for two years typically needs: a framework upgrade across several major versions, dependency updates with breaking changes, new privacy disclosures, and fixes for OS behaviour changes.
In practice that lands at 30–50% of the original build cost, done all at once, with no new features to show for it. Paying 15–20% a year is both cheaper and far less disruptive.
Watching the right numbers
- Crash-free session rate — above 99.5% is healthy, and a drop is your first alarm
- OS version distribution among your actual users, which decides what you must support
- Store rating trend, especially after each release
- Reviews mentioning a specific device or version
- Sessions per user, which is the real health metric
We send clients on a retainer a monthly summary of these five. Fifteen minutes of reading, and it catches problems while they are still cheap.
Frequently asked questions
What happens if we do nothing for a year?
Can we do maintenance in-house?
How often should we release?
Is maintenance included in your build price?
Considering an app for your business?
Tell us how often a customer would open it. That one answer usually settles whether you need an app or a much cheaper mobile site.
Related services
What we build for problems like this one