After launch an app needs platform updates (new iOS and Android versions, store policy changes), dependency and security updates, monitoring for crashes and performance, bug fixes and usually new features. Plan for it from day one: an app that is not maintained gradually breaks, even if nobody touches its code.
Why apps need maintenance even when nothing changes
Software runs on top of things that keep moving: operating systems, browsers, app-store rules, third-party APIs and the open-source packages inside your code. Each of them changes on its own schedule. An app left untouched for a year or two will often stop building, show warnings, or be blocked from store updates until it is brought up to date.
The five kinds of maintenance work
- Platform updates. Apple and Google release major OS versions every year and periodically raise the minimum SDK version that store updates must target. Apps need testing and sometimes code changes to keep up.
- Dependency and security updates. Frameworks and libraries ship fixes, including security patches. Staying reasonably current avoids painful jumps later.
- Monitoring. Crash reporting (for example Crashlytics or Sentry), uptime checks and performance tracking tell you about problems before your users do.
- Bug fixes. Real-world use always finds edge cases that testing missed.
- Improvements. New features, design refinements and changes driven by feedback and analytics.
How to budget for maintenance
A figure often quoted in the industry is roughly 15–20% of the original build cost per year. Treat that as a starting point, not a rule. The real number depends on:
- How many platforms you support (iOS, Android, web) and how many integrations you rely on.
- How much new feature work you want each quarter.
- How critical uptime is: an internal tool and a payments app need very different levels of monitoring.
- The quality of the original codebase. Clean architecture, tests and documentation make every later change cheaper.
Signs an app is not being maintained well
- Store reviews mention crashes after an OS update.
- Releases are rare and every update feels risky.
- Nobody can say which versions of key libraries the app uses.
- The team learns about outages from customers.
- Only one person knows how to build and release the app.
Keeping maintenance cheap
The cheapest maintenance is the kind you design for: a shared codebase where it makes sense (one reason we build mobile apps in Flutter), automated builds and tests, crash reporting from day one, and documentation that lets any competent team pick the project up. And make sure you own the repository, the store accounts and the cloud accounts, never a vendor.