Google Play Store to require apps to target SDK no more than one year older than current release starting late 2018; new, native apps must offer 64-bit in 2019
The Play Store created some controversy last month after announcing plans to remove apps that used Accessibility Services …
Context & Ripple Effects
This 2017 announcement is the origin point of Google's now-familiar playbook of using Play Store distribution rules to force developer behavior. It followed an earlier compliance push where developers had to post valid privacy policies by March 2017 or risk removal, and it landed amid a broader tightening: months later Google would ban crypto miners, firearm-sale aids, and ad-only apps from the store.
What makes this specific rule consequential is how durable it proved — five years later Google formalized the same logic into a standing mechanism, planning to hide and block apps that don't target an API within two years of the latest release. The one-year SDK window and the 2019 64-bit mandate were the template.
First-order effects
- Developers shipping apps on outdated SDK targets must recompile against a current Android release within roughly a year or their updates lose access to the Play Store, and new native apps must ship 64-bit binaries starting in 2019.
Second-order effects
- Teams maintaining large legacy catalogs face recurring porting work every annual Android cycle, raising the effective cost of keeping low-traffic apps alive and pushing some toward abandonment rather than maintenance.
Third-order effects
- If the pattern holds — and the later two-year hide-and-block rule confirms it did — SDK currency becomes a permanent, automated gatekeeping layer, letting Google deprecate old APIs and enforce security baselines through distribution rather than persuasion.
The trend: Google is converting the Play Store from a passive marketplace into an active enforcement tool for platform modernization, with each policy wave ratcheting minimum technical requirements upward.