App Review Guidelines

App Review Guidelines

Definition

App Review Guidelines are the official policy documents that govern app content, functionality, and metadata on Apple App Store and Google Play Store. These guidelines define what is acceptable for distribution and inform both developer practices and ASO strategy. Non-compliance risks App Review rejection, demotion in rankings, or permanent removal. Understanding guidelines is essential for Product Page Optimization (PPO) and Keyword Research, as they constrain metadata tactics (no keyword stuffing, no misleading claims).

Store policy is no longer just a submission checklist completed before release. It is a product design constraint, a data-access constraint, a moderation obligation, a regional compliance requirement, and an operational risk-management system. Product, engineering, legal, trust and safety, user acquisition, and ASO teams all need to monitor guideline compliance continuously because metadata, permissions, monetization, content systems, account ownership, and regional availability can all trigger review action.

How It Works

Apple App Store

Apple's App Store Review Guidelines cover 44+ categories of requirements:

Key Sections:

1. Safety: Harmful content, fraud, illegal activities, and age verification mechanisms for regulated content.
2. Performance: Crashes, bugs, unfinished features.
3. Business: In-app purchases, pricing, subscriptions, ads.
4. Design: Metadata accuracy, screenshot authenticity, user privacy.
5. Legal: Copyright, trademark, data privacy (Data Safety & Privacy).
6. Apple Services: Use of proprietary APIs, HomeKit, health data.
7. Age Ratings & Regional Controls: Age assurance, gambling restrictions, loot-box disclosures, and local compliance requirements, particularly due to scrutiny from regulatory bodies in regions like Brazil.

ASO-Relevant Rules:

• Keyword Stuffing: "Do not include keywords, references to other apps, or extraneous information in the name, subtitle, or keywords field." Violation → keyword field stripped or app rejected.
• Screenshot Accuracy: Screenshots must depict the actual app. Fake UI, edited versions, or placeholder text → rejection.
• Misleading Metadata: Description, keywords, category must match functionality. Claiming fitness app but delivering meditation → rejection.
• Rating Manipulation: No fake reviews, review incentives, or review deletion schemes. Detected via Apple's ML → collection de-listing.
• Competitive Comparison: Avoid disparaging competitors; claims must be verifiable.
• Spam: No duplicate apps, no apps with minimal functionality designed purely for ranking. Template-generated apps without meaningful differentiation trigger rejection under Guideline 4.3. Generic scaffolds generated from commercialized templates are now detected by automated systems that identify duplicate code structures. Apps demonstrating meaningful differentiation and sufficient native functionality are more likely to pass review.
• Runtime Code Execution: Guideline 2.5.2 prohibits apps from downloading, installing, or executing code that changes features or functionality post-review. Apps that generate and run code within the app after passing review create an "audit gap" and face rejection or removal. This has become the primary rejection trigger in 2026, with enforcement systematically blocking platforms like Replit and Vibecode, and removing apps like "Anything." Removals have triggered litigation over withheld revenue exceeding $500,000, with regulatory scrutiny focusing on ensuring compliance against such practices.
• Web View Wrappers: Guideline 4.2 prohibits apps that are thin shells around remotely served content. Apps must provide native functionality, not just display web content generated elsewhere. React Native and Flutter apps that compile to native binaries pass review; thin web wrappers displaying remotely generated content are rejected.
• Minimum Functionality: Apps created from commercialized templates trigger spam detection. Apps must demonstrate meaningful differentiation and sufficient native functionality to pass review.
• Interpreted Code: Section 3.3.1(B) prohibits apps from using interpreted code that changes the app's primary purpose post-review.
• Reviewer Access: Apps with authentication systems must provide demo accounts in App Review Notes. Developers submitting apps with third-party authentication (Sign in with Google, Sign in with Apple) satisfy this requirement by providing functional demo accounts using those services — no separate username/password system is required. The key is ensuring reviewers have unobstructed access to all account-based features without requiring personal credentials or payment. Some developers implement dedicated demo modes to simplify the review process, though functional demo accounts for third-party OAuth flows are acceptable. Incomplete listings and inaccessible functionality are among the most common rejection reasons under Guideline 2.1. Apps that rely solely on third-party sign-in must either provision test accounts or build a secondary authentication flow for reviewers; failure to provide functional access results in immediate rejection. Review accounts should avoid two-factor prompts the reviewer cannot complete, include entitlements needed to test paid or restricted features, and be documented clearly in review notes.
• Pricing vs. Subscriptions: A free app with subscriptions should set the base app price to zero while configuring subscription pricing separately as in-app purchases. Unlike Google Play, where this process appears clearer, Apple requires developers to navigate specific pricing options in App Store Connect. Setting a price of 0.00 USD is typically correct for free apps, but developers should ensure clarity on what their app offers, particularly with subscriptions. Subscription tiers should be defined accurately, including any free trial options.
• AI Content Safeguards: Apps with generative AI, image editing, avatars, chatbots, or user-generated content must block prohibited output, not merely forbid it in terms of service. Moderation systems should account for prompt evasion, model workarounds, abuse monitoring, human escalation, repeat-offender handling, and evidence that safeguards work against common bypass attempts. Metadata, screenshots, keywords, ads, and promotional text cannot steer users toward banned use cases such as non-consensual sexual imagery.
• Age Ratings & Regulated Mechanics: The need for strict age controls has been emphasized by regulatory pressures, particularly in Brazil. Compliance with local laws, such as the ECA Digital framework, mandates that apps preventing minors from accessing age-restricted content must implement robust verification mechanisms. Developers must implement mandatory age-verification systems for apps classified under categories like gambling, ensuring compliance with emerging regulations and age restrictions.

