Google Play Mandates Privacy-First Contact and Location Access as Apple Intensifies App Review Enforcement

Google Play's New Privacy-First Access Requirements

Google Play is implementing mandatory privacy controls for contact and location access, requiring developers to migrate away from broad-permission models by October 2026. The changes center on two new frameworks designed to reduce user friction while strengthening privacy protections.

The Android Contact Picker becomes the required standard for any app requesting contact information for sharing, invites, or one-time lookups. Apps targeting Android 17 and above must remove the READ_CONTACTS permission entirely unless they can justify persistent, full-access requirements through a Play Developer Declaration. The picker allows users to share only specific contacts rather than granting blanket access to their address book.

Similarly, a new location button replaces complex permission dialogs for apps requiring one-time precise location data — such as finding nearby stores or geotagging photos. Apps targeting Android 17 and above must implement the onlyForLocationButton flag in their manifest unless they can document why persistent precise location access is essential to core functionality.

Developers have until October to prepare. Google is deploying two enforcement mechanisms: Play policy insights in Android Studio will proactively flag apps that should adopt these frameworks, and pre-review checks in Play Console (launching October 27) will surface wiki:app-review blockers before submission. This mirrors the increasingly automated compliance screening we have seen in wiki:app-store-submission-process workflows on iOS.

Apple's Escalating Enforcement Against Runtime Code Execution

Apple has simultaneously intensified enforcement of long-standing guidelines prohibiting apps from downloading, generating, or executing code after passing review. The crackdown targets apps that create what Apple calls an "audit gap" — functionality that exists in production but was not present during the original review.

In March 2026, Apple blocked updates for Replit and Vibecode, both platforms that enable users to generate and run software from within the app. The company pulled the "Anything" app entirely after it attempted to circumvent restrictions by opening generated content in an external browser rather than an embedded web view. A lawsuit followed from Ex-Human, a San Francisco startup claiming Apple is withholding over $500,000 in revenue after removing its apps Botify and Photify AI.

The enforcement is not an outright ban on AI-assisted development — Apple already integrates OpenAI and Anthropic into Xcode. The issue is dynamic code execution at runtime, which violates Guideline 2.5.2. Apps must be self-contained in their submitted bunaries and may not introduce features or functionality after wiki:app-review. Security audits have found that 45% of AI-generated code contains vulnerabilities, and AI-written code has 2.74 times more security flaws than human-written code. One audit of apps built with AI platforms found 170+ apps with completely exposed databases, including one app leaking 18,697 user records.

Apps built using AI coding tools like Cursor, Lovable, or Bolt are not inherently at risk — the distinction lies in how the final binary is constructed. Tools that compile to native iOS binaries pass review normally. Tools that generate and execute code within the app violate existing policy.

• Audit contact and location usage — Identify which permissions your app requests and whether they can be replaced with the new privacy-first frameworks.
• Implement the contact picker — Replace READ_CONTACTS with the Android Contact Picker for sharing, invites, and one-time lookups.
• Adopt the location button — For one-time precise location actions, implement the onlyForLocationButton manifest flag.
• Prepare Play Developer Declarations — If your app genuinely requires persistent full access to contacts or location, draft documentation explaining why coarse location or selective access is insufficient for core functionality. The declaration form will be available before October.
• Monitor pre-review checks — Use the Play Console pre-review system launching October 27 to identify compliance issues before submission.

For iOS Developers

• Avoid dynamic code execution — Ensure your app does not download, generate, or execute code after passing wiki:app-review. Use server-driven configuration (feature flags, remote config) for behavior changes rather than code injection.
• Conduct human security audits — Do not ship AI-generated code without line-by-line review. Audit for exposed API keys, missing input validation, authentication bypass, unencrypted storage, and hardcoded credentials.
• Build native, not web wrappers — Apps that are thin wrappers around remotely generated web content violate Guideline 4.2 (Minimum Functionality). Compile to native iOS binaries.
• Test on real devices — AI-generated code often works in simulators but breaks on hardware. Test across multiple device types before submission.
• Provide demo credentials — Include demo account credentials in App Review Notes. Reviewers cannot test functionality they cannot access.

Both platforms are moving toward the same outcome: reduced runtime flexibility in exchange for stronger user privacy and security guarantees. Developers who treat compliance as a last-minute checklist will face lengthening review cycles and heightened rejection risk. Those who integrate these requirements into their development process early will avoid submission delays and maintain velocity in increasingly competitive app markets.