App Store and Google Play Requirements in 2026
Zubin Gala
Principal Mobile App Engineer, Unico Connect
In this article
Most teams treat shipping as the end of a mobile project, but launch is where two companies you do not control start setting deadlines for you, and missing one of them leaves you unable to update the app at all.
The big one has already passed. Since 31 August 2026, new apps and app updates must target Android 16, API level 36, to be submitted to Google Play. If you missed it, the route back is the extension to 1 November 2026, requested from the policy warning on the Policy status page in Play Console, and for apps on that extension, that date replaces the August one as the live deadline. If your app targets something older, you can keep the version already published, but you cannot ship a fix, a feature, or a security patch until you raise the target.
Beyond that headline date, Apple and Google have other requirements already in force in 2026 that are quietly blocking uploads, and some that remove a published app instead of rejecting a new one.
Quick Answer
For Google Play, new apps and updates have had to target Android 16, API level 36, or higher since 31 August 2026, with an extension to 1 November 2026 available on request. Wear OS and Android Automotive OS must target Android 15, API level 35, by the same date, and Android XR must target Android 14, API level 34. Android TV sat on the same API level 34 requirement but its deadline was a year earlier, 31 August 2025, so that one has already passed. For the App Store, since 28 April 2026 every upload to App Store Connect must be built with Xcode 26 or later against the iOS 26 and iPadOS 26 SDKs, or the matching 26 SDK for tvOS, visionOS and watchOS. Separately, since 1 May 2024 you must declare approved reasons in a privacy manifest for a defined set of APIs, including those used by third party SDKs you did not write. Non technical requirements matter as much as the technical ones. Without verified Digital Services Act trader status, an app is removed from the App Store in the EU.
Key Takeaways
- Missing the Google Play deadline of 31 August 2026 blocks your updates while existing installs carry on. An app below API level 36 stays live for existing users but becomes unfixable, which is worse than a takedown, because when a security issue arrives there is no route to ship the patch.
- If you are not ready, ask for the extension today. Google allows a request for more time until 1 November 2026, but the decision to grant it sits with Google, so do not build a plan around approval.
- Check your Xcode version before the next release. Since 28 April 2026, uploads must be built with Xcode 26 or later against the 26 generation SDKs, and nothing flags the problem until somebody tries to release, which is usually the worst moment to find out a toolchain upgrade is required.
- Audit third party SDKs for privacy manifests. Approved reasons are required for a defined set of APIs, including those called by SDKs inside your app, so an analytics, crash reporting or advertising SDK can fail your submission and leave you waiting on its vendor to ship the fix.
- Put the administrative items on your release checklist, because one of them removes a live app instead of rejecting an upload. That item is Digital Services Act trader status. Without it, an app is removed from the App Store in the EU, and no amount of code quality substitutes for filling in the form.
The Google Play Deadline, in Detail
Google raises the minimum target API level every year, and the current step took effect on 31 August 2026. Since that date, new apps and app updates must target Android 16, API level 36, or higher to be submitted to Google Play. Non compliant apps get a policy warning in Play Console, and Google states that an extension to 1 November 2026 can be requested from the details page of that warning on the Policy status page. Separately, existing mobile apps that target below Android 15, API level 35, stop being available to new users on devices running a newer Android version than the app target unless they have an extension, with lower thresholds for Wear OS, Android TV, Android XR and Android Automotive OS. Users who already installed the app keep it.
Two platform families sit on different numbers, which is the part teams miss when they own more than one form factor. Wear OS and Android Automotive OS must target Android 15, API level 35, by 31 August 2026, and Android XR must target Android 14, API level 34, by that date. Android TV is the exception and is easy to miss, because its API level 34 deadline was 31 August 2025 and has already passed.
Read the rule carefully, because the wording invites misplaced calm. It governs what you can submit. An app that misses the deadline is not removed and existing users keep it, but you lose the ability to publish anything new, so every bug fix, every feature and every security patch is blocked behind the same upgrade.
Raising the target level is also more than a configuration change. Each Android release tightens behaviour, and targeting a newer level opts you into all of it at once, typically around background execution, permissions, storage access and foreground services. The upgrade needs a proper QA pass on a range of devices, and because it produces nothing a user can see, it is exactly the work that gets deferred.
What Apple Requires Right Now
Apple sets its bar mainly through the build toolchain rather than a target level, and the current one is already in force.
Since 28 April 2026, apps and games uploaded to App Store Connect must be built with Xcode 26 or later. In practice that means iOS and iPadOS apps built against the iOS 26 and iPadOS 26 SDKs, with the matching 26 generation SDK required for tvOS, visionOS and watchOS. Since 9 September 2026, iOS and iPadOS apps uploaded to App Store Connect must also target iOS 13 or later.
Nothing warns you about this one while you are developing normally, because it only bites at upload. A team on an older Xcode can work for months and then discover, during a release that matters, that shipping requires a toolchain upgrade, which in turn can require operating system upgrades on build machines and continuous integration runners, plus dependency updates for anything that will not compile under the newer toolchain. Schedule toolchain upgrades as routine maintenance so they do not turn into an emergency.
Store requirements in force in 2026, and what each one actually breaks
| Requirement | Platform | The date | What it breaks | Who it catches out |
|---|---|---|---|---|
| Target Android 16, API level 36 | Google Play | 31 August 2026, extension available to 1 November 2026 | Blocks all new submissions and updates, existing installs unaffected | Teams with no scheduled platform maintenance, who find out during an urgent fix |
| Xcode 26 and the 26 generation SDKs | App Store | In force since 28 April 2026 | Blocks uploads to App Store Connect | Teams whose continuous integration runners are on an older toolchain |
| Privacy manifest, required reason APIs | App Store | In force since 1 May 2024 | Blocks submission, including because of a third party SDK | Anyone with analytics, attribution or advertising dependencies |
| Digital Services Act trader status | App Store, European Union | In force since 17 February 2025 | Removes the published app from the EU store entirely | Engineering teams, because it is a form rather than a code change |
| Receipt signing, SHA-256 | App Store | SHA-1 intermediate expired 24 January 2025 | Breaks on device receipt validation, so purchases fail | Paid apps with an old validation code path nobody has touched |
Which should you choose
Google Play requirements from the official target API level page in Play Console Help. Apple requirements from the official Apple Developer Upcoming Requirements page. Both read 2026-08-27 and verified again 2026-09-26. Store requirements change often, so verify at those two sources before planning a release.
Privacy Manifests and Required Reason APIs
This is the requirement that most often surprises teams, because the thing that fails your submission may be code you never wrote.
Since 1 May 2024, you must declare approved reasons in your privacy manifest for a defined set of APIs, and the requirement covers the APIs used by your app code including third party SDKs. Apple maintains the list. It exists because these APIs can be used for fingerprinting, which is prohibited on the App Store, so each use has to be matched to an allowed reason and declared.
Three practical consequences follow.
One. Your dependencies become your problem, because an analytics, attribution, crash reporting or advertising SDK that lacks a correct privacy manifest can block your release while the fix sits in the release schedule of that vendor. Audit your dependency list before a release begins.
Two. Adding an SDK is now a compliance decision as well as a size and performance question. Check its privacy manifest before you adopt it, and prefer maintained SDKs, because an abandoned one becomes a permanent blocker.
Three. You have to repeat the check. Dependencies update, APIs move on and off the list, and a release that passed six months ago tells you nothing about the next one.
The submission failures I see are almost never in the client code. They are a dependency three levels down that has not shipped a privacy manifest, or a build machine on a Xcode version that was fine last quarter. Both are entirely predictable and both get discovered on release day, because nothing complains until you press upload. We audit the dependency list and the toolchain on a schedule for exactly this reason.
Zubin Gala, Principal Mobile Engineer, Unico Connect
The Requirements That Break a Published App
Rejection at submission is inconvenient. Removal from a live store costs revenue, and because several of these requirements are administrative rather than technical, engineering teams miss them.
Digital Services Act trader status. Since 17 February 2025, apps without verified trader status are removed from the App Store in the European Union. It is a form and a verification process with no code involved, and the penalty is delisting in an entire market.
Age ratings. Apple updated its age rating system, set out in the App Review Guidelines, and required responses to the updated questions in App Store Connect by 31 January 2026 to avoid interruptions to submissions. Any app whose content changes materially should revisit these answers rather than assume the original ones still hold.
Receipt validation. Since 24 January 2025, the SHA-1 intermediate certificate used for signing App Store receipts has expired. Apps doing on device receipt validation must support SHA-256, or move to the AppTransaction and Transaction APIs. If your paid app validates receipts with an old code path, it breaks purchases, a far more expensive failure than a rejected submission.
macOS quarantine attribute. Since 18 February 2025, macOS apps distributed on TestFlight and the App Store must not include the com.apple.quarantine extended file attribute. It is a packaging detail that blocks the upload to App Store Connect.
What This Means for Your Budget
An app keeps needing work long after launch, and store requirements are the clearest proof.
Every year brings a target API level rise on Android and a toolchain and SDK bar on Apple, and neither produces a visible feature even though both are mandatory to remain shippable. This is a large part of why we budget maintenance at 15 to 20 percent of build cost per year, the same figure used in our mobile app development cost guide. A meaningful share of that money pays for keeping the app eligible for the stores, which is separate work from fixing bugs.
Teams that skip this build up a specific and dangerous debt. The app keeps working and nothing appears wrong until an urgent fix is needed, at which point a year of deferred platform work blocks the release path and the upgrade you postponed stands between a security issue and its patch.
Cross platform frameworks change how this work looks without removing it. A Flutter or React Native app still targets an Android API level and still builds against an Apple SDK, and you also depend on your framework shipping support for the new platform version. That support usually arrives quickly, but it puts another party in your release path. For the wider tradeoff between the two, see our Flutter and React Native comparison.
A Release Readiness Checklist
Run this every quarter, well ahead of release day.
Check the Android target level against the current requirement and the roadmap, and confirm the separate numbers if you ship Wear OS, Automotive, TV or XR builds.
Check the build toolchain on developer machines and continuous integration together. Continuous integration is where the stale version usually hides.
Audit dependencies for privacy manifests, including transitive ones, and flag anything unmaintained as a release risk instead of a technical preference.
Confirm the administrative items, which means trader status for the EU, current age rating answers, and any account level verification the stores have introduced.
Test on old devices and old operating system versions, because raising a target level changes runtime behaviour for users who have not upgraded, and that is where regressions land.
Keep a release runbook so this knowledge does not live with one engineer. Almost everything above fails silently until upload, so this checklist is what catches those failures early.
Where These Numbers Come From
The Google Play target API level requirements, the 31 August 2026 date, the API level 36 requirement, the extension to 1 November 2026, and the separate levels for Wear OS, Android Automotive OS, Android TV and Android XR all come from the official Google Play target API level requirements page in the Play Console Help. The Apple requirements, including the iOS 13 minimum target in force since 9 September 2026, the 28 April 2026 Xcode 26 and 26 generation SDK requirement, the required reason API and privacy manifest requirement in force since 1 May 2024, the App Store receipt signing certificate change of 24 January 2025, the 31 January 2026 age rating deadline, the Digital Services Act trader status requirement in force since 17 February 2025, and the macOS quarantine attribute rule from 18 February 2025, all come from the official Apple Developer upcoming requirements page. We read both on 27 August 2026 and verified them again at source on 26 September 2026. Store requirements change frequently, so verify against those two pages before you plan a release. The maintenance figure of 15 to 20 percent of build cost per year is our own published planning range.
Frequently Asked Questions
What API level do Android apps need to target in 2026?
From 31 August 2026, new apps and app updates must target Android 16, API level 36, or higher to be submitted to Google Play. An extension to 1 November 2026 can be requested. Wear OS and Android Automotive OS must target Android 15, API level 35, by 31 August 2026, and Android XR must target Android 14, API level 34. The Android TV deadline for API level 34 was 31 August 2025.
What happens if my app misses the Google Play target API deadline?
The published version stays available to existing users, but you cannot submit updates. That means no bug fixes, no new features and no security patches until the target level is raised. Missing the deadline blocks shipping without taking the app down, and teams often underestimate that because the real cost appears the first time an urgent fix is needed.
What Xcode version is required for App Store submissions?
Since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later, using the iOS 26 and iPadOS 26 SDKs, or the corresponding 26 generation SDK for tvOS, visionOS and watchOS. Nothing warns you before upload, so check the version on your continuous integration runners as well as on developer machines.
What is a privacy manifest and does my app need one?
A privacy manifest declares your data use and, since 1 May 2024, the approved reasons for using a defined set of APIs that could be used for fingerprinting. It covers APIs called by third party SDKs as well as your own code, so an SDK without a correct manifest can block your submission even though the code is not yours.
Why would a live app be removed from the App Store?
Administrative requirements rather than code quality are the usual cause. The clearest example is Digital Services Act trader status, which has been required since 17 February 2025 and results in removal from the App Store in the European Union without it. Age rating responses and account verification steps can also interrupt submissions.
How much should we budget for keeping an app in the stores?
Plan 15 to 20 percent of build cost per year for maintenance overall, and expect platform compliance, as distinct from bug fixing, to take a meaningful part of it. Each year brings an Android target level rise and an Apple toolchain and SDK bar. Neither produces a visible feature, and you have to meet both to stay shippable.
Do cross platform apps avoid these requirements?
No. A Flutter or React Native app still targets an Android API level and still builds against an Apple SDK, so every deadline above applies. You also depend on your framework releasing support for new platform versions, which adds a party to your release path even though it is usually quick.
How often should we check store requirements?
Quarterly, and before any planned release. Both platforms publish requirements ahead of time, on the Google Play target API level page and the Apple Developer Upcoming Requirements page, so nothing here should be a surprise. Teams get caught because nobody is assigned to read those pages.
Conclusion
Store compliance is the least interesting work in mobile development and among the most consequential, because it is the only part where an external deadline can stop you shipping entirely. The immediate item is the Google Play target API level requirement in force since 31 August 2026, and if you are not on Android 16 yet, request the extension today and start the upgrade.
Beyond that, put the toolchain, the target level and the dependency audit on a quarterly schedule, and keep a runbook so it does not depend on one person remembering. Give platform maintenance its own funded line in the budget so it does not get squeezed in between features.
If you want a team that runs this as a matter of course, see our mobile app development services, our education app development guide for a sector where compliance decides procurement, or contact us.