Review Timeline:

• Historical standard: 24–48 hours (99% of submissions).
• Current reality (2026): 7–30+ days during peak submission periods.
• Complex/escalated: 3–7 days.
• Expedited review: Available (on-request) for time-sensitive releases; 24-hour turnaround.

Submission Volume Context: Weekly submissions peaked near 200,000 apps in Q1 2026, exceeding 200,000 apps by April 2026, an 84% increase driven by AI-assisted development tools. New iOS app launches rose 56% year-over-year in December 2025, followed by a 54.8% spike in January 2026. This surge has strained review infrastructure, increased rejection rates for pattern-detected template apps, and extended review times significantly.

Appeal Process:

• Rejection email includes reason + guideline reference.
• Developer can submit rebuttal with evidence within 30 days.
• Human review team evaluates; final decision binding.

Content Moderation Challenges: Apple has faced criticism for inconsistent enforcement of guidelines related to harmful content, particularly apps that generate non-consensual imagery. In response to concerns over app visibility and user safety, stricter evaluations of submissions that could violate user safety norms are now in place, reflecting an ongoing commitment to addressing regulatory expectations.

Google Play Store

Google's Developer Program Policies are less restrictive than Apple's but equally enforceable:

Key Sections:

1. Spam & Abuse: Repetitive content, keyword stuffing, cloaking, spam behavior.
2. User-Generated Content: Moderation requirements; liability for harmful UGC.
3. Intellectual Property: Copyright, trademark, patent infringement.
4. Restricted Content: Explicit content, violence, hate speech, illegal drugs, gambling, betting, and regulated activities.
5. Data & Privacy: Data collection, use, sharing; Data Safety & Privacy requirements.
6. Mobile Malware & Unwanted Software: Trojans, adware, spyware.

ASO-Relevant Rules:

