The app is fine. Nothing is broken, nobody is asking for a feature, it has been doing its job for a year. Then someone needs a small change: a phone number in the about screen, a price in the listing. The developer opens the project, makes the fix, uploads the build, and the store refuses it. Not because of what changed. Because of when.
Both stores run a calendar for app updates, and it does not care about yours. This post is about the two dates that decide whether your app can ship at all.
Google Play: the floor moves every August 31
Every Android app declares a targetSdkVersion: the API level it was built and tested against. Google Play uses that number as a ratchet. On August 31 each year, the submission floor moves up to the newest Android release, and from that date no new app or update can be uploaded unless it targets it. The Play Console Help page shows the cadence in two rows:
- August 31, 2025: submissions had to target Android 15 (API level 35)
- August 31, 2026: submissions must target Android 16 (API level 36)
An extension to November 1, 2026 was available through a form in Play Console. That date has now passed too, so the floor today is API 36. Wear OS and Automotive apps sit one level lower (API 35), TV and XR stay at API 34, but the deadline is the same August 31 date.
There is a second rule on the same page that owners miss more often, because it does not block uploads. It shrinks the audience. Existing apps must stay within one level of the floor, currently API 35, to remain available to new users on devices running a newer Android than the app targets. An app still targeting API 34 is not removed. It simply stops appearing to new users on Android 15 and 16, on any device running a newer Android than the app targets. The install base keeps working; the funnel quietly narrows.
The App Store: same idea, every April
Apple's version gates the toolchain instead of a manifest number. Since April 28, 2026, everything uploaded to App Store Connect must be built with Xcode 26 or later and a 26-series SDK. The Upcoming Requirements page keeps the history, and it reads like a calendar entry: Xcode 16 and the iOS 18 SDK on April 24, 2025, Xcode 15 and the iOS 17 SDK on April 29, 2024, Xcode 14.1 and the iOS 16.1 SDK on April 25, 2023. Late April, every year, the ground under your last build gets older.
Apple added a second rule this September, aimed at the other end of the support range: since September 9, 2026, iOS and iPadOS uploads must target iOS 13 or later. Apps that still claimed support for older versions had that floor raised underneath them.
So the two stores split the job between them. Play checks the API level you declare. Apple checks the tools you built with. An app nobody has touched fails both checks on schedule, one in April and one in August, no matter how well it runs.
What the yearly update actually costs
Bumping a number in a manifest is minutes of work. That is the part people quote when they say updates are cheap. What rides along is not.
A new targetSdkVersion switches on that Android version's behavior changes: new permission models, background execution limits, notification rules. A new Xcode brings a Swift version, an SDK with deprecations, and occasionally a breaking change in an API your app calls. For an app built last year by a team that kept its dependencies current, absorbing one annual step is usually a few days of work per platform, most of it testing.
For an app nobody has opened in two years, the first step is often getting it to build at all. Expired signing certificates, a CI image that no longer exists, a dependency that has moved three major versions, an SDK vendor that went quiet. Each of those is a normal maintenance task. Piled up against a hard deadline, they are a project.
This is the part we watch happen to client apps that come to us mid-neglect. The deadline does not scale with how much work your app needs. It lands on the same date either way, and the stores do not grade on effort.
Our position
Treat the two dates as fixed appointments, not surprises to discover at upload time. Any maintenance arrangement worth paying for already has them on a calendar: Apple's toolchain bump in April, Play's API floor in August, at least one release per store per year even when the changelog honestly reads "updated dependencies and build tools". An app that cannot ship an update is not maintained software. It is archived software with users.
If a studio built your app and cannot tell you its current targetSdkVersion without opening the project, that is the first line to ask about.
The takeaway
The whole obligation fits in eight lines. Check yours against it.
(api 36 / android 16 since aug 31, 2026)
new users on newer devices
(xcode 26 / ios 26 sdk since apr 28, 2026)
before the deadline, not after a rejection
The PLAN line is the one that gets skipped, because an app that needs nothing feels like it needs no release. The stores disagree on a schedule, every year, in writing. Keeping a release train that can absorb these dates is what our support and maintenance work is for, and it is what we run on CashTaq ourselves. If you want us to run the CHECK lines on your app, send us the store links.
// sources
// next step
We work this way on client projects too.
Tell us what you are making. We reply with a plan, a timeline, and a price.
