Enforcement action accelerates across both platforms
The rhythm of wiki:app-store-policy enforcement has changed. Apple pulled multiple high-profile apps in recent weeks — including a scam rewards app that harvested biometric data from 5.5 million users and a fake crypto wallet that bypassed wiki:app-review-process entirely. In parallel, Google Play announced sweeping policy updates that require developers to adopt new privacy-preserving APIs for contact and location access by October, backed by pre-submission compliance checks in Play Console.
This is not routine policy iteration. Both stores are tightening the gap between stated guidelines and actual enforcement, and the message is consistent: apps that rely on ambiguous language, post-approval workarounds, or legacy permission models are now at immediate risk.
Apple's enforcement: removal after the fact, not prevention
Apple removed the Freecash app only after external media coverage forced the issue. The app had climbed to #2 in the U.S. App Store by marketing itself as a TikTok-watching cash opportunity, but instead harvested race, religion, health, and biometric data while pushing users toward ad-heavy mobile games. Developers appear to have acquired an existing approved app, renamed it, and updated functionality to bypass review — a tactic that worked for months.
Separately, Apple threatened to pull xAI's Grok chatbot after the app generated nonconsensual sexualized deepfakes of real people, including minors. Apple rejected the initial content moderation plan as insufficient and only approved the app after multiple iterations. The incident was disclosed in a letter to U.S. senators who had urged removal, making clear that Apple's enforcement was reactive, not proactive.
These cases expose a recurring pattern: apps reach high visibility before review failures become public, and removal happens only when the reputational cost of inaction exceeds the cost of enforcement.
Google Play's API mandate: privacy by design, enforced by tooling
Google is taking a different approach. Starting October 27, apps targeting Android 17 must use the new Contact Picker API for one-time contact access, replacing the broad READ_CONTACTS permission. Apps requiring ongoing contact access must submit a Play Developer Declaration justifying the need. Similarly, one-time location requests must use the new location button API rather than persistent precise location permissions.
Developers who fail to comply will encounter pre-review checks in Play Console that flag permission policy violations before submission. Android Studio will surface compliance insights starting in October, guiding developers toward the exact changes required. This is enforcement through tooling — the policy is baked into the development workflow, not left to manual review.
The shift also introduces an official account transfer feature in Play Console, mandatory as of May 27, with a seven-day security cool-down to prevent unauthorized ownership changes. Unofficial account sales or credential sharing are now explicitly prohibited.
AI-generated content becomes an enforcement priority
Both platforms are grappling with AI-generated content that violates app store guidelines but evades detection at submission. A Tech Transparency Project report found 38 "nudify" apps across the App Store and Google Play — apps that create fake nude images from user photos — with a combined 483 million downloads and $122 million in revenue. Many were rated "E for Everyone," making them accessible to children.
Apple and Google both ban non-consensual sexual content, yet their stores actively promoted these apps through autocomplete suggestions and search rankings. After the report, Apple removed 15 apps, but the underlying issue remains: generative AI models change behavior post-approval, and current review processes cannot detect prompt-based evasion tactics.
This is the new enforcement gap. Apps that pass review can activate harmful features later, either through server-side updates or by teaching users how to bypass safeguards. Traditional wiki:app-review catches static violations at submission, but AI-driven apps shift their behavior after approval.
What this means for developers
Assume compliance will be enforced retroactively. Apps approved months ago are now subject to removal if policy violations surface publicly. The approval timestamp is not a shield.
Adopt privacy-first APIs early. Google's October deadline for Contact Picker and location button adoption is firm, and pre-submission checks will block apps that ignore the requirement. Review your permission requests now.
Treat demo accounts and test credentials as submission-critical. Apps requiring sign-in must provide functional demo credentials in wiki:app-review notes. Apps that rely solely on Google or Apple Sign-In must either provision test accounts or build a secondary auth flow for reviewers. Failure to do so results in immediate rejection.
Content moderation must cover post-approval behavior. If your app includes user-generated content, AI outputs, or server-driven features, your moderation plan must account for what happens after submission. Relying on "for entertainment purposes" disclaimers or reactive filtering will not prevent removal.
Account security is now a compliance issue. Unofficial account transfers — buying pre-approved developer accounts, sharing credentials, or using third-party marketplaces — are grounds for expulsion from both programs. Google's new transfer feature with mandatory cool-down is the only permitted method.
The shift we are tracking
Enforcement is moving from gatekeeping at submission to continuous compliance monitoring post-approval. The old model — pass review once, update freely — no longer holds. Apps that change behavior, harvest unexpected data, or enable harmful content after approval are being removed, often only after public scrutiny forces action.
At the same time, privacy-first API requirements are becoming mandatory, not optional. The transition from broad permissions to scoped, user-controlled access is no longer a recommendation — it is enforced through tooling, pre-submission checks, and developer declarations.
The gap between policy and enforcement is closing, but the mechanism is reactive removal, not proactive prevention. That leaves developers exposed: the app that passes review today may be pulled tomorrow if its behavior shifts or if external coverage reveals a violation that review missed.
Plan accordingly.