Why a "finished" app does not stay finished
Every autumn brings a new major iOS and Android release, and every time something visible changes: a permission that must be requested differently, notification behaviour, a screen area that gets cut differently on new models. In parallel, Google requires updated apps to target a recent API level each year; below that threshold the app stays in the store but can no longer be updated, and eventually disappears for new devices. Maintenance is not insurance sold pre-emptively — it is what keeps the app publishable.
What we actually monitor
Three layers. First, the app itself — crashes, screens closing unexpectedly, network errors, all grouped by version and phone model so you can tell whether a problem is general or device-specific. Second, the services the app depends on — authentication, notifications, your integrated APIs — with periodic checks and history. Third, user behaviour — screens opened, 7- and 30-day retention, the point where people drop out of a flow. The first two tell you whether the app works; the third tells you whether it is still used.
The lifecycle of a new version
An update follows the same steps every time: the change lands in the project, a test build is generated, your team gets it on TestFlight or the Android internal track, it is validated on real devices, then it goes to review. On Android the rollout can be staged and halted the moment the error rate rises. We keep previous builds, so a problematic version can be swapped quickly for the last stable one with nothing to rebuild.
When Apple or Google change the rules
Policy changes come with a deadline and a practical effect: a permission that now needs a written justification, a new declaration about the data you collect, an obligation such as in-app account deletion. We track them and send you, well before the deadline, exactly what has to happen and what we handle. If the change is purely technical, we apply it and re-publish. If it needs a business decision — which data you still collect, for example — we make it together before the deadline, not after the console warning appears.
