Launching is the start, not the finish
The app is in the store. Now what happens when iOS ships a new version, Google adds a requirement, or a certificate expires?
On most projects the schedule ends on launch day. The budget is planned the same way.
Then the app goes live and a new schedule begins — one set not by you, but by Apple, Google and the operating systems.
Work that arrives without you asking
Annual OS releases. A new iOS every autumn, a new Android every year. Usually it passes without incident; sometimes a permission behaviour changes, a layout breaks, background rules tighten. It has to be tested.
Store policy changes. Google and Apple regularly introduce new requirements: data safety declarations, target API levels, permission justifications. Ignore them and the app can be removed.
Target API level. Google Play requires apps to target a recent Android version and raises that bar every year. Fall behind and you cannot upload a new build — the existing one stays live, but frozen.
Certificates and accounts. Apple Developer membership is annual. Distribution certificates expire. An expired certificate means you cannot ship a release, and it is usually noticed exactly when an urgent fix is needed.
Dependencies. SDKs for maps, payments and analytics age. Some are retired, some become incompatible.
What these have in common
None of it happens because you wanted it, and none of it adds a feature. The work keeps the app where it already is.
That is why maintenance is not a luxury, it is an operating cost. Left out of the budget, the pattern goes like this: nobody touches it for a year, then one day the app stops opening or disappears from the store, and at that point the job is a year of accumulated updates all at once. Expensive and risky.
The first week after launch
Worth its own heading, because it is the busiest period:
- Bugs on real devices that testing never surfaced
- Usage patterns nobody predicted
- Store reviews — the first ones stay at the top for a long time
- Crash reports
Being able to respond quickly in that first week means the team has to be available. Not scheduling launch right before a holiday is a simple rule that keeps paying off.
No monitoring, no maintenance
If you learn about crashes from a store review, you are already late. At minimum you want:
- Crash reporting
- Server-side error logging
- Basic usage measurement — which screens, how often
These belong in the first release. Adding them later is harder, and you lose the historical data.
A realistic maintenance rhythm
For a small or mid-sized app:
| How often | What |
|---|---|
| Continuous | Crash and error monitoring |
| Monthly | Dependency updates, small fixes |
| Twice a year | Testing against new OS releases |
| Annually | Certificate and account renewals |
Add user-requested changes on top of that and you have the real cost of keeping an app alive.
Why we bring it up early
Discussing maintenance at the quoting stage makes the sale harder. We do it anyway — because we have seen what happens a year later to the projects that skipped it.
Launching is a milestone. The app starting to earn its keep happens after that.