• Keyword Stuffing: "Do not engage in keyword stuffing and spamming." Examples: "Free Yoga Fitness Meditation Free Yoga Free Fitness App Free Meditation." Google's system auto-flags; manual review on escalation.
• Cloaking: Delivering different content based on platform/user; misrepresenting app functionality.
• Fake Reviews: Artificial review inflation detected by ML; apps de-ranked or removed.
• Misleading Ads: If app is advertised via Google App Campaigns, claims must match store listing.
• Reviewer Access: If the app requires sign-in, the review team must be able to reach the app's core functionality. Working demo credentials, clear review notes, stable third-party sign-in flows, review-only entitlements, and access to paid or restricted features reduce avoidable rejection risk.
• AI and UGC Safety: Apps with generative AI, chat, avatars, image editing, or user-generated content need enforceable moderation systems. A submission package should include a prohibited-content taxonomy, prompt filtering strategy, image input restrictions, abuse monitoring workflow, human escalation process, repeat-offender handling, and evidence that safeguards work against common bypass attempts.
• Regulated Content by Region: Betting, lotteries, sweepstakes, gambling-adjacent mechanics, casino-style games, loot boxes, and real-money-adjacent entertainment require market-by-market review. Developers must ensure legal authorization, accurate age-rating questionnaires, pre-access age gates, and metadata that does not imply restricted availability where the product cannot legally operate.

Privacy & Permissions Enforcement (Enhanced October 2026):

• Contact Access: Apps targeting Android 17+ must use Android Contact Picker for contact sharing, invites, or one-time lookups. The READ_CONTACTS permission is reserved exclusively for apps requiring persistent, full access to the contact list. Apps requesting READ_CONTACTS must submit justification declarations through Play Console (Play Developer Declaration). The picker provides a searchable, system-controlled interface where users explicitly select which contacts to share, with apps receiving only the requested fields (phone numbers, email addresses, or other attributes) for selected contacts. Sharesheet is accepted as a privacy-friendly alternative for one-time contact sharing. The October 27, 2026 deadline marks the enforcement date for these requirements, with pre-review checks in Play Console flagging violations before submission.
• Location Access: Apps targeting Android 17+ must use the streamlined location button for discrete location actions (finding stores, tagging photos). Apps requesting always-on precise location must justify why coarse location or the button interface does not suffice through a Play Developer Declaration. The location button grants session-scoped access to precise coordinates without triggering a permission dialog, with access terminating automatically when the session ends. Apps requiring persistent precise location access must implement the button via the onlyForLocationButton manifest flag and submit declarations explaining why coarse location or the button mechanism cannot support their core features.
• Local Network Access: Apps targeting Android 17+ have local network access blocked by default. The new ACCESS_LOCAL_NETWORK permission is required for persistent local network features.
• Pre-Review Checks: Play Console flags potential violations during pre-submission checks starting October 27, 2026. Android Studio surfaces policy insights identifying which apps should adopt new privacy patterns, with these compliance checks embedded in the development workflow by October 2026. This tooling provides exact implementation steps and proactively identifies whether an app should use the Contact Picker or location button before submission. Developers should know they are in violation before they submit, not after they are rejected.
• Permissions Register: Teams should maintain a register for every sensitive permission: permission requested, feature requiring it, whether access is one-time, session-based, or persistent, user-facing explanation, store declaration status, screenshots or screen recordings proving the flow, and fallback behavior if the user declines. Automated pre-checks can catch obvious mismatches, but they do not fully validate whether feature claims, data use, UI disclosure, and runtime behavior are aligned.
• Conversion and Trust Impact: Privacy-sensitive permissions affect more than review. Broad contact and location prompts can reduce user trust, increase uninstall risk, and weaken store quality perception. Permission design should be treated as part of Data Safety & Privacy, onboarding, and conversion optimization.

Android 17 Platform Stability & Breaking Changes:

Android 17 reached platform stability with Beta 3, locking down the API surface and enabling apps targeting Android 17 to be published to Google Play. Several breaking changes now affect apps targeting Android 17:

• Resizability enforcement on large screens: Apps can no longer opt out of orientation, resizability, or aspect ratio constraints on tablets and foldables. Fixed-orientation apps must be refactored for adaptive layouts.
• Dynamic code loading restrictions: Safer Dynamic Code Loading (DCL) protections extend to native libraries. All native files loaded via System.load() must be marked read-only, or the system throws UnsatisfiedLinkError.
• Certificate transparency enabled by default: CT validation is no longer opt-in. Apps relying on certificates without CT logs will fail validation.

Account Security:

