Google Play Mandates Privacy-First Access Patterns
Google Play is overhauling how apps request contact and location data, introducing mandatory privacy-focused alternatives and developer declaration systems ahead of October enforcement deadlines.
The new Contact Picker requirement replaces broad READ_CONTACTS permission requests with a user-controlled selector that shares only specific contacts chosen by the user. Apps using contacts for one-time actions like sharing or inviting must migrate to the picker or alternative privacy mechanisms like Sharesheet. The READ_CONTACTS permission remains available only for apps that require full, ongoing access to function — and those must justify the need through a Play Developer Declaration form launching before October.
Similarly, a streamlined Location Button now handles one-time precise location requests through a single-tap interface, replacing traditional permission dialogs for discrete actions like finding a nearby store or tagging a photo. Apps targeting Android 17+ that use precise location temporarily must implement the button via the onlyForLocationButton manifest flag. Apps requiring persistent precise location access must submit a declaration explaining why coarse location or the button mechanism cannot support their core features.
Developers gain enforcement visibility through new tooling: Android Studio's Play policy insights will flag contact and location compliance issues by October, and Play Console pre-review checks launch October 27 to catch violations before submission. These proactive features aim to reduce rejection friction and review delays — but they also signal that Google Play expects rapid adoption. The wiki:app-review-process for both platforms is tightening around privacy-first patterns, with automated detection of non-compliant permission usage already in place.
Apple Removes Scam Apps After Extended Chart Runs
Apple removed multiple high-profile apps in April following extended periods of data harvesting and policy violations — revealing gaps in both initial wiki:app-store-policy enforcement and ongoing monitoring.
Freecash, a rewards app that promised users up to $35 per hour for watching TikTok, ranked #2 in the U.S. App Store charts in January before removal in mid-April. The app collected extensive user data including race, religion, health information, and biometrics, and pushed users to install mobile games for in-app purchase conversion rather than delivering promised cash rewards. Despite media coverage in January exposing the deceptive marketing, Apple took no action until contacted by press in April, when the app was removed for violating guidelines prohibiting scams and misleading marketing.
Freecash accumulated 5.5 million downloads across Apple and Google Play in January alone, sustained chart positions through bot-driven ratings, and appears to have circumvented initial review by acquiring and repurposing an existing App Store listing — a tactic previously used to bypass the vetting process after an earlier ban in 2024.
A fake Ledger cryptocurrency app similarly bypassed App Store security, exposing users to potential fund loss before removal. These incidents underscore a recurring enforcement pattern: apps that violate wiki:app-review-guidelines at scale often remain live until external pressure forces action, rather than being caught by automated or ongoing review systems.
Apple Escalates AI-Assisted App Enforcement
Apple blocked updates for Replit and Vibecode in March, removed the "Anything" app entirely, and triggered litigation from Ex-Human over the removal of Botify and Photify AI — marking a shift from passive oversight to active enforcement against apps built with AI coding platforms.
The enforcement targets a specific technical violation: apps that generate and execute code at runtime rather than submitting all functionality for review upfront. This violates Guideline 2.5.2, which prohibits apps from downloading, installing, or executing code that introduces features after approval. Apps built with tools like Cursor or Bolt that compile to native binaries are unaffected — the issue is platforms that run unreviewed code inside the app itself, creating what Apple calls an "audit gap."
Additional violations cluster around Guideline 4.2 (minimum functionality — thin web view wrappers get rejected), Guideline 4.3 (spam detection for apps generated from identical templates), and Section 3.3.1(B) (interpreted code that changes the app's primary purpose post-review). Security data supports the crackdown: 45% of AI-generated code contains vulnerabilities, with AI output showing 2.74x more flaws than human-written code. An audit of apps built with one popular platform found over 170 apps with completely exposed databases and no row-level security, including one app leaking 18,697 user records.
App Store submissions surged 84% in a single quarter as AI-assisted development tools reached mainstream adoption, with iOS app launches up 56% year-over-year in December 2025 and 54.8% in January 2026. Apple processed approximately 200,000 weekly submissions at peak, pushing review times from 24–48 hours to 7–30+ days. The volume spike forced Apple to prioritize enforcement of existing quality and security thresholds rather than create new rules.
Developers using AI tools can still achieve approval by compiling to native binaries rather than web wrappers, eliminating all dynamic code execution, conducting human security audits of generated code, ensuring meaningful feature differentiation beyond generic templates, and providing complete metadata with demo credentials. The shift does not ban AI-assisted development — it enforces that all functionality must be present and reviewable in the submitted binary, regardless of how that binary was created.
Account Transfer Protections and Demo Login Requirements
Google Play introduces a mandatory account transfer feature in Play Console starting May 27, replacing informal ownership changes with a secure, auditable process that includes a 7-day security cooldown period. Unofficial transfers via shared credentials or third-party marketplaces are now prohibited, addressing fraud risks during acquisitions and mergers.
Developers seeking guidance on providing test access for apps with authentication systems should include demo accounts in submission materials rather than implementing separate testing login flows. Apple's wiki:app-review-guidelines require full reviewer access to all account-gated features, typically satisfied through demo credentials documented in App Review Notes rather than architectural changes to the app itself.