After Your App Goes Live: Maintenance and Version Management

Maintenance means keeping the app's libraries, operating system compatibility and store policy compliance current; it is a separate job from adding new features, and it runs on a regular, predictable schedule.

An app is not a product you write once and leave; like any live software, it needs to change as the environment around it changes.

The distinction is worth stating plainly: maintenance keeps the app standing as it is; new feature work grows it. The same team can do both, but they need separate budget lines, otherwise maintenance quietly loses out to growth work every time.

Apple and Google each release one major operating system version a year; with each release, some APIs get deprecated and some permission behaviours change. Code that ran fine the previous year can behave unexpectedly on the new version.

That is why the app needs testing against each major OS release as it appears; delaying that test tends to show up as user complaints.

A permission prompt that used to be one screen, for instance, can split into two steps on a new release; the code still runs, but the user never sees the screen they expected. Changes like this only surface in real testing, not in a code review.

Google Play raises its minimum target API level every year; apps left below it lose the ability to be newly installed or updated. That means the app can effectively disappear from the store even if the code itself has not broken.

On Apple's side, similarly, apps compiled against an old SDK eventually stop being accepted for submission; that is why an annual rebuild and test cycle is part of the job.

What works in practice is defining two or three fixed maintenance windows a year: library updates, new OS testing, store policy checks. Outside those windows, only a genuinely critical bug triggers urgent work.

• Compatibility testing when a new OS version releases
• A rebuild when the store's target API/SDK requirement updates
• Security updates for third-party libraries in use
• Regular review of user feedback and crash reports

In the mildest case, the app slowly degrades or throws errors on some screens. In the worst case, the store closes it to new users, or removes it entirely, once the target API level falls too far out of date. Both take time to reverse.

A furniture workshop's dealer app, left untouched for two years, lost the ability to be freshly installed once Google Play raised its target API level; dealers who changed phones could no longer reinstall it. The fix itself took a week, but noticing the problem took almost six months, because no one was checking regularly.

In a small business, telling one person 'can you also look after the app' sounds simple, but maintenance ends up squeezed between that person's actual job and gets pushed back every time. This is the most common way maintenance quietly stops happening.

The decision test is this: is the app's annual maintenance load (testing, rebuilding, store checks) small enough to be one person's regular, repeatable task, or does it need its own budget and schedule. If the latter, handing maintenance to an outside team under a standing arrangement stops the work from getting lost in the gaps.

The most frequent mistake is treating maintenance as 'we will deal with it if something breaks'; store requirements arrive quietly, without an obvious problem first, and the app can drop out of the store before anyone notices. Maintenance needs to be scheduled, not reactive.

The second is testing a new OS release only once it ships officially; testing from the moment the beta appears gives time to catch and fix issues before the public version lands.

• Only remembering maintenance once something breaks
• Testing a new OS only on its official release
• Leaving maintenance to one person with no written schedule