Apple’s App Review Guidelines (October 2026 revision) say an app that no longer works as intended or is no longer actively supported will be removed from the App Store.
That is the short case for app maintenance, the post-launch work that keeps a released mobile or web app working and secure as operating systems change around it. It covers bug fixes, dependency updates, security patches and performance tuning.
Product owners and engineering teams don’t get to set the schedule. Apple, Google and each new OS release do, and the roadmap has to bend around those dates.
What Is App Maintenance?
Maintenance starts at launch and runs until the app is retired, which makes it the last phase of the app lifecycle.
ISO/IEC/IEEE 14764:2022 (Edition 3, published January 2022) treats software maintenance as a process with its own activities and tasks. Its scope text excludes backup, recovery and system administration, which it leaves to whoever operates the software.
App teams read the term more widely. Artoon Solutions’ glossary entry, for one, counts backend support and infrastructure management as part of the job.
In practice, every change made to a shipped build is maintenance after deployment, from a one-line crash fix to a library upgrade.
App Maintenance vs New Feature Development
The dividing line is what the change does to the product.
Work that keeps existing behavior running on current devices, operating systems and APIs is maintenance. Work that gives users behavior they didn’t have before is feature development. Maintenance contracts usually exclude it, so agencies bill it separately (ChopDawg).
Perfective work sits right on the line. Speeding up a slow search screen counts as maintenance. Adding saved searches doesn’t.
I’d write the boundary into the contract before launch. Otherwise every ticket turns into a negotiation.
What Are the Types of App Maintenance?
Corrective, adaptive, perfective and preventive. Nearly all maintenance work fits one of those labels.
Corrective work is the familiar kind: a defect shows up and gets fixed. Adaptive work happens because the platform moved, not because the app broke. Perfective work covers performance and usability improvements, and preventive work removes latent faults before users hit them.
ISO/IEC/IEEE 14764 is the reference for this taxonomy, but its public scope text says only that it establishes definitions for the various types. It does not itemize them.
Most guides list four. TekRevol’s guide reports a fifth, additive type in the 2022 edition for larger feature builds, and the ISO catalogue page does not confirm it.
| Type | Trigger | App example | Timing |
|---|---|---|---|
| Corrective | Crash report or bug ticket | Fix a login failure | After failure |
| Adaptive | New OS, SDK or API change | Rebuild against the Android 17 SDK | Before platform deadline |
| Perfective | Usage data or user feedback | Cut load time on a slow screen | Ongoing |
| Preventive | Code or dependency review | Upgrade a library before support ends | Before failure |
A study archived by the University of Cagliari sorted more than 14,000 issue reports from 34 open source projects into these four types. Resolution time depended on the type.
So plan the backlog by type, not by ticket count. A corrective hotfix and a preventive upgrade do not clear at the same speed.
The same change can land in two types depending on why it is made. A library bump is preventive when done ahead of an end-of-support date and adaptive when a new SDK forces it.
What Does App Maintenance Include?
Bug fixing, dependency updates, security patching, compatibility testing, performance tuning, and backups with server upkeep make up most of it.
What sets each job off differs. Some work is calendar-driven, set by platform releases and store deadlines. The rest reacts to things: crash spikes, security advisories, outages, and the slow screens and drop-offs that user feedback points to.
Bug Fixes and Crash Monitoring
Firebase Crashlytics and Sentry report crashes and errors from live devices, and a Jira queue turns each report into a tracked fix.
Decide the triage rule before launch. A crash on login or checkout outranks any cosmetic bug, no debate needed.
Watch crash-free sessions for each release, and pause the rollout when the number drops.
Dependency Updates and Security Patches
Equifax is the usual cautionary tale, and the details are unflattering. It kept running an unpatched Apache Struts version in its ACIS web portal after the flaw went public on March 7, 2017. The breach reached 148 million people (US House Oversight Committee, 2018).
GitHub Docs describes Dependabot as raising pull requests for security updates and for version updates. Security alerts only fire for vulnerabilities in a published advisory, so version updates catch the libraries that are simply aging.
Skipped updates stack up as technical debt, and every missed version makes the next upgrade bigger.
Android apps pull libraries through Gradle. iOS apps use Swift Package Manager or CocoaPods, and CocoaPods trunk goes read-only on December 2, 2026 (CocoaPods Trunk Read-only Plan). Existing builds keep working, but pods that resolve from trunk stop receiving new versions after that date.
OWASP’s MASVS gives mobile teams a security baseline. Its code controls ask for an app that requires an up-to-date platform version and can enforce app updates.
Compatibility, Performance and Backups
Compatibility work starts at the OS beta, not at the stable release. Teams test on real devices and emulators for each OS version, then move on to performance work like startup, memory and screen-load tuning. The infrastructure side adds database and hosting backups, server upkeep and API deprecation checks.
Each compatibility fix gets a regression testing pass, because a fix for one OS version can break behavior on another.
Third-party APIs retire endpoints on their own schedule, so integrations need a recurring check.
How Often Does an App Need an Update?
Plan for at least one compatibility release per store each year, then add a release for every security patch and crash fix.
Platform owners set that floor. Google and Apple both raised their minimum build requirements in 2026.
Google Play requires new apps and updates to target API level 36 (Android 16) from August 31, 2026. Existing apps need API level 35 or higher, or they drop out of discovery for new users on newer Android versions. On Apple’s side, App Store Connect uploads must be built with the iOS 26 SDK or later from April 28, 2026.
Both dates come from the platforms’ own documentation (Google Play Console Help; Apple Developer news, February 3, 2026). Google lets developers request an extension to November 1, 2026 for apps that need more time.
Existing installs keep working, so the penalty lands on new downloads.
Android adds its own rhythm: a major SDK release in the second quarter and a minor one in the fourth, according to Android Authority. Android 17 (API level 37) reached stable on June 16, 2026.
Some of its behavior changes apply to all apps running on Android 17, whatever the targetSdkVersion. Others apply only to apps that target API level 37, including the end of the large-screen opt-out that SDK 36 offered for orientation and resizability restrictions (Android Developers documentation).
A third-party SDK that lags the platform holds the whole release. OneTrust shipped its 202605.1.0 Spring release with iOS 26 SDK support so apps embedding its mobile SDK could keep submitting after Apple’s April 28 cutoff (OneTrust developer documentation).
Version numbers tell users and teammates what changed. A versioning scheme built on major, minor and patch numbers puts bug fixes in the patch slot, backward-compatible additions in the minor slot and breaking API changes in the major slot (Semantic Versioning 2.0.0).
A fixed release cycle turns these deadlines into scheduled work. Without one, every platform change arrives as an emergency.
What Happens When App Maintenance Stops?
Store visibility has hard numbers attached. Google Play sets bad behavior thresholds in Android vitals: a user-perceived crash rate of 1.09% and a user-perceived ANR rate of 0.47% across all sessions. An app above either line can lose visibility in Play (Android Developers documentation).
Apple is blunter. Its App Review Guidelines, in the October 16, 2026 revision, say an app that no longer works as intended or is no longer actively supported will be removed from the App Store.
Review is a risk of its own. Guideline 2.1 rejects binaries that crash or show obvious technical problems, so the first update after a long gap is also the riskiest one to submit.
Security exposure builds quietly. CISQ’s 2022 report tells teams to monitor third-party components in operation and apply patches in a timely fashion. An unmaintained build does neither, and the catalog of mobile app security threats keeps growing around it.
Integrations can fail without a single change on your side. Third-party APIs retire versions on their own schedule, and a payment or login call that disappears breaks the flow.
Ratings take a hit too. Apple’s guideline 5.6.4 lists negative reviews and excessive refund requests as signs that quality has slipped. It adds that an inability to maintain quality can factor into Developer Code of Conduct decisions.
When Maintenance Is No Longer Enough
Maintenance has a ceiling. CISQ’s 2022 report puts the tipping point where the cost of new features, bug fixes and maintenance exceeds the project budget, a state it calls “technical bankruptcy.”
It also lists signs that an organization is overburdened with technical debt, among them:
- A simple change request turns into a major project
- Unplanned work keeps growing
- Teams decide not to upgrade software that is still in use
- Support cases about core functionality keep rising
Recurring crashes alone point to a bigger maintenance budget, not a rebuild. When all four signs appear, targeted code refactoring of the worst modules comes first, which matches CISQ’s advice to repay technical debt continuously.
A change that once took days and now takes weeks marks a module for refactoring. If most modules behave that way, price a rebuild.
How Much Does App Maintenance Cost?
Budget 15% to 20% of the original development cost per year, and plan for the first year to cost more.
Agency guides repeat that rule, Cleveroad’s June 2026 cost guide among them, and Cleveroad credits it to CISQ. The CISQ 2022 report it links gives no maintenance percentage in its executive summary or its technical debt section, so treat 15% to 20% as a planning default, not a measured constant.
The published first-year figures run higher. ChopDawg puts the first year at 25% to 35%, so $50,000 to $70,000 on a $200,000 app, and Technbrains says up to 50%. For years two and three, ChopDawg drops to 15% to 20%, or $30,000 to $40,000 on the same app, which lines up with the annual rule of thumb of 15% to 20% of original development cost.
Scope moves these numbers. Cleveroad counts small feature enhancements inside its monthly ranges, a bug-fix-only plan leaves them out, and the first production year surfaces defects that testing missed.
By app size, Cleveroad’s ranges run from small utility apps to regulated platforms.
| App size | Typical profile | Annual cost |
|---|---|---|
| Small | One platform, few integrations | $6,000 to $20,000 |
| Mid-size | iOS and Android, backend, payments | $20,000 to $80,000 |
| Complex or enterprise | High traffic, regulated data | $80,000 to $300,000+ |
These are vendor figures, not survey data (Cleveroad, June 2026).
The percentage is taken from the original mobile app development cost, so a cheaply built app looks cheap to maintain on paper. Cleveroad’s code audits suggest otherwise: it reports that apps built with limited engineering investment needed 25% to 40% of their original development cost reinvested in year one to stabilize them.
Platform count, integration depth, infrastructure load and the scope of security and compliance work are what push an app up or down that table.
Who Should Maintain the App: In-House Team, Agency or Freelancer?
Hire in-house only when maintenance fills at least one full-time role. Below that, a retainer or an ad-hoc arrangement costs less and covers more skills, which is Cleveroad’s conclusion too, though an agency has a stake in it.
| Model | Cost pattern | Best fit | Main risk |
|---|---|---|---|
| In-house team | Fixed salaries, paid in quiet months too | Workload that fills a full-time role | Idle capacity |
| Agency retainer | Fixed monthly hours | Mid-size production apps | Scope limits |
| Freelancer | Hourly or per task | Small apps on one stack | Key-person dependency |
| Ad-hoc | Pay per incident | Stable apps that rarely change | Slow ramp-up |
In-House Team
The median software developer earned $135,980 in May 2025, according to the US Bureau of Labor Statistics. That is salary alone.
Benefits, tooling and the QA and DevOps capacity a live app needs come on top, and the roles an in-house team has to cover add up fast.
What you get for the money is full control of the codebase and release access, knowledge that stays in the company, and no contract scope to negotiate. What you pay for is payroll that continues when the backlog is empty, and one departure can remove the only person who knows the build.
Agency Retainer
A retainer buys a block of monthly engineering hours, and ChopDawg notes that most development companies charge for maintenance this way. The fixed fee is the draw. Spend is predictable, QA and DevOps capacity is shared, and nobody sits idle on your payroll.
The catch is that hours cap the response, and new features get quoted outside the retainer. Confirm that line in writing before signing, since vendors split it differently (Cleveroad).
Freelancer
One person, one point of failure.
A freelancer fits a small app on a single stack, and honestly I’d be most careful with this option once real revenue depends on the app. Build and release access sits with one person, and nobody reviews the code. Any gap in availability stops fixes entirely.
Keep the store developer accounts and signing keys in the owner’s name, so a departure never locks the team out of releases.
Ad-Hoc Engagement
Ad-hoc maintenance suits stable apps with low traffic, simple functionality and few integrations, according to Cleveroad. The risk is ramp-up, because a new team needs time to reproduce issues and learn the codebase before fixing anything.
The cost pattern is spiky. Quiet months cost nothing, and a bad month costs a full emergency rate. You only pay for incidents, but nobody owns the backlog between them.
How to Set Up App Maintenance After Launch
Order matters here, so work through these top to bottom.
- Add crash reporting to the release build and pick one crash metric as the release gate. Android vitals reports the share of daily users who hit a crash, while Firebase Crashlytics also reports crash-free sessions, so the same crashes give different rates (Android Developers documentation).
- Route every alert to a ticket in Jira with a named owner.
- Turn on Dependabot alerts and version updates for the repository (GitHub Docs).
- Calendar the platform windows, and use TestFlight for iOS betas, where each build stays available for 90 days (App Store Connect Help).
- Automate the release path with Fastlane and a CI pipeline, then test one hotfix release before you need it.
- Set the maintenance budget and write down response times for crashes, security patches and store deadlines.
Run Dependabot’s pull requests through a pipeline on GitHub Actions, so every update is built and tested before anyone merges it.
Good defect tracking records each crash once, with the build, device and OS version attached, so the fix can be verified under the same conditions.
This setup has weak points. Alerts nobody owns turn into noise, beta builds expire mid-test when nobody refreshes them, and an iOS hotfix still waits in review.
Apple’s guidelines soften the last one. Bug fixes for apps already on the store are not delayed over guideline violations unless the violation is a legal or safety issue, and critical timing issues qualify for an expedited review request.
App Maintenance FAQ
Is app maintenance the same as application support?
No. Maintenance is engineering work on the code, backend, integrations and platform compatibility, while support is user-facing help and incident handling, according to Cleveroad.
Many vendors sell both in one retainer, so check which hours cover what.
How is app maintenance different from application modernization?
Maintenance keeps the existing app working. Modernization re-engineers or replaces the system it runs on.
That makes modernization a project with its own budget, not a recurring line item.
Does a web app need maintenance too?
Yes. A web app skips store review, but it still needs dependency patches, hosting upkeep, backups and browser compatibility checks.
The same maintenance types apply, because they classify changes by intent, not by platform.
Do developers fix bugs for free after launch?
Often, but only for a limited window. ChopDawg reports that most development companies offer a 30-day bug warranty.
After the warranty ends, fixes move under a retainer or per-ticket billing, so read the contract for the end date.
What do Apple and Google developer accounts cost?
Apple charges $99 per membership year, and Google charges a one-time $25 registration fee (Apple Developer, Play Console Help).
Only the Apple fee recurs, so it belongs in the yearly maintenance budget.
Can AI tools lower app maintenance cost?
They speed up triage but do not replace review. CISQ’s 2022 report cites Microsoft’s BugLab, whose best model detected and repaired 26% of the bugs in a 2,374-bug Python test set.
Only 19 of its 1,000 reported warnings were real bugs, so a human still checks every fix.
How do you retire an app you can no longer maintain?
Unpublish it in Google Play Console and remove it from sale in App Store Connect. Per Play Console Help, existing users keep the app and still receive updates, while new users cannot download it.
Keep the backend running until you have told those users, because the installed app still calls it.
What to Cut First When the Maintenance Budget Falls Short
When app maintenance funding covers only part of the year, cut small feature enhancements first and protect platform compliance, security patching and crash fixes.
For a mid-size app, Cleveroad’s June 2026 breakdown prices small feature enhancements at $1,000 to $6,400 per month and store compliance at $50 to $400. Compliance is the cheapest line, and it’s also the one a store can actually enforce. Feature enhancements cost the most, and nobody checks whether they shipped.
A workable order is to pause feature enhancements first, then defer any performance tuning that no metric demands. Compliance, patches and crash fixes stay funded.
The trade-off is a frozen roadmap, so users see no new features until funding returns.
This order holds as of October 2026, and it changes when a store deadline lands inside the budget year, because compatibility work then moves to the top.
- Notepad++ Vulnerability History and How to Stay Safe - October 27, 2026
- What Code-Level Optimisations Technical SEO Specialists Perform - October 27, 2026
- How to Add an AI Support Agent to a SaaS Product: Data, Integration and Guardrails - October 27, 2026
