What Happens After Launch: Mobile App Maintenance

A website left alone for two years is dated. A mobile app left alone for two years is often broken, sometimes removed from the store, and occasionally impossible to rebuild without a week of work before anyone writes a line of new code.

The difference is that an app sits on top of two platforms that keep moving. Apple and Google both ship a major OS release every year and change their store requirements more often than that. Your app does not have to change for its situation to change.

Maintenance is not the same as bug fixing

Most founders picture maintenance as fixing things users complain about. That is part of it, and usually the smaller part.

The larger part is keeping the app compatible with an environment that changes underneath it. None of that work is visible to users. Done well, nobody notices anything at all - which is precisely why it is the first thing cut from a budget and the first thing to cause a problem.

Maintenance is the work that keeps an app exactly where it is while everything around it moves.

What upkeep actually consists of

Six recurring jobs cover almost all of it.

Two of these have hard deadlines attached. Certificates expire on a fixed date, and store requirements come with a cutoff after which you cannot submit an update at all. Missing either is not a degradation, it is a stop.

What happens to an app left alone

Nothing, for a while. That is what makes this easy to defer.

Then a new OS release lands and a feature starts behaving oddly on the newest phones - often something specific like a camera flow, a notification, or a screen that suddenly renders wrong on a new device size. Support requests arrive, and they are all from users on recent hardware.

Meanwhile the store requirements have moved. To publish a fix, you now need to target a newer SDK version, which requires updating dependencies that have each moved several versions, some with breaking changes. What should have been a one-day fix has a week of upgrade work in front of it.

And unpatched dependencies are a security matter as well as a compatibility one. A library with a known vulnerability is a published, searchable description of a weakness in your app.

Where those weaknesses tend to appear, particularly in code assembled quickly, is covered in our post on security flaws in AI-generated code.

The compounding problem

Maintenance deferred does not stay the same size. Each skipped update makes the next one harder, because upgrades that would have been incremental become one large jump across several breaking changes at once.

A codebase updated every few months is a routine job each time. The same codebase updated after two years of silence is a project, with its own testing effort and its own risk of regressions - and it has to be done before any new feature can ship.

This is ordinary technical debt, accumulated by doing nothing rather than by taking shortcuts.

The mechanics of that, and how to decide what is worth paying down, are in what is technical debt.

What good maintenance looks like in practice

It is not a retainer with an unspecified number of hours. It is a small set of specific commitments.

• Dependencies reviewed and updated on a regular cadence, not when something breaks.
• Compatibility with each new iOS and Android release verified during the beta period, before users are on it.
• Crash reporting and error monitoring in place, with someone actually reading them.
• Certificate and key expiry dates tracked, with a reminder well ahead of the date.
• Store policy changes watched, so deadlines are met rather than discovered.
• A stated response time for anything that stops users completing the app's main task.

Notice how much of that is scheduling rather than engineering. A large share of maintenance failures are calendar failures.

Who should do it

Three arrangements, each reasonable in different circumstances.

Keeping it with the team that built the app is the most efficient option while the product is still evolving, because nobody has to rediscover the reasoning behind the code. It works best when the scope is written down rather than assumed.

Ad-hoc arrangements suit stable apps that genuinely change little, on the condition that the annual compatibility work is still booked deliberately. Ad-hoc in practice often means nothing happens until something breaks, which is the expensive version.

Bringing it in-house makes sense once the app is central enough to justify a permanent engineer. The transition needs a real handover - repository, accounts, documentation and a walk through the architecture - not just credentials sent over email.

Whichever you choose, the accounts and the code should already be in your name. That is what makes changing arrangements a decision rather than a negotiation.

If your app has already drifted

Plenty of apps are in this position: live, still used, and nobody has touched the code in a year or more. The situation is recoverable, and it is worth knowing the size of the job before committing to it.

The sensible first step is an assessment rather than a rescue - can the current codebase still be built and released, how far behind are the dependencies, what does the store require now, and is anything expiring soon. That produces a real decision between updating what exists and replacing part of it, instead of a guess.

That assessment is exactly what our app audit and takeover service.

Frequently asked questions