Debugging log · Play Console
What happens if you don't target API 36 by the deadline?
Every year the same worry goes around: the target API deadline is coming, and if I miss it, does my app get pulled? I had ten apps facing the August 31, 2026 cutoff and wanted a precise answer before I panicked. Here it is, separated cleanly into what actually happens and what doesn't.
The short version: if your app doesn't target API 36 by the deadline, your currently published version stays live and installable — it is not removed. What you lose is the ability to submit new updates: uploads of a build targeting an older API get blocked. A deadline-extension request is typically available in the Play Console if you need a few more weeks.
What does NOT happen
Let's kill the worst fear first, because it's the most common misconception:
- Your app is not removed from the Play Store. The version you already published stays up.
- Existing users keep the app. Nobody's install is revoked, and the app keeps working.
- New users can still install it — with one caveat about device visibility below.
- You are not banned or penalized. Missing a target-API deadline is a publishing restriction, not a policy strike against your account.
What DOES happen
The consequence is specific and it's all about shipping changes:
- You can't submit updates. After the deadline, uploading a new release that targets an API level below the requirement is blocked at the Play Console. Bug fix, new feature, security patch — all of it is frozen until you comply.
- New app submissions are blocked too. A brand-new app must target the current requirement from day one.
So the real cost of missing the date isn't losing your app — it's losing your ability to maintain it. For an app you're done with, that might be acceptable. For anything you still touch, it's a hard stop on your release pipeline.
The separate "visibility" rule people confuse with this
There's a related-but-different rule worth untangling, because it causes a lot of confusion. To keep an app discoverable and installable on the newest devices, it generally needs to target within a couple of API levels of the latest. An app that falls too far behind can stop being offered to users on the very newest Android versions, even though it stays available to everyone else. This is a gradual visibility effect, not the same thing as the hard upload block — but both push in the same direction: keep your target level current.
How to buy time: the extension
If the deadline is genuinely going to catch you, look in the Play Console for the option to request a deadline extension. Google has historically offered a short grace window (often into early November) that you can request per app. It's not automatic and it's not forever, but it converts a hard wall into a few more weeks — enough to do the migration properly instead of in a panic. Request it before the date, not after.
The actual fix is smaller than the worry
Here's the part that should lower your stress: for most apps, compliance is a build-configuration change, not a rewrite. Set compileSdk = 36 and targetSdk = 36, bump the tooling that requires (Android Gradle Plugin 8.9+, a matching Gradle, and Kotlin 2.0+ if you're on 1.9), test the behavior changes — mainly edge-to-edge — bump your version code, and upload. I did ten apps in a weekend, and the mandatory part was maybe a third of the work. The scary deadline is real, but the task behind it usually isn't scary.
Don't wait for the last day. The tooling upgrades occasionally surface pre-existing problems — a strict release-lint error, an outdated transitive dependency — that take longer than the target bump itself. Give yourself a buffer so a surprise doesn't collide with the deadline.
Play policies, dates, and extension availability change over time; confirm the current requirement and any grace period in your Play Console before planning around specific dates.