Mobile app maintenance cost: why the 15-20% rule breaks
Mobile app maintenance cost guides quote 15-50% of build cost with no source. Budget from Google Play and App Store deadlines and framework releases instead.
Three agency guides on mobile app maintenance cost, all updated in 2026, give three different rules: 15-20% of the build cost a year, 25-35% in year one, or up to 50% in year one. None of them cites a source for its percentage. This post shows where a maintenance budget really comes from: the dated platform mandates from Google and Apple, the framework release cycle and the monitoring you run. By the end you can set next year's number from a calendar instead of a ratio, and decide who should carry the work.
The short answer for a product head setting next year's budget: the percentage tells you almost nothing about your app. Two apps with the same build cost face the same Google Play target API deadline, the same Xcode upload minimum and the same framework upgrades. What differs is how many platforms, dependencies and integrations each one has to drag through those deadlines.
Is app maintenance really 20% of development cost?
App maintenance is not reliably 20% of development cost, because the figure has no traceable origin. We read the three guides that rank for this query, and each states a percentage as fact without naming a study, survey or dataset behind it.
| Source | Annual maintenance rule it states | Source cited for the figure |
|---|---|---|
| Space-O Technologies (updated 21 October 2026) | 15% to 20% of the initial development cost every year | None |
| Chop Dawg (6 June 2026) | 25-35% of the development budget in year one, dropping to 15-20% in years two and three; notes "some sources cite 30-35%" | None named |
| TechnBrains (updated 13 August 2026) | 15% to 20% on average; up to 50% in the first year; 25-30% for complex apps | None |
The disagreement matters more than any one figure. On a $100,000 build, these rules put year-one maintenance anywhere from $15,000 to $50,000. Space-O's own table turns its rule into $15,000 to $20,000 a year for a $100,000 app, which looks precise but is just the percentage multiplied out. A range that wide is not a budget. It is a sign that the denominator is wrong.
App maintenance cost percentage of development: the strongest case for it
The percentage rule deserves its best defense. If you know nothing else about an app, build cost is a rough proxy for size, and a bigger codebase does need more upkeep. A founder with no engineering history and a board meeting next week needs a number, and a ratio produces one in seconds.
The problem is that the expensive parts of maintenance do not scale with what you spent to build. A $30,000 single-platform app and a $300,000 one both have to meet the same store deadline on the same day. The work that deadline causes depends on how far behind your SDKs, framework and libraries are, and on how many platforms you ship. Build cost also hides a perverse effect: an app built cheaply on outdated dependencies often costs more to keep compliant than one built well, yet the ratio budgets it less.
The mobile app maintenance cost that arrives on a calendar
The largest predictable mobile app maintenance cost is mandated work: changes Google and Apple require before you can ship an update or keep reaching new users. These have dates, and the dates repeat. As of October 2026, these are the requirements on the record.
| Mandate | Date | What happens if you miss it |
|---|---|---|
| Google Play: new apps and updates must target Android 15 (API level 35) | 31 August 2025 | Updates cannot be submitted |
| Google Play: new apps and updates must target Android 16 (API level 36) | 31 August 2026, extension available to 1 November 2026 | Updates cannot be submitted |
| Google Play: existing apps must target API level 35 | In force now | App is not offered to new users on devices running a newer Android version than its target |
| App Store Connect: uploads must be built with Xcode 26 and an iOS 26 SDK | Since 28 April 2026 | Uploads to App Store Connect are not accepted |
| App Store Connect: iOS and iPadOS apps must target iOS 13 or later | Since 9 September 2026 | Uploads to App Store Connect are not accepted |
| App Store Connect: answer the updated age rating questions | 31 January 2026 | Update submissions are interrupted |
The Google rows come from the Google Play target API level requirements, which state that apps targeting a lower level "will only be available on devices running Android OS that are the same or lower than your apps' target API level." The Apple rows come from Apple's upcoming requirements page. If your Android app is still on an extension, our post on the target API level 36 deadline covers what the 1 November cut-off blocks.
The pattern is what you budget against. Google raised the target level on 31 August in both 2025 and 2026. Apple's page lists Xcode upload minimums that took effect on 29 April 2024 and 28 April 2026. As of this writing, Apple has not posted an Xcode 27 upload requirement, so treat a spring 2027 SDK bump as likely rather than announced, and check the page before you lock the budget.
Raising a target level is rarely a one-line change. Google's target SDK migration guide points you to a behavior-changes list for each Android version and asks you to retest permissions handling, Doze and App Standby, and file sharing with other apps. That test pass is the cost, and it scales with the number of features that touch the operating system.
React Native app maintenance cost: two release trains, not one
A cross-platform app adds a second calendar on top of the stores. Expo's documentation states that new Expo SDK versions are released three times each year, and that React Native "currently has six releases per year." Each Expo SDK targets one React Native version: SDK 58 pairs with React Native 0.88 and requires iOS 16.4 or later and Android 7 or later.
That minimum OS line is a budget item people miss. Moving to an SDK with a higher iOS floor means deciding whether to drop users on older devices, which is a product decision, not just an engineering one. We cover what SDK 58 changes in detail in Expo SDK 58 and iOS 27. The practical rule: if you skip SDK upgrades for a year, you do not save the work, you defer it and pay for several upgrades at once, usually under a store deadline.
What does app maintenance include?
App maintenance includes five kinds of work, and only some of them are fixed by the calendar. Separating them is how you stop a single percentage from hiding what you are paying for.
- Mandated platform work. Target API bumps, Xcode and SDK upload minimums, store policy declarations such as age ratings. Dated, non-optional, and the same for every app on the store.
- Framework and dependency updates. React Native, Expo or Flutter upgrades, plus every third-party SDK for payments, maps, push and analytics. Each one has its own release cycle and its own breaking changes.
- OS release compatibility. Testing against each new Android and iOS release and fixing what breaks before users report it.
- Monitoring and fixes. Crash monitoring, triage and bug fixes. The tooling can be free: Firebase lists Crashlytics and Cloud Messaging as no-cost products. The engineering time to act on what it reports is not.
- Accounts and infrastructure. The Apple Developer Program costs $99 a year, and Google Play charges a US$25 one-time registration fee. Backend hosting, databases and third-party API bills usually dwarf both and belong in the same line.
New features are not maintenance. Agency guides often fold enhancements into the maintenance percentage, which is one reason their numbers disagree. Budget feature work separately, against the roadmap, so that a cut to features never quietly becomes a cut to compliance.
How to build a mobile app maintenance budget from the calendar
Mobile app maintenance budget planning works better as a list of dated jobs than as a ratio. This is the sequence we would follow for a live customer app with an Android and an iOS client.
- List every dated mandate for the next 12 months. Start from the Google Play target API page and Apple's upcoming requirements page. Assume one Android target bump around late August and one Apple SDK minimum around late April, and confirm both once announced.
- Map your framework releases. Note your current React Native or Expo SDK version and how many releases behind the latest you are. At three Expo SDK releases a year, a year of skipped upgrades is three upgrades of debt.
- Inventory third-party SDKs. Payments, maps, push, analytics, auth. Each is a dependency that can force an upgrade or block a store bump.
- Estimate each job in engineer-days, not percentages. A target API bump on an app with heavy background work, notifications and file handling costs more than one on a content app. Price the test pass, not just the code change.
- Add a monitoring and fix allowance. Base it on your crash and bug history from the last two quarters, not on a guess.
- Add fixed costs. Store accounts, hosting and API bills, from your actual invoices.
Platform count multiplies most of this. FlashNow, a quick commerce app we built, spans 3 platforms and 4 platform roles, so each store mandate and framework upgrade has to be applied and tested across every client that ships. The same is true of any app with separate customer, partner and admin apps.
Should your build partner or an in-house team carry it?
The right owner depends on the ratio of mandated work to feature work. If most of next year is target API bumps, SDK upgrades and crash fixes, a dedicated in-house mobile engineer will spend long stretches waiting for the next deadline. A partner who already tracks these calendars across several apps can do the same work in focused blocks.
An in-house team is the better choice if you ship features every sprint. Maintenance then rides along with feature work, the team knows the codebase daily, and context switching to an outside partner costs more than it saves. Bringing a partner in for maintenance is the wrong choice if your roadmap is heavy and continuous.
Whichever you choose, insist on one thing: the owner should hand you a dated list of next year's mandated work with an estimate per item, not a percentage. If they cannot, they are not tracking the calendar, and you will find out at the deadline.
If you are deciding whether to hand post-launch work for your Android and iOS apps to a partner, our mobile app development team can review your current SDK, framework and target API versions and give you that dated list of what the next 12 months will require, so you budget the work rather than the ratio.
Frequently asked questions
The annual cost to maintain a mobile app depends on dated platform mandates, framework upgrades, monitoring and hosting, not on build cost. Agency guides quote 15-20% of build cost, 25-35% in year one or up to 50%, but none cites a source, so price each year's mandated jobs in engineer-days instead.
The 20% app maintenance rule has no traceable source. Space-O, Chop Dawg and TechnBrains each state a percentage between 15% and 50% without naming a study, and their figures disagree. Use the percentage as a sanity check at most, and build the real budget from store deadlines and dependency upgrades.
App maintenance includes mandated platform work such as Google Play target API bumps and Apple SDK minimums, framework and dependency updates, OS release compatibility testing, crash monitoring and fixes, and accounts and infrastructure. New features are not maintenance and should be budgeted separately against the product roadmap.
A React Native app needs regular upgrades because Expo ships three SDK releases a year and React Native ships six. Each Expo SDK targets one React Native version and sets minimum OS versions, so skipping upgrades defers the work and stacks several upgrades together, often under a store deadline.
An Android app that misses the Google Play target API deadline cannot submit updates. Existing apps must target API level 35 to stay available to new users; below that, Google Play only offers the app on devices running an Android version equal to or lower than its target.