• Official Transfer System: Starting May 27, 2026, all account ownership transfers must use the official account transfer feature in Play Console. Unofficial transfers (sharing credentials, buying accounts through third-party marketplaces) are explicitly prohibited.
• Security Cooldown: Every transfer includes a mandatory seven-day security cooldown to allow teams to detect and cancel unauthorized takeover attempts. This addresses fraud vectors where developers lost control during acquisitions or business transitions. The cooldown period prevents instant ownership changes, requiring advance planning for business sales and mergers.
• M&A and Publisher Due Diligence: Acquisitions, asset sales, publisher changes, studio rollups, and distressed app purchases must account for the official transfer path. Due diligence should confirm clean seller control of the developer account, documented users and permissions, transferable payment profiles and tax records, unresolved reviews or policy strikes, and a transaction timeline that includes the cooling-off period.

Review Interface Updates: Google Play Store introduced search functionality for app reviews in early April 2026, allowing developers and users to query review content directly within the platform. The update removes the previous "device model" filter option, trading granular device-specific filtering for broader text-based discovery. The change reflects operational necessity as review volume reaches scales where chronological browsing no longer serves developer or consumer needs effectively.

Review Timeline:

• Automated review: Instant to <1 hour (90% of apps).
• Escalated human review: 1–3 days.
• No formal appeal process; can resubmit after fix.

Content Moderation Challenges: Google has faced similar scrutiny regarding harmful apps, particularly "nudify" apps that utilize AI to generate explicit content. Despite violations of policies against non-consensual sexual content, many of these apps remain discoverable and have generated significant revenue, reflecting a need for improved content moderation algorithms and user safety measures.

Amazon Appstore

Amazon's Appstore Developer Agreement and Content Guidelines:

Key Sections:

1. Content Standards: Similar to Apple/Google (no explicit, harmful, illegal content).
2. Functionality: Must be fully functional; no beta/demo apps.
3. Metadata: Accurate descriptions, genuine screenshots.
4. Fraud Prevention: No fraudulent apps, data harvesting.

Review Timeline: 2–7 business days (slower than Apple/Google).

Enforcement Realities

Reactive vs. Proactive Moderation

Platform enforcement has historically operated primarily through reactive mechanisms triggered by external complaints, media coverage, or regulatory scrutiny rather than continuous proactive monitoring. Both Apple and Google maintain clear policies prohibiting sexual exploitation, nonconsensual imagery, and harmful content, yet policy-violating apps regularly achieve distribution and sustained visibility.

The enforcement pattern is consistent: platforms act decisively after receiving detailed external reports or facing public pressure, but do not systematically prevent prohibited content from entering the store or gaining search visibility. Apps generating nonconsensual imagery, for example, have remained available for extended periods until flagged by external researchers, at which point platforms remove batches of flagged apps while functionally identical replacements surface within days.

Apple's handling of high-profile violations illustrates this dynamic. The Freecash app spent months collecting race, religion, health, and biometric data while engaging in deceptive marketing, reaching #2 in U.S. App Store rankings in January 2026 by promising users up to $35 per hour for watching TikTok content. The app was downloaded 5.5 million times across iOS and Android in January alone, using misleading TikTok ads, fake ratings, and bot-driven traffic to sustain its ranking. Evidence suggests the developers acquired an existing App Store app and renamed it to bypass initial review after an earlier ban in 2024. Apple removed Freecash in mid-April only after external inquiry — not through proactive enforcement. This removal reinforces that guidelines apply uniformly regardless of app popularity or developer profile.

A fake Ledger cryptocurrency app similarly bypassed App Store security, exposing users to potential fund loss before removal. These incidents reveal that apps violating guidelines at scale often remain live until external pressure forces action, rather than being caught by automated or ongoing review systems.

The Grok case further demonstrates this pattern. xAI's chatbot app was generating non-consensual sexualized deepfakes of real people. Apple privately warned xAI in January 2026 that it would remove Grok from the App Store unless the company eliminated the chatbot's ability to generate such imagery. The warning followed user-generated images of women and children created by Grok and posted to X, many based on photos of real people. Apple rejected xAI's initial content moderation plan as insufficient and demanded additional changes. After multiple rounds of back-and-forth, Apple eventually approved a revised submission, thereby testing Apple's longstanding defense of its curated App Store model: that human App Review keeps users safer.

Research has identified 18 apps on the App Store and 20 on Google Play generating non-consensual sexual images, with a combined 483 million downloads and $122 million in revenue. Some carried age ratings marking them suitable for minors. Apple removed 15 apps after external reporting surfaced, but functionally identical replacements reappear within months. Many of these apps were promoted through autocomplete suggestions and search rankings, with approximately 40% of top-ten results for certain prohibited content searches returning policy-violating apps. Some appeared through sponsored placements, indicating that discovery infrastructure optimizes for engagement patterns without adequate policy evaluation layers.

However, enforcement has intensified significantly for AI-generated apps and code security violations. High-profile removals in March 2026 included the "Anything" app (complete removal), Replit and Vibecode (update blocks), and Ex-Human's Botify and Photify AI apps (mid-revenue removal triggering litigation over $500,000 in withheld revenue, with the company reporting collective monthly revenue exceeding $400,000). The common thread: runtime code execution creating an "audit gap" where functionality exists in production but was never reviewed. Apps generating a combined $430,000 per month in revenue were removed or blocked from updates.

Proactive Enforcement Shift

Both platforms are implementing proactive enforcement mechanisms to address the surge in automated app generation, representing a permanent change from reactive to preventive enforcement:

Google Play:

• Pre-review checks in Play Console (October 27, 2026) flag policy violations before submission.
• Android Studio integration surfaces policy insights during development by October 2026.
• Automated detection of privacy pattern violations for Android 17+ targets.
• Compliance checks embedded upstream in development workflow, reducing costs of discovering violations at submission.
• Narrower, user-mediated data-access patterns for contacts, location, and local network access.
• Formalized account-transfer workflows to reduce hijacking and post-sale disputes.

Apple App Store:

• Pattern detection algorithms flag template-generated apps lacking meaningful differentiation.
• Increased scrutiny of apps with identical structures to thousands of others.
• Enhanced security audit for AI-generated code vulnerabilities.
• Static analysis of submitted binaries to ensure shipped functionality matches reviewed functionality.
• Stricter treatment of AI systems that can generate non-consensual sexual content.
• Expanded age-assurance expectations in markets with stronger child-protection and gambling controls.

Violations are now caught earlier in the development pipeline, with compliance becoming a pre-build consideration rather than a post-build check. Automated tooling reduces excuses, not obligations: it can identify obvious risk signals, but developers remain responsible for aligning feature claims, runtime behavior, permissions, disclosures, metadata, and regional availability.

Discovery Systems and Policy Violations

Platform search algorithms and advertising systems can actively surface content that violates stated policies. Search queries for terms associated with exploitative AI tools return dozens of apps in top results, with some appearing through sponsored placements. Approximately 40% of top-ten results for certain prohibited content searches return policy-violating apps. Some carry age ratings marking them suitable for minors.

Autocomplete suggestions in App Store Search guide users toward prohibited content categories by completing partial queries with policy-violating terms. This indicates that discovery infrastructure optimizes for engagement patterns without adequate policy evaluation layers. Sponsored ad placements compound the issue by allowing paid promotion of apps that generate non-consensual imagery without friction.

The implication for Keyword Research and Product Page Optimization (PPO):

competitive analysis may include apps that should not exist on the platform, distorting keyword difficulty assessments and category benchmarking. ASO teams should treat prohibited-intent terms as policy liabilities, not merely demand signals. Keywords such as "undress," "nudify," or similar intent terms can create existential review risk when they imply prohibited behavior.

The broader platform shift is accountability for discovery. If search, autocomplete, ads, or recommendations help users find prohibited behavior, stores face pressure to fix the system rather than only remove individual apps. Apps operating near the edge of privacy, AI generation, minors, money, or regulated content should assume closer review and shorter tolerance for weak safeguards.

