Your app's maintenance budget is set by Apple's and Google's calendars

Your total maintenance budget depends on your app, but the part you cannot skip is not a percentage of what the app cost to build. It is a set of dated rules that Apple and Google publish every year. An app nobody touches loses the ability to ship updates on both stores within about a year, and on Google Play it starts disappearing for new users on newer phones within about two.

That changes how the question "what will this app cost to keep alive?" should be answered. The forced part of maintenance can be planned as a calendar from primary sources, and that is what this post does. The optional part, new features and improvements, is a separate decision.

Most app maintenance cost figures have no source

The figure that fills the first page of search results, maintenance at 15 to 20 percent of build cost per year, is a rule of thumb rather than a measurement. When we checked the pages ranking for "app maintenance cost per year" and "how much does it cost to maintain an app" in October 2026, most of them repeated a range like that, usually without a study a reader could check.

A percentage of build cost also has a structural problem. Two apps with the same build cost can carry very different forced workloads: one uses in-app purchases, push notifications and several analytics SDKs, while another is a thin client over a web API. The platform deadlines below hit both, but they hit the first one harder. So instead of a ratio, we start from the documented items and let you size the work against your own app.

Google Play sets a target API deadline every August

Google Play requires every new app and every update to target a recent version of Android, and the deadline lands on August 31. Google's target API level requirements page states the current rule: from August 31, 2026, "new apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play." Wear OS and Android Automotive OS apps must target API level 35, and Android TV and Android XR apps API level 34. Developers could request "an extension to November 1, 2026" for more time. The year before, the same page shows, the requirement was API level 35 from August 31, 2025.

Behind the dates is a rolling window. Google's Target API Level Policy says: "New apps and app updates MUST target an Android API level within one year of the latest major Android version release." Existing apps that are not updated, and that do not target an API level within two years of the latest major release, "will not be available to new users with devices running newer versions of Android OS." The same page advises developers to "start the migration process at least 3 months before the deadline."

The next window is already open. Google released Android 17, API level 37, on June 16, 2026, with the announcement "Today we're releasing Android 17 and making it available on most supported Pixel devices." Google has not yet published the August 2027 requirement, so treat API level 37 for August 2027 as our projection from the pattern, not an announcement.

Raising the target is rarely a one-line change. Each new target opts the app into that Android version's behaviour changes. Google's Android 17 announcement gives an example: "Once you target Android 17 (SDK 37), you can no longer opt out of maintaining orientation, resizability and aspect ratio constraints on large screens." That is testing and fixing work, and it is the core of the yearly Android compliance release.

Apple raises the SDK floor every spring

Apple requires uploads to App Store Connect to be built with a recent Xcode and SDK, and the floor rises each spring. Apple's Upcoming Requirements page states it plainly: 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." The same page records earlier steps in the same season, such as Xcode 14.1 from April 25, 2023 and Xcode 15 from April 29, 2024.

The next step is already announced. In a September 9, 2026 post, Apple wrote that "starting April 2027, apps and games uploaded to App Store Connect need to meet the following minimum requirements," including that iOS and iPadOS apps "must be built with the iOS 27 & iPadOS 27 SDK or later." Apple gave a month, not a day, so plan for the start of April.

Apple also adds requirements that are not about the SDK but still block uploads until they are handled. Recent examples from the same Upcoming Requirements page include declaring approved reasons for certain APIs, including in third-party SDKs, from May 1, 2024; answering updated age rating questions by January 31, 2026 "to avoid an interruption when submitting your app updates"; and, since September 9, 2026, a requirement that iOS and iPadOS apps target iOS 13 or later. App Review Guideline 5.1.1(v) adds a standing rule for any app with sign-up: "If your app supports account creation, you must also offer account deletion within the app."

One distinction matters for buyers. Apple's SDK rule governs what you can upload. We found nothing in it that removes a version already live on the store. What it does is turn any future fix, even an urgent one, into a toolchain upgrade first.

Store and program fees are small, documented and dated

The fixed cost of staying on the stores is small and published, while the commission rules are changing in phases. Apple's developer program page states: "The Apple Developer Program is 99 USD per membership year, or in local currency where available." Google's Play Console Help states: "There is a US$25 one-time registration fee."

On commission, Apple's program page gives the rate as 30 percent, or 15 percent for developers in the App Store Small Business Program, which covers developers who earned up to 1 million USD in proceeds in the prior calendar year, and 15 percent for qualifying subscriptions. Apple's subscriptions page says that after a subscriber accumulates one year of paid service, "your net revenue increases to 85% of the subscription price."

Google is mid-transition. Its service fees page applies a new fee structure to transactions with users in the EEA, the UK and the US from June 30, 2026, and in Australia and Japan from September 30, 2026. Elsewhere, the older structure, 15 percent on the first 1 million USD of revenue each year and 15 percent on auto-renewing subscriptions, applies "until the announced updated service fees are rolled out globally," and Google's page gives no date for that. Under the new structure the fee depends on factors such as region, transaction type and whether the install is new or existing, so check the page for the markets you sell in. Regional rules in the EU, the US and Japan add further payment options; we covered payment routing in Web app vs mobile app in 2026. The detail matters only if you sell digital goods.

Your frameworks and SDKs keep their own clocks

Beyond Apple and Google, the libraries inside the app have published support windows that force upgrades on their own schedule. The clearest is Google Play Billing. Google's billing deprecation FAQ states that "All versions of the Google Play Billing Library have a two-year deprecation cycle." Version 7 had a deadline for new apps and updates of August 31, 2026, with an extension to November 1, 2026. Version 8 has August 31, 2027, with an extension to November 1, 2027, and version 9 has August 31, 2028, with an extension to November 1, 2028. If your app sells anything through Play, that is a second August deadline on top of the target API.

