Mobile apps live in a fast-moving environment controlled by two companies. Apple and Google release new operating system versions every year, update their store requirements, deprecate old interfaces and launch new devices. An app that nobody touches can start misbehaving, lose visibility in the stores or become impossible to update in a hurry. App maintenance is the planned work that prevents this. This article explains what drives it, what a yearly maintenance rhythm looks like and how to budget for it.
Why mobile apps need more upkeep than you might expect
Annual operating system releases
Apple typically previews the next iOS at its developer conference in early summer and releases it in the autumn. Google also ships a major Android version each year. New versions can change permission behaviour, background execution limits, notification handling, privacy prompts, and the look of system controls. Some changes only take effect when your app is rebuilt against the new SDK, but users install the new OS regardless, and existing apps occasionally break.
Store requirements that move
- Google Play requires new apps and updates to target a recent Android API level, and raises the requirement on a regular schedule. Apps that fall too far behind may become unavailable to new users on newer Android versions.
- Apple periodically requires submissions to be built with a recent version of Xcode and the iOS SDK.
- Both introduce new privacy declarations, policy rules and account requirements, often with deadlines.
Because these deadlines arrive whether or not you plan new features, they are the most important reason to keep the app's build setup current. Check the official Android target API requirements and Apple's developer news for the current rules.
Third-party SDKs and libraries
Payment, maps, analytics, crash reporting and login SDKs release updates for security fixes, new OS support and their own API changes. Older SDK versions are eventually retired, sometimes cutting off functionality for apps that have not updated.
Cross-platform framework upgrades
If your app uses Flutter or React Native, the framework itself needs periodic upgrades to keep up with new OS versions and store requirements. Skipping several versions turns a routine task into a substantial project.
Certificates, keys and credentials
Signing certificates, provisioning profiles, push notification credentials and API keys have expiry dates or rotation needs. An expired credential can break notifications or block an urgent release.
Devices and screens
New phones bring new screen sizes, cut-outs, foldables and tablets. Layouts that looked perfect on last year's devices may need adjusting.
The old-version problem
Unlike a website, you cannot instantly replace every copy of your app. Users update at their own pace, some have automatic updates turned off, and some devices cannot run your newest version. Your backend therefore serves several app versions at once. Good practice includes:
- Versioned APIs, so a backend change does not break older apps.
- A minimum supported version, checked when the app starts, with a polite prompt to update when an old version can no longer work safely. Google Play offers an in-app updates API that helps on Android.
- A policy on supported OS versions, reviewed yearly, balancing reach against the cost of supporting old systems.
A yearly app maintenance calendar
| When | Activity |
|---|---|
| Continuously | Monitor crash reports, performance, API errors and store reviews; fix critical issues |
| Monthly | Review dependency and SDK updates, especially security fixes; check store policy announcements |
| When OS betas appear | Test the app on beta versions of iOS and Android; plan required changes |
| Before new OS public release | Ship compatibility fixes so the app works on day one |
| Ahead of store deadlines | Update target API level, Xcode and SDK versions, privacy declarations |
| Quarterly | Upgrade the cross-platform framework if used; review minimum supported OS and app versions |
| Yearly | Check expiry dates for certificates and credentials; review device test coverage; plan larger refactors |
Backend maintenance is part of app maintenance
The servers, database and APIs behind your app need their own patching, backups, monitoring and scaling. Certificate expiry on the API domain is a classic cause of sudden app-wide failure; our SSL checker shows expiry dates at a glance. Server-level upkeep is covered by our server management service.
What drives app maintenance cost
There is no single right figure, but these factors determine where yours sits:
- Number of platforms and codebases: two native apps need roughly twice the client-side upkeep of one cross-platform app.
- Number of third-party SDKs and integrations: each is a source of updates and occasional breakage.
- Use of platform-specific features: background tasks, widgets, Bluetooth and similar features are more affected by OS changes.
- Automated test coverage: good tests make upgrades faster and safer.
- Code health: well-structured code with current dependencies is cheaper to keep current.
- Support expectations: guaranteed response times, out-of-hours cover and the range of devices and OS versions supported.
Many organisations set aside a recurring annual budget for maintenance, separate from new features. Agree with your development partner what it covers: compatibility updates, store compliance, dependency upgrades, bug fixes and monitoring.
Signs your app has fallen behind
- Store warnings about target API level or SDK deadlines.
- Rising crash rates on the newest OS version.
- Reviews mentioning layout problems on new devices.
- A build that no longer compiles with current tools, making an urgent fix slow.
Our mobile app development team offers maintenance arrangements built around this calendar.
Key takeaways
- Annual OS releases, store deadlines and SDK updates make maintenance unavoidable.
- Plan around a yearly calendar: test on betas, ship compatibility fixes early and meet store deadlines.
- Support old app versions with versioned APIs and a minimum-version check.
- Cost depends on platforms, SDKs, platform features, test coverage and support expectations.