What an app costs after launch

The app you shipped in March is not the app you have in December: the platform under it moved and the binary did not. An app nobody touches decays on its own — the system retires something, a login provider changes a screen — and one morning an install that worked is refused. The cost of an app after launch is not a bill you receive; it is a failure you discover, usually in the week you needed it.

What changes underneath an app nobody touches?

Four things, and none of them needs a change from you.

• The operating system version. Each release retires interfaces and changes what a permission means. An app built against an older version keeps working for a while, then appears as a compatibility message, then cannot be installed at all.
• The store's rules. The store writes and revises them, and publishes them on its own pages for your category. Read them there before a release, not in an article, this one included.
• A third-party login. A provider changes its consent screen or retires an older sign-in flow, and the button stops returning a user. Nothing in your code changed.
• A payment provider's integration. It is software with its own versions, and its replacements usually arrive with a deadline attached.

None of this is a defect in your app. It is the platform moving under a fixed artefact: fewer phones can install it, and nobody touched anything.

What are the two kinds of update?

The keep-alive update and the change. Different triggers, different measures of success and, in any honest budget, different money.

Kind	What it does	How it is decided
Keep-alive	Keeps the app installable and the sign-in working	A calendar and monitoring, not a request
Change	Alters what the app does for its users	A business decision with a date and an owner

A keep-alive release adds nothing a user can see. Its measure is "the same app, still installable, still able to log in". Its timing is set outside, which is why it loses against any feature somebody is waiting for.

A change release is a project: specification, estimate, acceptance test, a person who asked for it. Budgeting the two together means the boring one is squeezed every time — until the week the build is refused and the fix is done in a hurry against a queue nobody controls.

Which is the oldest phone you must still support?

The one your users actually hold, and the answer belongs in writing, because it is a business decision rather than a technical default.

The analytics report the system versions of the people who open the app, and the bottom of that list is not noise; it is customers you would be dropping.

Once chosen, the floor is a promise with three obligations: test on a device at that version, keep a build that runs on it, and keep the server answering that build. The third is the one forgotten. An old install calling an endpoint you removed breaks for exactly the users least able to update.

The floor moves when you decide it moves — with a date, ideally a year ahead, and a message inside the app for the people below it.

What does an app need watched?

Crash reports, and a person who reads them. A dashboard nobody opens is decoration.

• Crash reports from the device, carrying the app and system versions. The number that matters is the share of sessions that ended in a crash, per version.
• A release check. Compare each new version's figure with the previous one. A jump is a decision within hours, not a ticket for next month.
• A sign-in failure count. Authentication breaks are what support hears about first and what monitoring misses.
• A named reader. Not a channel, not "the team": one person, one weekly habit, and a rule for when the number moves.

When is an app the wrong answer?

When the usage is monthly or rarer.

An installed app earns its place when the work is frequent, or when it has to happen where no browser is: a stockroom, a van, a site with no coverage. If a customer opens it once a month to look at a bill, the arithmetic inverts:

• the install is forgotten, and the icon is buried on a third screen;
• the update is skipped, so the version you support is not the one they run;
• the notification is muted after the second one, and the channel is gone;
• and the review queue delays the fix for the one thing that broke.

A responsive site or a page inside the system they already use does that job with no install and no queue. An app used monthly is a maintenance bill for a feature nobody opens.

How do you budget and run it?

1. Write the floor: the oldest system version supported, and the date it will be reviewed.
2. Write the keep-alive work per period — the work, not a figure — and put its dates in a calendar.
3. Keep the change list separate, with a written specification and an estimate for each item on it.
4. Ship crash reporting with the first release, the app version attached to every report, and name the reader.
5. Keep a test device at the floor, and the last good build beside the server that answers it.
6. Fix the weekly ritual: crash share, sign-in failures, oldest supported version.
7. Read the store's current rules for your category before each release, at the source.

Where this goes wrong

• One release a year, in December. That is a project, not a patch: the toolchain moved, a dependency has a deadline, and the person who set it up has left.
• Keep-alive money spent on features. The visible thing ships; the thing that keeps the app installable waits until it is urgent.
• The floor is raised silently. People on older phones see a compatibility message and leave, and no chart records them.
• An app kept for a task it does not fit. The install base decays quietly, and the bill does not.

What this does not cover

It quotes no figures — not for a retainer, not for store fees, not for one update — because those move by programme, region and provider, and a number in an article is wrong before it is read. It does not restate store policy: the rules are the store's, they are revised, and they must be read there for your category before anyone promises a date. It does not claim to know which framework will still be maintained in five years; nobody does. And it is not an argument against apps — a field team with a van and a stockroom is precisely the case where an app is right.

We build apps that are meant to be kept alive, and we say so when the honest answer is not an app.