Mobile apps carry a maintenance floor that exists independently of your roadmap. Two OS releases a year, SDK deprecations, certificate expiries and store policy changes all generate mandatory work. Budgets that fund only feature development discover this as a series of urgent interruptions.
01The work that arrives whether you plan it or not
Both platforms ship a major OS version annually, each with behaviour changes, deprecations and eventually a minimum SDK requirement for store submissions. Missing that requirement means you cannot ship at all until you comply.
Third-party SDKs deprecate on their own schedules, and security-critical ones cannot be deferred indefinitely. A payment or authentication SDK reaching end of life is a hard deadline set by someone else.
Certificates and provisioning profiles expire on fixed dates. So do the API keys and push credentials your app depends on. None of these care about your sprint plan.
- Annual OS compatibility work for both platforms, including testing on new versions before public release.
- Minimum SDK bumps required for continued store submission, which can force dependency upgrades.
- Security patches in dependencies, some of which are urgent rather than scheduled.
- Certificate, profile and credential renewals with hard expiry dates.
- Store policy changes - privacy labels, permission justifications, account deletion requirements - that have arrived repeatedly in recent years.
02Putting a number on it
As a planning figure, a live mobile app with an active user base needs meaningful engineering attention every month even with no new features, and more in the weeks around major OS releases.
The variable that dominates is dependency count. An app with a large third-party surface inherits every one of those maintenance schedules; a lean app inherits far fewer.
The second variable is how far behind you let things drift. Staying current is routine work spread across the year. Catching up after two years of neglect is a project, because upgrades compound and you can no longer isolate which change broke what.
03What happens when it is not funded
The predictable sequence: the app falls behind minimum SDK requirements, a security patch cannot be applied because the dependency chain is too old, and a store policy change arrives that cannot be met within the release window.
At that point a routine update becomes an emergency modernisation, usually at the least convenient moment, and often with the original team no longer available.
The apps we are most often asked to take over are in exactly this state. The work is rarely difficult; it is just much larger than it needed to be.
04Budgeting it honestly
Treat maintenance as a standing allocation rather than a contingency. A fixed monthly capacity that absorbs OS releases, dependency upgrades and store changes keeps the app shippable and makes feature planning predictable.
The alternative is not cheaper. It defers the same work into larger, worse-timed chunks and adds the cost of an app that periodically cannot ship.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer