Guideline libraryTopic overview

The review process, app quality and enforcement: how it all fits together

Behind each rejection is a process, and understanding it makes the messages easier to read. Both stores combine automated analysis of the submitted app with human review. Automated checks look for things such as private API use, missing permission explanations and known malicious code. Reviewers then use the app, read the listing and compare the two.

Quality rules are the least dramatic and the most frequent. They cover whether the app works, whether it is complete, whether its screenshots and descriptions are accurate and whether its age rating matches its content. Security rules cover what the code is allowed to do, including what it may download and what it may run in the background.

Finally there is enforcement. Violations are not only about a single submission. Google tracks them at the developer-account level, and Apple considers repeated problems as a pattern. Account integrity rules exist so that enforcement has consequences that cannot be avoided by starting again under a different name.

How Apple approaches it

Apple's Performance section covers completeness and bugs in 2.1, beta builds in 2.2, undocumented features in 2.3.1 and the accuracy of metadata across 2.3. Technical rules include public-API use in 2.5.1 and self-contained apps in 2.5.2, and malware is covered by 2.5.3. Developer information must be real and reachable under 1.5.

Apple's 2.1 guideline also serves as the route for information requests, particularly for new developer accounts.

How Google Play approaches it

Google Play combines functionality and quality expectations with policies on store-listing metadata, content ratings, malware, device and network abuse and third-party SDKs. Developer Account Integrity and the Policy Strikes System describe how violations accumulate across an account, and the Target API Level rule sets a technical baseline that is raised roughly once a year.

Where the two platforms differ

Apple reviews most submissions before they go live. Google publishes after review as well, but relies heavily on automated analysis and continues to scan apps after release.
Apple's information requests under 2.1 have no direct Google equivalent, although Play can ask for declarations and supporting material.
Google's account-level strike system is explicit. Apple's enforcement is described less formally but also considers a developer's history.
Google sets a yearly target API level requirement. Apple has equivalent technical requirements tied to its tools and operating-system releases.
Both hold developers responsible for the behaviour of third-party code in their apps.

What reviewers typically check

Whether the app installs and runs on a physical device, and whether the main features can be reached, including through a demo account.
Whether placeholder content, debug options or beta labels remain in the build.
Whether screenshots, descriptions, previews and ratings accurately describe the build.
Whether the app's code or its libraries use restricted interfaces, download executable code or behave like malware.
Whether the developer information and contact details are real and reachable, and whether the account has a history of violations.

Key terms

Binary: The compiled app that is installed on a device, as opposed to the store listing around it.
Metadata: The listing information, including name, description, screenshots, keywords and ratings.
Resolution Center: The part of App Store Connect where App Review sends messages about a submission.
Play Protect: Google's service that scans apps for harmful behaviour.
Target API level: The Android version an app declares it is built for, which Google Play requires to be recent.

Common questions

Do both stores review apps by hand?

Both combine automated analysis with human review, in different proportions and at different times.

Why can a violation found in an old app affect a new one?

Enforcement is tracked at the developer-account level, so history follows the account.

Is a build problem the same as a listing problem?

No. The stores distinguish findings about the app itself from findings about its listing, which can have different effects on a submission.

Apple guidelines on this topic

