Most businesses budget an app as a project: discovery, design, build, test, launch — and an end date. That is a reasonable way to think about a brochure site. For an app it is a mistake, and it surfaces about nine months after launch, when someone reports the app crashing on open on their new phone, or an email arrives saying the next build will not be accepted.
The difference is simple. A website runs in a browser, and browsers go to extraordinary lengths not to break old sites. An app runs on an operating system that ships a major version every year, is packaged by build tooling that ages, and is distributed through a store that revises its terms whenever it likes. An app nobody has touched for two years has not "stayed the same" — it has quietly decayed while no one was looking.
The annual release cycle is your real schedule
Apple and Google each ship a major OS version every autumn. Every one of them brings three things: new behaviours that change how your interface renders, permissions that have tightened, and — in due course — a requirement that your build be compiled against the newer SDK before it is accepted at all.
That last one is what catches unprepared teams. Apple periodically raises the minimum SDK that new submissions must be built against, and Google Play enforces a minimum target API level for updates, restricting store visibility for apps that fall behind. In practice this means that even with no new features planned, a moment arrives where you must ship a release simply to stay in place. If nobody owns that, you discover it at the worst possible time — while trying to push an urgent fix, only to find the project no longer builds.
What erodes while you are not looking
The decay does not arrive in one blow. It accumulates in four places at once.
Third-party libraries. A typical app leans on dozens of external packages. Some get abandoned, some change their interfaces, and some turn out to carry a security flaw that is only fixed in a newer version — which in turn needs a newer version of something else. The longer you wait, the longer the upgrade chain: a day of work becomes a week.
Certificates and keys that expire. Distribution certificates, push notification keys, third-party service credentials — all of them have expiry dates. An expired certificate does not knock over an app that is already installed, but it does block the next build, usually exactly when you are in a hurry.
The backend underneath. The API your app talks to keeps evolving. A server release that stops returning a field the app expects will break a screen for everyone who has not updated — which is most people.
Store rules. Privacy policies, data-collection declarations, accessibility requirements, privacy labels: all of them get revised. A store rejection over an unfilled field costs a week, not an hour.
The number worth knowing
A rule of thumb that holds up in practice: budget annual maintenance at roughly fifteen to twenty percent of the original build cost. That is not paying for nothing. It covers the release cycle, library upgrades, certificate renewals, fixing crashes found in the field, and regression testing on real devices.
Skipping it does not save the cost — it defers it, with interest. An app neglected for three years does not need an update; it needs a full modernisation project, sometimes a partial rewrite, because the build tooling itself no longer supports what was written back then. We have seen this often enough to put it plainly: ongoing maintenance is cheaper than the resurrection that follows neglect.
What a maintenance retainer actually covers
"Maintenance" means different things to different vendors, so it is worth being specific. For us it means four things.
Monitoring. Crash reports from the field, not from your users. When a crash appears on a new OS version, you want to learn it from the data — not from a one-star review.
A planned update cadence. Library upgrades and OS compatibility on a steady rhythm, so the work spreads across the year instead of piling into one impossible block in September.
Releases. Build, sign, upload, track the store review, handle rejections. It sounds like paperwork until you are stuck in it.
A window for small changes. Fixing copy, swapping a banner, adding a form field. The things that never justify a project, but accumulate badly when there is no route to production.
We run retainers like this on monthly and quarterly cadences depending on the size of the app and how fast it changes — deliberately not the same shape for everyone. An internal app with fifty users and a consumer app with tens of thousands of installs do not need the same coverage.
Three checks you can run this week
None of these need an outside vendor. First, open the app on a device running the newest OS and walk the three journeys that matter most — sign-up, your core action, payment if you have one. Second, check when the last build went to the store; if it is more than a year ago, you are already exposed to an SDK requirement. Third, make sure someone knows where the developer account, certificates and keys actually live — too many companies discover that access stayed with a previous vendor at precisely the moment they need to ship an urgent fix.
If any of the three raises a flag, that is the moment to deal with it — not when the app has already stopped building. We have been building and maintaining apps since 2010, and almost every time, the difference between a routine update and an expensive modernisation project is simply how long someone waited.
Want to know where your app stands? Read more about our development services and AI automation — or just get in touch and we will take a look together.