App Store and Google Play deadlines in 2026 that affect your builds

Store deadlines rarely break a release on the day they start. They break it a few weeks later, when someone uploads a build made on an old CI image and App Store Connect refuses it, or when Play Console will not take an update the night before a launch. Most of these rules are announced months ahead, on pages few people check.

This article lists the App Store and Google Play deadlines of 2026 and early 2027 that change what a build must look like: what each rule says, from when, who it affects, how to fix it and how to check a file before you upload it. Every date was read on the official Apple and Google pages on November 3, 2026, and the list is kept up to date with a dated line at the bottom. The same data is on our free store deadlines page, with links to the official source for each rule.

All deadlines at a glance

Date	Store	Rule	Check your file
January 31, 2026	App Store	New age rating questions answered	App Store Connect
April 28, 2026	App Store	Uploads built with Xcode 26 and the iOS 26 SDK	IPA inspector
August 31, 2026	Google Play	New apps and updates target API 36	APK inspector
August 31, 2026	Google Play	Existing apps below API 35 hidden from new users on newer Android	APK inspector
September 9, 2026	App Store	Apps target iOS 13 or later	IPA inspector
September 30, 2026	Android	Developer verification, first four countries, seven stores	Your developer console
February 1, 2027	Google Play	No updates released without 16 KB page size support (apps targeting Android 15+)	APK inspector
2027, month not announced	Android	Developer verification worldwide, all install sources	Your developer console

Store uploads and test builds are affected differently. A rule about App Store Connect uploads does not stop you from sharing an ad hoc build with testers through an install link. But the build you test should be the build you will ship, so test on a build that already meets the rules, or you test one thing and release another.

App Store

Xcode 26 and the iOS 26 SDK, since April 28, 2026

What: every app uploaded to App Store Connect, new or update, must be built with Xcode 26 or later and the iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26 SDK. The minimum iOS version of the app can stay lower; this is about the SDK you build with.

Who it catches: teams whose CI image still has Xcode 16, and cross platform projects whose build machine was set up a year ago and never touched.

Fix: install Xcode 26, fix new warnings, archive and upload again. On CI, pick a macOS image with Xcode 26.

Check: the IPA inspector reads the SDK and Xcode version from the .ipa in your browser, without uploading it.

Minimum iOS 13, since September 9, 2026

What: apps must target iOS 13 or later. A build with a lower deployment target is refused at upload.

Who: older apps that still list iOS 11 or 12, and projects where a Podfile, a Flutter setting or a React Native template holds an old value even after the Xcode target was raised.

Fix: set the iOS Deployment Target to 13.0 or later in Xcode and in your Podfile or framework settings, then archive again.

Check: the IPA inspector shows the minimum iOS of the build.

Age rating questions, by January 31, 2026

What: the updated age rating questions had to be answered in App Store Connect, or submitting updates is interrupted. If you have an app you have not updated this year, look before your next release.

Fix: App Store Connect, the app, App Information, Age Rating.

Required reason APIs, since May 1, 2024

Not new, but still the most common upload email. Apps that use required reason APIs, such as UserDefaults or file timestamps, must declare a reason in PrivacyInfo.xcprivacy (ITMS-91053), and SDKs on Apple's list of commonly used SDKs need their own privacy manifest and signature (ITMS-91061). Updating an old SDK is usually the fix. The IPA inspector shows whether the app and its frameworks carry privacy manifests.

Google Play

Target API 36 for new apps and updates, since August 31, 2026

What: new apps and updates must target API level 36. Wear OS and Android Automotive OS apps need API 35, Android TV and XR apps API 34. Uploads that target lower are refused. The extension Google gave on request ran until November 1, 2026, so it is over.

Fix: set targetSdk to 36, test the behavior changes of Android 16, upload again.

Check: the APK inspector shows the min and target SDK of an .apk.

Existing apps below API 35 hidden from new users, since August 31, 2026

What: apps already on Google Play that target below API 35 (Wear OS 34, Android TV and XR 33, Automotive 32) stay installed for current users, but new users on devices with a newer Android version can no longer find or install them.

Who: apps that work and were never updated. Sales do not stop with an error message; they fade.

