An app keeps needing work after it launches. Plan the budget and the contract for ongoing work at the same time as the build, so updates don't turn into emergencies.
Why apps need regular updates
- Apple and Google release major iOS and Android versions every year. New versions can change permissions, background behavior and interface details, so test against the betas before release.
- Google Play requires apps to target a recent Android API level by set deadlines, or updates can be blocked and the app can become harder to find for users on newer devices. Apple periodically requires builds made with recent versions of its tools.
- Frameworks, plugins and SDKs release updates and security fixes, and sometimes stop supporting older versions.
- Signing certificates, some push notification credentials and API keys expire or rotate, and must be renewed before they lapse.
- If a connected service or your own backend changes its API, the app has to change too.
- Crash reports arrive from devices and OS versions nobody tested.
Store policy changes also affect each update you submit, as described under App Store and Google Play review.
App support plans: retainer, maintenance-only or on request
| Arrangement | How it works | Suits |
|---|---|---|
| Monthly retainer | A set block of hours each month for updates, fixes and small features | Apps with steady use and regular change |
| Maintenance-only plan | OS compatibility, dependency and store-requirement updates, critical fixes | Stable apps with few new features planned |
| On request | Work estimated and billed per job | Simple internal apps, low change |
Support terms to put in writing
- What counts as a critical issue, and how quickly someone starts on it.
- What's included (OS updates, dependency upgrades, monitoring) and what's quoted separately (new features).
- Whether unused hours roll over.
- Who watches crash reports and store emails, and who renews certificates.
- How the arrangement ends, and what is handed over if it does (see the handover checklist).
Crash reporting and usage monitoring
Crash reporting and basic usage analytics show what's breaking and which features people actually use. Any SDK you add has to be reflected in your store privacy disclosures, so keep monitoring to what you'll act on.
What affects app maintenance cost
The number of platforms and codebases, how many third-party SDKs the app depends on, the size of the backend, how often you want new features, and how well the app was kept up to date before. An app left untouched for several years usually needs a bigger catch-up effort before new work can start.
App maintenance questions
How often does an app need updating?
At the very least, check it against each yearly iOS and Android release and each store requirement deadline. Beyond that it depends on how often your dependencies, integrations and feature plans change.
What happens if we stop maintaining the app?
It may keep working for a while, but OS changes, expiring credentials and store requirements catch up with it. On Google Play, missing a target API level deadline can block updates. Catching up later usually takes more work.
Can a different developer maintain an app we already have?
Usually, if you have the source code, the developer accounts and access to the backend. Expect a code review before the new developer takes on changes.
Already have an app that needs updates? Describe it in your brief, including who built it and what access you have.
Send a project brief