On this page · 8 sections
Summary. Ask five agencies what app maintenance costs per year and you get five numbers, usually quoted as a percentage of build cost, all of them invented. Here is the part that is not negotiable. Since 28 April 2026, Apple requires every app uploaded to App Store Connect to be built with Xcode 26 or later against the iOS 26 SDK. Google Play enforces a target API level every 31 August: from 31 August 2025, new apps and updates must target Android 15 (API level 35) or higher, and apps still below Android 14 (API level 34) stop being discoverable to new users on newer devices, with extensions available to 1 November. Neither deadline cares whether you shipped a feature. Neither is optional if you want to stay in the store. Add the Apple Developer Program at $99 per membership year, about ₹9,431 at ₹95.26 to the dollar, and you have the floor: 2 forced release cycles a year, plus a fee, for an app whose code you never touched. Everything above that floor is a choice. Everything below it is a slow removal from the store.
This is what actually drives the bill, and why a flat annual quote is a guess dressed as a number.
The floor: two dates you do not control
Start with the two hard requirements, because they set the minimum tempo of any live app.
Apple's Upcoming Requirements page is one sentence long and worth reading twice: "Since April 28, 2026 — Apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26."
Note what that does and does not say. It governs the SDK you build against, not the iOS version your users run. Your deployment target can stay where it is, and your existing users are unaffected. But if you want to ship anything at all, including a one-line crash fix, the binary must come out of Xcode 26 against the iOS 26 SDK. An app that has not been rebuilt since last year cannot ship an emergency patch until someone does the toolchain upgrade first. That is the trap: the SDK requirement is dormant until the day you urgently need it not to be.
Google's target API level policy works differently and bites harder. From 31 August 2025, new apps and app updates must target Android 15 (API level 35) or higher to be submitted, and existing apps must target Android 14 (API level 34) or higher "to remain available to new users on devices running Android OS higher than your app's target API level". Fall below it and, in Google's words, your app "will only be available on devices running Android OS that are the same or lower than your apps' target API level".
Read that consequence precisely, because it is widely misdescribed. Your app is not deleted. Google is explicit: "Users who have previously installed the app from Google Play will not be impacted and will still be able to discover, re-install, and use the app." What you lose is new users on new phones. The app does not break, it stops growing, and it stops growing silently. There is no outage, no alert, no crash report. Your install graph just bends and someone blames marketing.
This is an annual ratchet, not a one-off. Google's own table records Android 14 (API level 34) required from 31 August 2024, then Android 15 (API level 35) from 31 August 2025. Extensions run to 1 November, and only apps already out of compliance get the form, delivered through a policy warning in Play Console. Wear OS, Android TV and Android Automotive OS run one version behind on their own schedules. The only documented escape is a permanently private app restricted to one organisation for internal distribution.
| Requirement | Owner | Cadence | What happens if you miss it |
|---|---|---|---|
| Xcode 26 + iOS 26 SDK for uploads | Apple | Since 28 April 2026 | Cannot upload anything, including hotfixes |
| Target Android 15 (API 35), new apps and updates | Google Play | From 31 August 2025 | Submission rejected |
| Target Android 14 (API 34), existing apps | Google Play | From 31 August 2025 | Invisible to new users on newer devices |
| Extension request | Google Play | To 1 November | Only offered to non-compliant apps |
| Apple Developer Program | Apple | $99 per membership year | Certificates lapse, app pulled |
| Wear OS / Android TV target | Google Play | 31 August, one version behind | Same discoverability loss |
That is six recurring obligations before anyone opens your backlog.
Why the percentage-of-build-cost quote is nonsense
The industry convention is to quote maintenance as 15% to 20% of build cost per year. It is a convention, not a measurement, and it fails in both directions.
It over-charges the simple app. A content app with three screens, no SDKs and no background work needs the two forced releases a year and little else. Twenty percent of a large build cost for that is rent.
It badly under-charges the complex one. An app with payments, push, a maps SDK, an analytics SDK, background location and an offline cache does not have one dependency chain, it has nine, and each one has its own deprecation calendar that does not align with Apple's or Google's. The build cost tells you what the app cost to write. It tells you nothing about how many third parties can now break it.
The honest predictor is not build cost. It is your dependency count, your platform lag, and your cross-platform framework's churn rate. An agency that quotes an annual maintenance figure without asking which SDK version you are on, how many third-party SDKs you embed, and when you last shipped, is quoting a number it made up. The right first question is not "what is your budget", it is "when did you last upload a build".
Cross-platform teams should be especially careful here, because the framework adds a third deprecation calendar on top of Apple's and Google's. Flutter teams have had three structural migrations land in close succession: Impeller becoming mandatory, CocoaPods giving way to Swift Package Manager, and Material and Cupertino moving out to standalone packages. None of those were requested by a product owner. All of them consume the same engineer.
The real cost drivers, ranked
In our experience the annual bill sorts by these, in this order.
Platform lag is first and it compounds. Skipping a year does not defer the work, it multiplies it, because you then cross two sets of behaviour changes at once with no working baseline in between and no way to bisect what broke. The team that upgrades every year does a boring week. The team that upgrades every third year does a quarter and a war room. This is the single highest-use line in the whole budget: an app upgraded on schedule is cheap to keep, and the same app upgraded late is a rewrite wearing a patch's clothes.
Third-party SDK count is second. Every embedded SDK is a deprecation you did not schedule and a privacy manifest you must maintain. The count matters more than the complexity.
Cross-platform framework churn is third, and applies only if you are on Flutter or React Native. It is a real cost and usually a worthwhile trade, but it is not zero and it does not appear in the build quote.
OS behaviour changes are fourth. iOS 27 brings its own required work, including the mandatory UISceneDelegate migration and a wider set of API changes worth a testing pass. These are the items that turn a toolchain bump into a project.
Actual feature work is fifth. It is the only line anyone discusses in the kickoff meeting and the only one you fully control.
Notice the ordering. Four of the five cost drivers are set by other people's release calendars. That is the argument for treating maintenance as a standing capability rather than a project you fund when something breaks.
What we do, and how we scope it
eCorpIT is a technology consultancy in Gurugram, founded in 2021, CMMI Level 5 appraised and MSME certified, with partnerships including AWS, Microsoft and Google. We run mobile app maintenance as an ongoing engagement rather than a break-fix retainer, because the work is calendar-driven and the calendar is published a year ahead.
An engagement starts with an audit rather than a proposal. We establish what SDK your last build used, how far behind Apple's minimum and Google Play's target level you are, how many third-party SDKs you embed and which of those are already deprecated, and whether your framework has pending migrations. That audit is what makes a number possible. Anyone who hands you a number before it is guessing.
From there the work is a schedule, not a queue. Apple's SDK minimum and Google Play's 31 August target-level deadline are planned as fixed releases with the toolchain upgrade and regression pass sized in advance, not discovered in September. Between them we handle dependency and security updates, crash triage against real user impact, OS behaviour changes as betas land, and store compliance items like privacy manifests and age ratings. We design applications around DPDP requirements where the app touches personal data. Feature work sits on top, and it is the part that flexes when a platform deadline gets bigger than expected.
Our teams are senior-led and multi-disciplinary, which matters more for maintenance than for greenfield builds. A toolchain migration on a live app with paying users is not junior work; the code is unfamiliar, the tests are thin, and the blast radius is your install base. This is also why we prefer continuity: the second year of a maintenance engagement costs less than the first, because the audit stops finding surprises.
Who this fits: teams with a live app and no dedicated mobile engineer, or one mobile engineer who cannot be spared for a fortnight in August. Who it does not fit: teams with a staffed mobile platform group who already track this calendar. If that is you, you do not need us, you need to keep doing what you are doing. If you are building rather than maintaining, our Flutter app development service is the better starting point.
India-specific considerations
Two local realities change the shape of this.
The rupee cost of the fixed items is small and the rupee cost of the deadline is not. The Apple Developer Program at $99 a year is roughly ₹9,431 at ₹95.26 to the dollar, which is a rounding error against a single engineer-week. The expensive item is never the fee, it is the fortnight in August when someone has to be free. Indian product teams tend to run leaner on mobile than their user numbers justify, often one engineer covering both platforms, and one engineer means the platform deadline and your roadmap compete for the same person twice a year. That is a scheduling problem before it is a budget problem.
DPDP is the second. India's Digital Personal Data Protection Rules were notified on 14 November 2025 and run to full enforcement on 13-14 May 2027, with penalties reaching ₹250 crore for major violations. Mobile apps are where consent is actually collected, which makes your app the surface the obligation lands on. Every third-party SDK you embed is a data flow you are answerable for, and most teams cannot currently list theirs. That list is a maintenance artefact, and building it is part of the audit rather than a separate compliance project.
FAQ
How eCorpIT can help
eCorpIT runs mobile app maintenance for teams that have a live app and no spare mobile engineer. We start with an audit that establishes your real position against Apple's SDK minimum and Google Play's target API level, inventories your third-party SDKs and their deprecation dates, and turns that into a schedule with the August and April work sized in advance rather than discovered late. We design applications around DPDP requirements where personal data is involved, and our teams are senior-led because migrating a live app with paying users is not junior work. If you cannot say which SDK your last build used, talk to our team and we will start there.
References
- SDK minimum requirements, Upcoming Requirements, Apple Developer, accessed 16 July 2026.
- Target API level requirements for Google Play apps, Play Console Help, Google, accessed 16 July 2026.
- Meet Google Play's target API level requirement, Android Developers, Google, accessed 16 July 2026.
- Apple Developer Program enrollment, Apple, accessed 16 July 2026.
- Apple Developer Program membership details, Apple, accessed 16 July 2026.
- Upcoming Requirements, Apple Developer, accessed 16 July 2026.
- Permanently private apps, Google Play Help, accessed 16 July 2026.
- Update or unpublish your app, Play Console Help, Google, accessed 16 July 2026.
- Android 16 behavior changes, Android Developers, Google, accessed 16 July 2026.
- Android 15 behavior changes, Android Developers, Google, accessed 16 July 2026.
- Submitting apps to the App Store, Apple Developer, accessed 16 July 2026.
- When does India's DPDP law begin full enforcement? 2026-2027 timeline explained, India Briefing, 11 May 2026.
Last updated: 16 July 2026.