On this page · 8 sections
Summary. Fifteen days from now, on 31 August 2026, new apps and app updates must target Android 16, API level 36, to be submitted to Google Play, and existing apps must target at least API level 35 to remain available to new users on devices running a higher OS version. Since 28 April 2026, anything uploaded to App Store Connect must be built with Xcode 26 or later using an OS 26 SDK. On 3 March 2027 AWS blocks function updates for the nodejs20.x, python3.10, python3.9, ruby3.2 and provided.al2 Lambda runtimes. Amazon EKS charges $0.60 per cluster per hour once a Kubernetes version passes into extended support, against $0.10 on a supported one, and it is enabled by default. None of that is discretionary work, and none of it appears in a feature roadmap. That is what app maintenance actually is in 2026.
The maintenance calendar, in date order
| Date | Platform | What happens | Who it hits |
|---|---|---|---|
| Since 31 January 2026 | App Store | Age ratings automatically updated to the new system; responses to the updated questions were required to avoid interruption when submitting updates | Every iOS app |
| Since 28 April 2026 | App Store | Uploads must be built with Xcode 26 or later using an iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26 SDK | Every iOS app that ships an update |
| 27 August 2026 | Kubernetes | 1.34 enters upstream maintenance mode; patches limited to CVEs and dependency issues | Backends on 1.34 |
| 31 August 2026 | Google Play | New apps and updates must target API level 36; existing apps need API level 35 to stay available to new users on newer devices | Every Android app |
| 1 November 2026 | Google Play | Latest date available by requested extension to the API 36 requirement | Teams that will miss August |
| 2 December 2026 | Amazon EKS | Kubernetes 1.34 leaves standard support; cluster fee rises from $0.10 to $0.60 per hour | Backends on EKS 1.34 |
| 1 February 2027 | AWS Lambda | Function creation blocked on nodejs20.x, python3.10, python3.9, ruby3.2, provided.al2 | Serverless backends |
| 3 March 2027 | AWS Lambda | Function updates blocked on the same runtimes | Serverless backends |
Two of those deserve emphasis because their consequences are misunderstood.
The Play requirement has two different teeth. Missing API 36 stops you submitting anything at all, so you cannot ship a fix. Missing API 35 does not remove your app, but it stops new users on newer Android versions from installing it, which is a silent decline rather than an outage. Google will grant an extension to 1 November 2026 on request, which is a useful safety valve and also a signal about how often teams reach August unprepared.
The Lambda block is worse than it sounds. A blocked runtime keeps running. What stops is your ability to deploy a change to it, including a security patch. Being unable to fix a live function during an incident is a materially worse position than an outage you can respond to. AWS has actually been generous here: the normal policy is to block creation 30 days and updates 60 days after deprecation, and this cohort was granted a long extension in response to customer feedback, with nodejs20.x deprecated back on 30 April 2026 and still updatable until March 2027. The extension is not a reprieve, it is a longer runway on the same wall.
What maintenance actually consists of
Most maintenance quotes are priced as a share of build cost, which tells you nothing about what will be done. The work divides cleanly into four categories, and they behave differently.
Forced platform work is the calendar above. It is predictable, non-negotiable, and its size depends mostly on how far behind you already are. A team that bumps its target SDK annually does a small job each year; a team two levels behind does a migration.
Infrastructure drift is the quiet one. Kubernetes upstream supports a patch release series for roughly fourteen months, twelve of standard patching and two of maintenance mode in which only CVE and dependency fixes are cut. Managed services extend that and charge for it. On EKS the extended-support upgrade policy is set to EXTENDED by default for new and existing clusters, and once a cluster has entered extended support it cannot be disabled, only avoided beforehand by accepting an automatic upgrade instead. Google prices the same way, $0.10 per cluster per hour and $0.50 on top for extended support. A single forgotten non-production cluster at $0.50 extra an hour is $360 a month.
Corrective work is genuine defect fixing, and it is the smallest line in a well-built app and the largest in a poorly built one.
Adaptive work is everything caused by the world changing around the app: a payment provider's API version, an OS permission model, a new device form factor, a regulatory obligation.
The reason to separate them is budgeting. Forced platform work and infrastructure drift can be scheduled a year ahead from published vendor calendars. Corrective and adaptive work cannot. A maintenance agreement that does not distinguish them will either overcharge for a stable app or leave a busy one without capacity when it matters.
Standing platform costs
| Line | Google Play | App Store |
|---|---|---|
| Account | US$25 one-time registration fee | $99 per membership year |
| Commission in India | 15% on the first $1M annual revenue, 30% above; 15% on auto-renewing subscriptions | 15% under the Small Business Program below $1M in proceeds; standard rate above |
| Alternative billing | Service fee reduced by 4 percentage points in India and South Korea | Not applicable |
| Compulsory release cadence | Annual target API level bump | SDK and Xcode version requirement |
| Newer fee structure | Applies to EEA, UK and US from 30 June 2026, split by new versus existing installs | Not applicable |
India is still on the older Play fee structure. The newer regime, which splits rates by whether a user's install is new or existing, applies to the EEA, UK and US from 30 June 2026 and reaches other markets when the rollout goes global. Worth tracking, because it changes the arithmetic on subscription products materially when it lands.
India-specific considerations
Two things shape maintenance for products serving India specifically.
Device and OS spread is wider, which raises the cost of the compulsory work rather than its frequency. A target API bump has to be regression-tested across a longer tail of devices and Android skins, so the testing matrix, not the code change, is the expensive part. Budget the bump as a test cycle with a code change attached rather than the reverse.
Data obligations now have their own maintenance rhythm. Under the Digital Personal Data Protection Act, 2023, section 8(7) requires erasure once consent is withdrawn or the purpose is served, and requires you to cause your processor to erase too. Section 8(6) requires intimation of a personal data breach to both the Board and each affected data principal. These are not one-time build items. They are ongoing duties whose evidence has to keep working through every subsequent release, which means the erasure path and the breach process need to be in the regression suite rather than in a compliance folder.
How we run maintenance
- Build the dated inventory first: target API levels, SDK requirements, runtime deprecations, cluster versions, base images and third-party API versions, each with its published deadline.
- Separate forced work from discretionary work and schedule the forced work against those dates, not against sprint capacity.
- Set the annual platform bump as a fixed calendar event rather than a reaction. It is cheaper every time it is done on schedule and more expensive every time it is skipped.
- Instrument the silent failures. An app that stops being installable for new users on newer devices generates no error, only a slope on a chart.
- Keep the compliance paths in the regression suite so consent withdrawal, erasure and data export keep working release after release.
Our maintenance engagements start with that dated inventory, which is usually the first time the whole calendar has been in one place, and then run as a retained senior team with the forced work pre-scheduled and capacity reserved for corrective and adaptive work. We do not price maintenance as a flat percentage of build cost, because the percentage tells the buyer nothing about what is included.
eCorpIT maintains and modernises mobile and backend applications from Gurugram with senior-led, multi-disciplinary teams and CMMI Level 5 assessed processes. For related reading, our mobile app development company in India guide covers partner selection, app development cost in India covers what each build budget band buys, and cloud application development company covers the cluster and runtime side of the same calendar.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based engineering organisation, founded in 2021, that maintains and modernises mobile and backend applications. We open every maintenance engagement with a dated inventory of the platform deadlines, runtime deprecations and cluster versions that will force work in the next eighteen months, which is usually the first time that calendar has existed in one place. We then run as a retained senior team with the forced work pre-scheduled and capacity reserved for defects and adaptive change, designing aligned with Digital Personal Data Protection Act, 2023 requirements and delivering under CMMI Level 5 assessed processes. Talk to our team if your app is approaching a deadline you have not planned for.
References
Last updated: 16 August 2026.
