App Store and Google Play Requirements in 2026
Zubin Gala
Principal Mobile App Engineer, Unico Connect
In this article
- Quick Answer
- Key Takeaways
- The Google Play Deadline, in Detail
- What Apple Requires Right Now
- Privacy Manifests and Required Reason APIs
- The Requirements That Remove a Published App
- What This Means for Your Budget
- A Release Readiness Checklist
- Where These Numbers Come From
- Frequently Asked Questions
- Conclusion
Most teams treat shipping as the end of a mobile project. It is not. It is the point at which two companies you do not control start setting deadlines for you, and missing one of them does not degrade your app, it stops you being able to update it at all.
There is a deadline this week. From 31 August 2026, new apps and app updates must target Android 16, API level 36, to be submitted to Google Play. 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. That is four days from the date of this article.
This guide sets out what Apple and Google actually require in 2026, the requirements that are already in force and quietly blocking uploads, and the ones that remove a published app rather than rejecting a new one.
Quick Answer
For Google Play, new apps and updates must target Android 16, API level 36, or higher from 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 TV and Android XR must target Android 14, API level 34. 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 just as much. Without verified Digital Services Act trader status, an app is removed from the App Store in the EU.
Key Takeaways
- The Google Play deadline is 31 August 2026 and it blocks updates, not installs. An app below API level 36 stays live for existing users and becomes unfixable, which is worse than being taken down, because a security issue arrives with no route to ship the patch.
- An extension exists and is worth requesting today if you need it. Google allows a request for more time until 1 November 2026. That is a request, not an entitlement, so do not build a plan around it being granted.
- Apple already moved. Since 28 April 2026, uploads must be built with Xcode 26 against the 26 generation SDKs. This one is invisible until somebody tries to release, which is usually the worst possible moment to discover a toolchain upgrade is required.
- Privacy manifests are the third party trap. Approved reasons are required for a defined set of APIs including those called by SDKs inside your app. Your analytics, crash reporting or advertising SDK can fail your submission, and the fix lives in somebody else release schedule rather than yours.
- Some requirements delist rather than reject. Digital Services Act trader status is the clearest example. 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 lands on 31 August 2026. From that date, new apps and app updates must target Android 16, API level 36, or higher to be submitted to Google Play. Google states that you can request an extension to 1 November 2026 if you need more time.
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. Android TV and Android XR must target Android 14, API level 34, by the same date.
Understand precisely what the rule does, because the wording causes misplaced calm. It governs submission, not distribution. An app that misses the deadline is not removed and existing users keep it. What you lose is the ability to publish anything new. Every bug fix, every feature, and every security patch is blocked behind the same upgrade.
Raising the target level is also not 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 work is real, it needs a proper QA pass on a range of devices, and it is exactly the work that gets deferred because it produces nothing a user can see.
What Apple Requires Right Now
Apple sets its bar 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.
This requirement has an unpleasant shape. Nothing warns you 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. Treat the toolchain as a scheduled maintenance item, not 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. 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.
The practical consequences are worth being blunt about.
One, your dependencies are your problem. An analytics, attribution, crash reporting or advertising SDK that lacks a correct privacy manifest can block your release, and the fix sits in that vendor release schedule. Audit your dependency list before a release rather than during one.
Two, every new SDK is a compliance decision. Adding one is no longer just 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, this is not a one time task. Dependencies update, APIs move on and off the list, and a release that passed six months ago is not evidence 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 Remove a Published App
Rejection at submission is inconvenient. Removal from a live store is a revenue event, and these requirements are administrative rather than technical, which is why 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. This is a form and a verification process, not a code change, and the penalty is delisting in an entire market.
Age ratings. Apple updated its age rating system 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, this breaks purchases rather than submissions, which is a considerably more expensive failure.
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 silently fails distribution.
What This Means for Your Budget
An app is not a project that finishes, 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. Neither produces a visible feature. 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 is not fixing bugs, it is keeping the app eligible for the stores.
Teams that skip this accumulate a specific and dangerous debt. The app keeps working, nothing appears wrong, and then an urgent fix is needed and the release path is blocked by a year of deferred platform work. The upgrade you postponed becomes the thing standing between a security issue and its patch.
Cross platform frameworks change the shape of this but not the fact of it. A Flutter or React Native app still targets an Android API level and still builds against an Apple SDK, and you additionally depend on your framework shipping support for the new platform version. That is usually fast, and it is another party in your release path. Our comparison of Flutter and React Native covers the wider tradeoff.
A Release Readiness Checklist
Run this quarterly rather than on 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 rather than 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 the checklist is the control.
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 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. Both read on 27 August 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 TV and Android XR must target Android 14, API level 34.
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. It is a block on shipping rather than a takedown, which teams often underestimate, 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 understand that a meaningful part of it is platform compliance rather than bug fixing. Each year brings an Android target level rise and an Apple toolchain and SDK bar, neither of which produces a visible feature and both of which are mandatory 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. The failure mode is not that the information is hidden, it is that nobody is assigned to read it.
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 on 31 August 2026, and if you are not on Android 16 yet, request the extension today and start the upgrade.
Beyond that, the discipline is simple. Put the toolchain, the target level and the dependency audit on a quarterly schedule, keep a runbook so it does not depend on one person remembering, and treat platform maintenance as a funded line rather than something 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.