Inconsistent Cross-Category Standards

Enforcement consistency varies significantly across content categories. Platforms remove narrative games with industry-standard content warnings and age ratings for mature themes while allowing apps generating non-consensual imagery to remain available for extended periods. A psychological horror game with an ESRB "M" rating, content warnings, and availability on console platforms was delisted from Google Play under the Sensitive Content policy after months of distribution, while exploitative AI tools persisted despite clear policy violations.

This inconsistency suggests moderation is driven by perceived liability rather than uniform policy application, creating uneven enforcement realities.

Fraud, Impersonation, and Sensitive Categories

Fraudulent apps expose users to direct harm and increase pressure for stricter review, especially in categories involving money, identity, health, security, and credentials. Crypto, finance, identity, health, VPN, security, and account-management apps should expect higher verification standards and more scrutiny of brand ownership, developer identity, metadata, and post-approval behavior.

Legitimate brands should treat defensive ASO as part of trust and safety:

• Make brand ownership unmistakable.
• Keep developer account identity aligned with the product brand.
• Avoid misleading names, icons, subtitles, or screenshots.
• Monitor copycat listings and file complaints quickly.
• Use in-app warnings where user funds, keys, credentials, or recovery phrases are involved.
• Maintain a visible support and incident-response channel.

Search result pages for wallets, banks, exchanges, password managers, VPNs, and security products are fraud surfaces. A misleading listing can harm users even before the app is installed.

Operational Compliance Practice

Store guidelines should be managed as a release management system rather than a final submission task. Every app team should maintain four living documents:

• Policy matrix: Applicable Apple and Google rules by feature, category, region, and monetization model.
• Permission register: Every sensitive permission, the feature justification, user-facing flow, declaration status, fallback behavior, and evidence of the permission experience.
• Moderation file: Content rules, prohibited-content taxonomy, automated enforcement, human escalation, abuse monitoring, repeat-offender handling, and testing against bypass attempts.
• Submission playbook: Reviewer credentials, pricing setup, in-app purchase configuration, declarations, screenshots, review notes, regional restrictions, and release-owner responsibilities.

ASO teams should be included in this process. Metadata can create policy risk as easily as code can. Keywords, screenshots, promotional text, category choices, age-rating answers, and localized creative all shape how stores interpret the product.

The strongest teams build compliance into roadmap planning, creative testing, localization, launch sequencing, and account operations. Compliance is not separate from growth; it affects discoverability, conversion, retention, review predictability, and platform access.

Recent Updates

• 2026-05-08: Store guideline compliance expanded from submission checklist to continuous product, privacy, moderation, regional, and operational governance.
• 2026-05-08: Google Play permission enforcement emphasized contact and location alternatives, pre-review tooling, permission registers, and formal account-transfer workflows.
• 2026-05-08: AI content safety, minors, gambling-adjacent mechanics, financial impersonation, and discovery-system accountability became higher-risk review areas.
• 2026-05-09: Developers must implement mandatory age-verification systems for apps in regulated categories, following rising regulatory pressures.
• 2026-05-10: Enhanced scrutiny regarding harmful content and age restrictions highlighted by recent regulatory actions, including necessary compliance with age verification mechanisms for betting apps.
• 2026-05-11: Significant focus on user safety and regulatory compliance reinforced through stricter policies on harmful content and robust privacy measures, particularly for age-restricted apps.
• 2026-05-12: The importance of staying informed on compliance pressures and adapting to evolving app store guidelines emphasized in response to regulatory scrutiny, especially concerning age verification in betting applications.
• 2026-05-13: Developers urged to adopt privacy-first approaches and enhance user education about app privacy measures to improve trust and compliance.
• 2026-05-16: App developers reminded to declare age restrictions for gambling apps and actively utilize compliance tools to ensure alignment with local regulations, especially in regions like Brazil.
• 2026-05-17: Clarity on submission requirements for pricing and subscriptions reinforced, including the need to set correct pricing tiers for free apps, and the inclusion of all relevant visual assets like screenshots for better visibility.