Fix: publish an update that targets at least API 35, ideally 36, so the update itself is accepted.

16 KB page size, updates blocked from February 1, 2027

What: Google Play already requires 16 KB page size support for apps that target Android 15 or higher and ship native libraries. From February 1, 2027, Play Console will not let you release an update without it.

Who: any app with native code: your own C or C++, and SDKs that bring native libraries, such as Flutter, React Native, Unity and many ad, video and database SDKs. Pure Kotlin or Java apps are not affected.

Fix: update the SDKs that carry native libraries, build your own native code with NDK r28 or later, and use Android Gradle Plugin 8.5.1 or later.

Check: the APK inspector lists the native libraries, and its readiness check flags missing 16 KB support. That check shows this as a warning until February 1, 2027, then as a blocker.

Android developer verification

This one reaches beyond Google Play, so it matters for test builds too.

First phase, since September 30, 2026

What: on certified Android 7 and later phones and tablets in Brazil, Indonesia, Singapore and Thailand, installs from seven app stores (Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore and GetApps) check that the app is registered to a verified developer.

Not covered yet: apps sideloaded directly, such as an APK a tester downloads from an install link.

Worldwide, in 2027 (month not announced)

What: Google plans to extend the checks to all apps on certified devices worldwide, from any source. An app whose package name and signing key are not registered to a verified developer will not install unless the person uses the advanced flow or ADB.

What to do now: verify your developer account and register your package names with every signing key you use, including the one for test builds. Apps that use Play App Signing are registered automatically for the Play key, but a test build signed with a different key is a different case. Our guide Android developer verification explains the steps, and what it means for test builds covers sideloaded APKs in detail.

One AppForShare specific note: when you upload an .aab, AppForShare turns it into one installable APK signed with your workspace's test key, unless you added your own upload keystore (Pro and Team). You cannot register our test key with Google, so for verification plan on your own keystore or upload an .apk you signed yourself.

How to check a build before you upload it

1. Before the store upload: drop the .ipa or .apk into the free IPA inspector or APK inspector. The file is read in your browser and not uploaded, and both run the same readiness rules as our account builds: SDK version, minimum iOS, privacy manifests, target API, 16 KB pages, debug signing, 64-bit.
2. On every test build: if you share builds with an AppForShare account, each upload gets the same store readiness check on its build page, with a "how to fix" per issue. On Pro and Team, CI can fail the job on a blocked result with --fail-on blocked.
3. Before a release: read the official pages linked from store deadlines. Our check is guidance; it does not promise store approval, and Apple and Google review far more than a file can show.

For a wider iOS list, see the iOS test build checklist for 2026.

Put the pattern in your calendar

Both stores have followed a rhythm in recent years, which makes the next round easier to plan even before it is announced:

• Apple has required the newest Xcode and SDK for uploads each spring, a few months after the major release in September. Plan an Xcode upgrade for your CI images in the first quarter, not the week of the deadline.
• Google Play has raised the target API level each August, one level behind the newest Android. Put a target SDK upgrade in your early summer plan and test the new behavior changes on real devices.
• SDKs are where most surprises come from: privacy manifests, native libraries and target API changes all arrive through third party code. Keep a list of SDKs per app with the version you ship.
• Old apps that you do not update often are the ones that get caught. Check them twice a year, even when no release is planned.

Where these dates come from

• Apple: Upcoming requirements on developer.apple.com.
• Google Play target API: target API level requirements.
• 16 KB page size: page sizes on developer.android.com.
• Developer verification: Android developer verification.

We list a future date only when the store has announced it. When a store moves a date, we change this page, the tool page and the readiness rules together.

Common questions

Do these rules stop me from sharing a test build?

The App Store and Google Play rules apply to store uploads, not to an ad hoc .ipa or an .apk shared by link. Android developer verification is the exception: from its worldwide phase in 2027, it applies to sideloaded apps too.

What Xcode do I need in 2026?

Xcode 26 with the iOS 26 SDK for any App Store Connect upload since April 28, 2026.

What target API does Google Play need?

API 36 for new apps and updates since August 31, 2026; Wear OS and Automotive 35, Android TV and XR 34.

Change log

Checked November 3, 2026: all dates read on the official Apple and Google pages; first version of this article.