Your app expires even if you never touch it.

The comfortable story about a finished app is that it sits on the store doing nothing, costing nothing, occasionally earning something. It's the story behind every "I'll leave it up, it might still make a few dollars." It isn't true. An app that nobody touches is on at least four separate countdowns, three of them run by other people, and the usual way you find out is a support email from the one user who noticed.

Clock one: Play's target API level

Google requires every app on Play to target a recent Android version, and it raises the bar every August. As of 31 August 2026 new apps and updates have to target Android 16 (API level 36) or higher — with lower bars for the side platforms: API 35 for Wear OS and Automotive, API 34 for TV and XR.

The part that catches people is what happens to an app that's already published and falls behind. Google doesn't remove it and doesn't email you a removal notice. Instead, the app stays available only on devices running an Android version at or below what it targets. An app still targeting API 34 remains perfectly installable on an old phone and simply does not exist for anyone on Android 15 or newer. Existing installs keep working. Your download graph just flattens as the installed base rolls over to newer hardware — an effect that looks exactly like losing at ASO, and gets misdiagnosed as that constantly.

Google does publish an extension path — developers can request more time, to 1 November 2026 in the current cycle — but an extension is something you have to ask for, which means knowing the deadline exists.

Clock two: Apple's SDK floor

Apple's version of the rule sits one step earlier in the pipeline: not what your app targets, but what you built it with. From 28 April 2026, builds uploaded to App Store Connect must be made with Xcode 26 or later and the iOS 26 SDK (tvOS and visionOS have matching floors; watchOS apps additionally need 64-bit support).

Nothing happens to your live listing when that date passes. The damage is latent, and it shows up on the worst possible day: the day you need to ship a fix. You open a project you haven't built in eighteen months, discover the toolchain requirement, update Xcode, and now your dependencies don't compile against the new SDK, and the deprecated API you used in 2024 is gone. A one-line hotfix becomes a two-day migration while the bug is live. Every indie developer with more than one app in the store has had this week.

Clock three: the outdated-app sweep

Apple also runs a periodic cleanup, and it's the one that actually removes listings. Under the App Store Improvements process, an app can be flagged when it hasn't been updated in three years and fails to hit a minimal download threshold over a rolling 12-month window. Both conditions have to hold — a genuinely finished app that still gets installs isn't in scope.

If you're flagged, you get an email and 90 days to submit an update. Miss the window and the app comes off the store. People who already downloaded it keep it and it keeps working, including in-app purchases. Apps that crash on launch are a separate case: those are removed immediately, with no 90-day courtesy.

Clock four: your own renewal

The quietest one is the annual Apple Developer Program fee. Let the membership lapse and your apps stop being available for download — all of them, immediately, with no grace period. They keep running for people who already installed them, and you can renew at any time afterwards to undo it, but the restore isn't instant or automatic: free apps come back within about 24 hours, and paid apps only return once you sign in to App Store Connect and accept the Paid Applications Agreement again. That last step strands more listings than the fee ever does.

Why this lands hardest on the second app

Nobody misses these deadlines on the app they're actively working on. The toolchain is current because you build daily; the target API level is current because you shipped last month. The exposure is entirely in the back catalogue — the utility from three years ago that still trickles in twenty installs a month, the client app you handed over, the experiment you stopped marketing but never pulled.

Those are exactly the apps with no one watching, and the failure mode is silence. There is no alert for "this app is now invisible on modern Android." Revenue decays over months, which reads as a market going cold rather than a policy you didn't act on. If you've ever looked at an old app's flat download line and concluded the category died, it's worth ruling this out before you believe that.

The maintenance slot that prevents all four

This doesn't need a process. It needs one recurring calendar block — call it two hours, twice a year — and a short list run against every app you still have published, not just the current one:

Open the project and build it, today, on current tooling. Not "check the code" — actually produce an upload-ready binary. That single step surfaces clocks one and two before they're urgent, and it's the difference between a hotfix taking an hour and taking a week.

Read your own target API level off the Play Console rather than from memory, and compare it to the current requirement. If you're behind, you already know why installs softened.

Check the last-updated date on each listing. Anything approaching three years with thin downloads is queued for the sweep, and a small update resets that clock.

Confirm where store email goes and that the membership renews on a card that hasn't expired. These are the two failures with the most embarrassing ratio of consequence to cause.

While you're in there

An app you have to rebuild anyway is an app whose listing you may as well refresh. A store page assembled three years ago is selling against screenshots drawn for a device size that's since been retired, in a visual language that has aged the way all visual languages do — and unlike the binary, that part you can update without a compiler.

ShotCanvas exists for exactly that pass: drop in current screens, pick a template, and export pixel-exact sets for every App Store and Google Play slot — or publish them straight to both stores without opening a console. It's the cheapest half-hour in the whole maintenance block.