Everything that happens after the app ships

There is a moment in every app project where the team celebrates the submission and then discovers that submission is not launch, launch is not done, and done is not a state an app is ever in. What follows is the part nobody puts on a slide.

Review comes first, and most rejections are predictable enough that being surprised by them is a planning failure rather than bad luck. Apple's account deletion requirement, if the app lets people create an account. Privacy labels and the privacy manifest that must match what the code actually collects, including what the third-party SDKs collect on your behalf. An equivalent privacy-respecting sign-in option where third-party sign-in is offered. And guideline 4.2, minimum functionality, which is the polite way of saying that an app which only wraps a website will be refused — the same conclusion this journal reaches for commercial reasons. Prepare for those before submitting and review is a few days. Discover them afterwards and it is a few weeks.

Then the rollout, which should never be all at once. Google Play staged rollouts and Apple's phased release both let a version reach a small percentage of users first, and both are worthless without an agreed halt criterion decided in advance — a crash-free rate below a stated threshold, an error rate above one, a spike in a specific screen. Deciding on the day whether a number is bad enough to stop is how bad versions reach everybody, because by then somebody has already announced the launch.

The most useful capability an app team can have is the ability to fix something without waiting for review. For a React Native codebase, over-the-air updates through Expo cover the JavaScript layer, which is most bugs — a broken flow, a wrong string, a mispriced label — and can be delivered in minutes. What they cannot cover is anything that changes native code, permissions or dependencies, and using them to ship what is effectively a different app is against store policy and worth taking seriously. The correct mental model is a repair channel, not a release channel.

Under both of those sits the discipline that makes the rest work: feature flags. If a release and a launch are the same event, every deadline is a code freeze and every rollback is a resubmission. If the code ships dark and a flag turns it on, the marketing date and the engineering date stop fighting, and a feature that misbehaves is switched off in the afternoon rather than patched in a fortnight.

The health metric is not installs and it is not rating. It is crash-free sessions, watched per version and per OS release, with Android ANRs — application not responding — tracked separately, because a frozen app is a worse experience than a crashed one and does not appear in the crash number at all. Ninety-nine and a half per cent crash-free is a reasonable floor for a consumer app; the useful signal is not the absolute figure but the drop that appears three days after a release.

And then the treadmill, which does not stop. iOS and Android each ship a major version every autumn, and each one deprecates something. Google Play's target API level requirement forces an annual rebuild. Dependencies age out, certificates expire, an SDK you rely on is acquired and sunset. None of it is visible to the customer, all of it is invoiced, and the only alternative is the version of the story where the app stops opening after an OS update and the business finds out from a review.

Which returns to the only number worth putting on a dashboard: the share of people who installed in January and were still opening it in March. Everything above is in service of that. An app that is reviewed, rolled out, monitored and maintained properly is not thereby a good app — but an app that is not will not survive long enough to become one.