App maintenance: what breaks every year without you touching it
An app that is never updated stops working within a couple of years. The yearly forces that break it, what maintenance must cover, and how to budget for it.
The short answer
A finished app is not finished. Every year, forces outside your control change the ground it stands on: new operating system versions, new store rules with deadlines, expiring certificates, vulnerabilities in the libraries it is built from, and changes to the services it talks to. An app that is never updated meets each of them in turn and eventually stops working, is removed from a store, or becomes a security risk. Maintenance is what keeps that from happening, and it is a budget line from the day the app is planned.
What breaks, and when
| Force | What happens | Typical timing |
|---|---|---|
| Operating system update | Behaviour changes, features are deprecated, permissions work differently, the app crashes or looks wrong | Every year, with a beta period to prepare |
| Store rule change | A new requirement, such as a privacy declaration or an API level, with a deadline; non-compliant apps are blocked from updating or removed | Several times a year |
| Signing certificates and keys | Expire; without renewal, updates cannot be published or the app stops launching | Yearly or on a set schedule |
| Library vulnerabilities | A security hole is disclosed in a library the app uses; the app must be rebuilt with the patched version | Continuously |
| Third-party services | A payment, maps or analytics provider changes or retires an interface | Yearly, with notice you must be watching for |
| Device changes | New screen sizes and capabilities the app does not handle | Yearly |
Native apps meet every one of these on each platform separately. Hybrid apps meet them once with wrappers. Progressive web apps meet the fewest, because the browser absorbs most platform change.
What maintenance must cover
- A release cadence. At least quarterly, so the app is never far from a working build and stores never see it as abandoned.
- Operating system readiness. Testing on beta versions before each yearly release; fixing what changed.
- Store compliance. Watching rule changes and meeting deadlines before they become removals.
- Dependency patching. Routine updates of libraries, prompt updates when a vulnerability is disclosed.
- Certificates and keys. Renewed on schedule, stored in the company’s password manager.
- Monitoring. Crash reports and failure rates watched, so a break is known before users complain.
- Service changes. Provider announcements tracked; interfaces updated before the old ones are switched off.
Budgeting for it
Treat yearly maintenance as a fixed share of the build cost, agreed at the start and reviewed yearly, covering the seven items above. For a native app on two platforms, expect it to be higher. For a progressive web app on a shared backend, expect it to be modest. If the budget cannot be found, that is information about whether the app should be built as an app at all.
What this means for you
If you have an app, check when it was last released and whether the seven items have an owner. If you are planning one, put maintenance in the budget from day one, prefer the architecture that carries the least of it, and treat a quarterly release as the minimum sign of life. Apps do not break because you changed something. They break because everything else did.
Frequently asked questions
The app works fine. Why would it break?
Because the world around it moves. The operating system updates and changes behaviour or deprecates a feature. A store changes a rule and requires an update within a deadline. A signing certificate expires. A library the app depends on has a vulnerability disclosed. A service the app talks to changes its interface. Each is a year-one event.
How much maintenance does an app need?
Enough for at least a release per quarter, prompt updates when an operating system or store deadline requires them, dependency patching on a routine, and monitoring of crashes and failures. For a native app on two platforms, double the release work. A progressive web app needs the least, because the browser absorbs most of the platform change.
Can we skip maintenance if the app is internal?
Internal apps still run on devices that update, still depend on libraries with vulnerabilities, and still talk to services that change. They can skip store compliance if distributed internally; they cannot skip the rest.
Sources
- Apple: App Store Review Guidelines (accessed 2026-09-11)