1.1.6 — False information and featuresYour app's description and functionality can't misrepresent what it actually does.1.5 — Developer informationYour support URL, contact info, and developer name have to be accurate and actually reachable.2.1 — App CompletenessBroken links, placeholder content, or crashes during review will get an app rejected.2.2 — Beta testingBeta or unfinished builds can't be submitted for regular App Store review — that's what TestFlight is for.2.3.1 — Hidden or undocumented featuresEvery feature in your app has to be visible and described in your review notes — nothing unlocked later or hidden from reviewers.2.3.12 — New features descriptionThe "What's New" release notes have to actually describe what changed in that version.2.3.3 — Screenshot accuracyScreenshots have to show your actual app running, not marketing mockups or another platform's UI.2.3.4 — Preview requirementsApp preview videos have to be actual captured app footage, not staged or heavily edited demos.2.3.5 — Appropriate category selectionThe primary category you pick in App Store Connect has to genuinely match what the app does.2.3.6 — Honest age ratingThe age-rating questionnaire answers have to match what's actually in the app.2.3.8 — Metadata appropriate for all audiencesApp name, description, and screenshots have to be appropriate for a general audience, regardless of the app's actual age rating.2.4.1 — iPhone and iPad compatibilityIf your app runs on iPad, it has to actually work well on iPad, not just be a stretched iPhone layout.2.4.2 — Power efficiencyAn app that drains the battery abnormally fast for what it does will get flagged.2.5.1 — Public APIs onlyApps can only use Apple's public, documented APIs — no private frameworks or undocumented calls.2.5.16 — Widgets, extensions, and notificationsWidgets and extensions have to follow the same design and functionality rules as the main app, on their own.2.5.2 — Self-contained appsApps can't download or execute new code after install — everything has to ship in the reviewed binary.2.5.3 — Malware transmissionAn app can't include code designed to damage, disable, or gain unauthorized access to a user's device.2.5.4 — Multitasking background servicesBackground execution modes can only be used for what they're actually designed for.4.2 — Minimum functionalityAn app has to do more than wrap a website or repackage content with nothing native added.4.2.3 — App independenceYour app has to be a complete, standalone experience, not one piece of a larger unpublished product.

Google Play policies on this topic

Account Integrity — Developer account integrityGoogle requires developer accounts to be genuine, singly-owned, and not created to evade a prior suspension.Android Auto — Android Auto compliance requirementsApps that extend to Android Auto have extra restrictions around driver distraction — most notably, video and free-text input are off-limits while driving.App Promotion — App promotion and incentivized installsPaying people to install your app, or rewarding installs with cash-equivalent value, distorts rankings and isn't allowed.Content Ratings — Content rating accuracyThe IARC content rating questionnaire has to match what's actually in your app, not what you wish the rating was.Device Abuse — Device and network abuseApps can't interfere with other apps, download executable code, or degrade device performance.Functionality — Functionality, content and user experienceThe app has to work as advertised, without excessive crashes or an essentially empty experience.Hostile Downloaders — Hostile downloadersAn app whose real purpose is installing other apps — without being clear about it upfront — isn't allowed on Play.Malware — Malware policyGoogle auto-scans every app; a false positive here still blocks your submission until resolved.Metadata — Store listing metadataYour Play Store listing text and images have to accurately represent the app, no keyword stuffing.Misrepresentation — Store listing and ratings misrepresentationBuying reviews, incentivizing five-star ratings, or otherwise gaming your store listing's reputation is a policy violation.Ratings & Reviews — User ratings, reviews, and installsReviews and ratings have to come from real users with genuine opinions, not incentives, bots, or coordinated campaigns.SDK Requirements — Third-party SDK complianceYou're responsible for every SDK you ship, even when the violating behavior comes from the SDK vendor's code, not your own.Strikes System — Policy strikes and enforcement escalationRepeated policy violations accumulate against your developer account, not just the individual app, and escalate toward account termination.Target API Level — Target API level requirementsApps have to target a recent Android API level — Google blocks updates to apps that fall too far behind.Wear OS — Wear OS compliance requirementsWear OS apps and tiles are expected to work as standalone, glanceable experiences — not a shrunk-down copy of the phone app.

Platform rules change often. This page is a plain-language overview written by AppReviewFix, not official guidance. Check the App Store Review Guidelines and the Google Play Developer Program Policies for the exact current wording.

Other topicsPrivacy and data rules on the App Store and Google Play Payments, in-app purchase and subscription rules explained Content, user safety and legal rights: what reviewers look for Spam, copycat apps, ads and deceptive design explained Children’s apps: Kids Category, Designed for Families and child privacy