Cross-platform frameworks move faster still. React Native's release overview commits to "maintain the latest 3 minor series," and its published schedule shows a new minor version roughly every two months, with 0.88 dated October 12, 2026 and 0.89 dated December 7, 2026. That means a version can move out of support within months; check the current support table rather than assuming a fixed window. Expo's documentation says "New Expo SDK versions are released three times each year" and "Each Expo SDK release targets a single React Native version." Flutter's published 2026 schedule targets four stable releases, in February, May, August and November; those are planned windows, and Flutter does not publish a support period for older versions.

The practical consequence is that the yearly platform release for a cross-platform app often includes a framework upgrade, because older framework versions may not support the newest Xcode or Android target. Whether yours needs one is something to assess each year, not assume. It is the same pattern we described for AI models in Model deprecation: why pinning an LLM snapshot sets a deadline: every pinned dependency carries an end date, whether or not anyone has written it down.

An untouched app degrades differently on each store

Leaving an app alone does not freeze it. It changes what you can do with it, and the effect differs by store.

On Google Play, an app that is not updated keeps working for the people who already have it. Google's policy says those users "will continue to be able to discover, re-install, and use the app on any Android OS version that the app supports." New users are the problem. At the first August deadline you miss, you lose the ability to ship any update until the target is raised. Once the app falls outside the two-year window, it is no longer available to new users on devices running newer versions of Android.

On the App Store, paying the membership is necessary but not sufficient. Apple's App Store Improvements process removes apps that "no longer function as intended, don't follow current review guidelines, or are outdated." Developers of apps "that have not been updated within the last three years" and that see very few downloads over a rolling 12 months get an email and are asked "to submit an update within 90 days"; apps that crash on launch "will be removed immediately." Removed apps keep working for people who already have them. Separately, the next spring SDK floor means your next bug fix waits behind an Xcode and SDK migration. And the hard stop is the membership itself. Apple's renewal page says: "If your Apple Developer Program membership expires, your apps will no longer be available for download and you won't be able to submit new apps or updates."

There is one more change outside the stores. Google's developer verification programme began protections on September 30, 2026 for users installing apps from participating stores in Brazil, Indonesia, Singapore and Thailand, and Google says verification "will be expanded globally for all apps on certified Android devices in 2027." If an app is distributed outside Google Play, registering it is now part of keeping it installable.

The forced-update calendar for the next eighteen months

Here is every dated, documented item we found between October 2026 and 2028. Projections are marked as such.

• November 1, 2026: end of the Google Play extensions for the API level 36 requirement and for Play Billing Library 7.
• December 7, 2026: React Native 0.89 is scheduled, moving another minor version out of support.
• Your Apple membership anniversary, every year: renew, or apps become unavailable for download.
• April 2027: App Store Connect uploads must be built with the iOS 27 and iPadOS 27 SDK or later. Apple has announced the month, not the day.
• Around June 2027 (projection): the next major Android release, following Android 17 in June 2026.
• 2027: Google expands developer verification globally.
• August 31, 2027: Play Billing Library 8 deadline for new apps and updates, with an extension to November 1, 2027.
• August 31, 2027 (projection): the next Google Play target API deadline, most likely API level 37. Google has not yet published it.
• September 2027 (projection): the next iOS release, and with it Apple's announcement of the April 2028 SDK floor.
• August 31, 2028: Play Billing Library 9 deadline, with an extension to November 1, 2028.

Budget one compliance release per store per year, before the deadline

Our rule for buyers is simple: budget at least one platform-compliance release per store per year, and schedule each one to land well before the known deadline rather than in the week it falls due. For iOS, that release meets the spring SDK floor. For Android, it meets the August target API and billing deadlines. Google's own advice of three months' lead time is a sensible minimum for the Android release.

Two refinements make the rule practical. If the app is cross-platform, assess the framework version as part of the same release, because the new Xcode and Android target often require an upgrade. And if the app is in active development, fold the compliance work into a normal release, but keep it as its own line item so features cannot crowd it out.

A maintenance agreement should name work items, not a percentage

A maintenance agreement worth signing lists the forced work by name, so both sides can see whether it was done. At a minimum it should name:

• the yearly Android target API upgrade, with testing against the new Android version's behaviour changes;
• the yearly Xcode and SDK upgrade, with testing on the new iOS release;
• the React Native, Expo or Flutter upgrades those toolchains require;
• billing library and other SDK upgrades with published deprecation dates;
• store compliance tasks such as privacy declarations, age rating questionnaires and account deletion;
• who owns the Apple and Google developer accounts, who renews the Apple membership, and who receives the platforms' policy emails;
• a regular dependency and security review, including how upgrades are vetted before they ship.

We have written about vetting upgrades in Dependency cooldowns matter more once AI agents run npm install. The point here is narrower: every item above recurs whether or not the app gains a single new feature.

Dates move, rules vary by region, and this is not advice

Every date in this post comes from Apple's and Google's own pages as we read them in October 2026, and both companies change requirements, grant extensions and add regional rules. Projections are marked; treat them as planning assumptions until the platform publishes them. Fees differ by country and programme, and some rules are still rolling out. Nothing here is legal or financial advice. Check Apple's Upcoming Requirements page and Google's target API page each quarter, and put the next two deadlines in the calendar of whoever owns the app.

Written by Synthetixis, an AI-native product studio. More on what most AI software gets wrong.