App maintenance and support services: what's covered, which deadlines matter, and what to budget

Apps break slowly when nobody maintains them. Here's what maintenance should cover, the 2026 store deadlines that force updates, how SLA tiers differ and how to budget.

An app that nobody touches after launch doesn't stay the same. It slowly breaks. Apple and Google raise their technical requirements every year, third-party SDKs deprecate old versions, new devices expose layout bugs, and security patches pile up. App maintenance and support services exist to keep the app shippable, stable and secure, so that when you want to release a feature, you can.

This guide explains what maintenance actually covers, the store deadlines that drive it, how SLA tiers differ, and how to budget for it each year.

What app maintenance and support services cover

Maintenance work falls into four buckets. A good contract names all four.

New features are not maintenance. Many teams bundle a small number of enhancement hours into a support plan, which is useful, but keep the line clear so maintenance doesn't get squeezed out by feature requests.

The store deadlines that force updates

Both stores set requirements that apply to any new upload, including bug-fix releases. If your app falls behind, the next urgent fix can't ship until the upgrade is done.

• Google Play target API level. From August 31, 2026, new apps and updates must target Android 16 (API level 36), with an extension available on request to November 1, 2026. Existing apps that target Android 14 or lower become unavailable to new users on newer Android versions. Details are on Android's target API level requirements page.
• Apple SDK minimums. Since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK (or the equivalent for other Apple platforms), according to Apple's upcoming requirements page.
• Policy and privacy changes. Both stores update data safety, privacy and age-rating requirements periodically. Apple, for example, required developers to answer new age rating questions by January 31, 2026 to avoid interruptions when submitting updates.

The pattern repeats every year: new OS versions arrive in the autumn, and store requirements follow over the next year. A maintenance plan should put these dates on a calendar months ahead, test on beta OS releases over the summer, and ship the compliance update well before the deadline.

SDK and dependency updates

A typical app depends on dozens of third-party packages. Each one is a small supply chain:

• Framework upgrades. Flutter, React Native and the native toolchains ship major versions regularly. Skipping several in a row turns a routine upgrade into a multi-week project.
• Marketing and analytics SDKs. Attribution, analytics and ad network SDKs must stay current to keep measurement working and to meet privacy requirements such as Apple's privacy manifests.
• Payments and authentication. Payment SDKs and login providers deprecate old API versions, sometimes with only a few months' notice.
• Abandoned packages. Some open-source libraries stop being maintained. Part of maintenance is spotting these early and replacing them.

Ask your support team for a dependency report each quarter: what's outdated, what's deprecated, and what it would take to update.

Crash monitoring and triage

Stability work starts with visibility. At minimum you want a crash reporting tool (Firebase Crashlytics or Sentry are common), Google Play's Android vitals, and Xcode Organizer data for iOS. Google Play uses vitals such as crash and ANR rates in its store quality signals, so poor stability can affect visibility as well as reviews.

A simple severity model keeps triage honest:

1. Severity 1: the app won't open, login or payment is broken, or data is exposed. Fix immediately and hotfix.
2. Severity 2: a core flow fails for a meaningful group of users or devices. Fix in the next release, usually within days.
3. Severity 3: cosmetic or edge-case issues. Schedule into normal releases.

Agree on what counts as each level in writing. Most disputes about support quality are really disputes about severity.

Security maintenance

Security is the bucket most often skipped and the one that hurts most when it is. Include:

• Regular scans for known vulnerabilities in app and backend dependencies, with patches applied on a set schedule.
• Operating system and runtime updates on servers, or managed services that handle them.
• Rotation of API keys, signing credentials and certificates before they expire, with a record of where each lives.
• Backup checks, including an occasional test restore.
• Access reviews: remove former staff and contractors from repositories, cloud and store accounts.

For regulated apps, such as fintech or healthcare, your compliance obligations may set specific patch windows. Build those into the SLA.

SLA tiers: what you're actually buying

Support plans usually come in tiers. The figures below are typical examples to frame a conversation, not market benchmarks; every vendor sets its own.

Response time is not fix time. Ask for both, and ask what happens when the vendor misses them.

Typical annual maintenance cost

A widely used planning rule of thumb is to budget around 15–20% of the original build cost per year for maintenance. Treat it as a starting point, not a benchmark. Apps with many integrations, payments, or regulatory requirements usually need more; simple content apps often need less.

Your annual budget typically has four parts:

• Support plan or retainer: the engineering time for the four buckets above.
• Third-party services: crash reporting, analytics, MMP, SMS/OTP, maps and other usage-based tools.
• Infrastructure: hosting, databases, storage and bandwidth, which grow with users.
• Store accounts: Apple's annual developer program fee and any paid tooling.

What pushes the engineering part up or down:

• Number of integrations. Every payment provider, login method, ad SDK and external API is something that can change underneath you.
• Codebase age and health. An app several framework versions behind, with no automated tests, costs more to keep current than a well-kept one.
• Release frequency. Frequent releases mean more regression testing and store submissions.
• Regulatory load. Fintech, health and children's apps carry extra review, logging and patching obligations.

If you're still at the planning stage, our app development cost guide shows how build choices affect long-term running costs. If you need ongoing feature work as well, a dedicated development team may be better value than a support plan plus ad-hoc projects.

What to put in a maintenance contract

• The four buckets listed explicitly, with what's in and out of scope.
• Severity definitions, response times and target fix times.
• A release cadence, and who submits builds to the stores.
• A named contact and an escalation path.
• Access arrangements: your repository, your store accounts, your cloud, with the vendor added as users.
• A handover clause: documentation, credentials and a knowledge-transfer session if you change vendors.

Taking over an app built by someone else? Expect an initial audit before a vendor commits to an SLA. That's a good sign, not a sales tactic. If store submissions are part of the scope, see our store submission checklist.

Maintenance at Appryze

We build Android, iOS (native Swift or Flutter) and web apps from Delhi for clients in the USA, UK, UAE and India, and support them after launch. Support work is tracked in your repository and reported in weekly written updates, with call times that overlap US business hours. You keep ownership of the code and every account. See our Studio page to start with a quote.

Frequently asked questions

What do app maintenance services include?

Usually four things: platform compliance (new OS versions and store requirements), dependency and SDK updates, stability work such as crash fixes and performance, and security maintenance including patching, key rotation and backups. Some plans add a small allowance of enhancement hours, but new features are normally scoped separately.

How much does app maintenance cost per year?

A common planning rule of thumb is 15–20% of the original build cost per year, but it varies widely. Apps with payments, many integrations or regulatory requirements usually need more, while simple apps need less. Add third-party services, hosting and store account fees to the engineering cost.

How often should a mobile app be updated?

Most actively used apps release at least monthly, and every app needs updates at least once or twice a year to keep up with new iOS and Android versions and store requirements. Security fixes and critical bugs should ship as soon as they're ready, outside the normal schedule if necessary.

What happens if I don't update my app for Google Play's target API requirement?

You won't be able to publish new versions, including bug fixes, until the app targets the required API level. Existing apps that fall too far behind also become unavailable to new users on newer Android versions. For 2026, new apps and updates must target Android 16 (API 36) from August 31, with extensions possible to November 1.

What is a good SLA for app support?

It depends on how critical the app is. Revenue-critical apps usually need a response to severity 1 issues within about an hour, including out of hours, while stable, low-change apps can work with next-business-day response. Always agree on both response time and target fix time, with clear severity definitions.

Keep reading

More in App Maintenance & Support Services · All app development guides