App review is the evaluation that an app store operator performs on a submitted mobile app or update to verify that it complies with the store’s policies on safety, privacy, functionality, content and payments before it is distributed to users. In mobile distribution, it is the gate between a finished build and the public: an app that does not pass review cannot be published through that store, regardless of its technical quality.
Both major stores review apps, but with different emphasis. Apple’s App Review relies heavily on human reviewers working from the App Review Guidelines, while Google Play combines automated scanning and policy enforcement with human review, and continues to monitor apps after they are published.
How the app review process works
The app review process starts when a developer submits a build together with its store metadata through App Store Connect or Google Play Console. The submission includes not only the binary but also the description, screenshots, age rating answers, privacy disclosures and, where needed, demo account credentials for reviewers.
- Automated checks scan the binary for malware, private API use, missing declarations and technical defects.
- Policy review compares functionality, content and metadata with the store’s guidelines.
- Functional testing launches the app on devices to confirm it works and matches its description.
- A decision is issued: approved, rejected with cited guideline sections, or held for more information.
- After approval, the developer releases the version manually, automatically or as a staged rollout.
Review time is not guaranteed. Many submissions are processed within one or two days, but new developer accounts, sensitive categories such as finance or health, and apps that request powerful permissions often take longer and receive closer scrutiny.
What reviewers check
Reviewers check whether the app is safe, complete, honest and correctly monetized. Although wording differs between stores, the main areas are broadly similar.
| Area | Typical requirements | Frequent problems |
|---|---|---|
| Completeness and performance | No crashes, no placeholder content, working links | Crashes on launch, broken login, test data |
| Privacy and data use | Accurate disclosures, permission justification | Undeclared data collection, unnecessary permissions |
| Payments | Store billing for digital goods where required | Unapproved external payment links |
| Content and safety | Age rating, moderation of user content | Missing reporting and blocking tools |
| Metadata accuracy | Screenshots and description match the app | Misleading claims, irrelevant keywords |
| Minimum functionality | Real value beyond a repackaged website | Thin wrappers, template apps |
Privacy has become the most demanding area. Apple requires privacy nutrition labels and justification strings for each permission, while Google Play requires a data safety section and declarations for sensitive permissions such as background location, all of which must match the app’s actual behavior, including third-party SDKs.
App review on Apple and Google platforms compared
The two main stores share the goal of app review but differ in method, timing and enforcement after publication. These differences affect release planning.
| Aspect | App Store | Google Play |
|---|---|---|
| Primary method | Human review of every submission | Automated analysis plus human review |
| Rule set | App Review Guidelines | Developer Program Policies |
| Beta builds | External TestFlight builds get a lighter review | Testing tracks, with review for public tracks |
| New personal accounts | Standard review | Closed testing period required before production |
| Post-release enforcement | Removal for later violations | Ongoing scanning, warnings, suspensions |
| Appeals | Reply in App Store Connect, appeal to review board | Appeal through Play Console |
Where regulation allows alternative app marketplaces or sideloading, a lighter form of review may still apply. In the European Union, for example, apps distributed outside the App Store must pass Apple’s notarization, which focuses on security and integrity rather than on business rules.
Preparing a submission that passes review
The most reliable way to pass app review is to remove ambiguity for the reviewer. A reviewer has limited time, no context about the product and often no access to the developer’s backend or hardware.
- Provide a working demo account with sample data and explain any features behind special hardware or regions.
- Write clear review notes describing non-obvious features, payment flows and why each sensitive permission is needed.
- Test the exact release build on a clean device and the oldest supported OS version.
- Align metadata with the app, including screenshots, age rating and privacy declarations.
- Audit third-party SDKs so their data collection appears in the store disclosures.
Teams that release often also plan for review time. A phased or staged rollout after approval limits the impact of defects, and Apple offers expedited review requests for critical fixes, which are granted at its discretion.
Handling rejections
A rejection cites the guideline or policy section that the reviewer believes is violated, sometimes with screenshots. The right response depends on whether the finding is a defect, a misunderstanding or a policy disagreement.
| Situation | Recommended response | Reason |
|---|---|---|
| Real defect or missing declaration | Fix and resubmit | Fastest path to approval |
| Reviewer missed a feature | Reply with explanation and steps | Often resolved without a new build |
| Metadata issue only | Update store listing | No new binary required |
| Disagreement on policy interpretation | Formal appeal with clear arguments | Escalates to a separate team |
A common mistake is resubmitting the same build without changes or explanation, which usually produces the same result and delays the release further. Keeping a record of past rejections helps teams avoid repeating the same issue in later versions.
In simple terms
App review is the check an app store makes before an app goes live. The store looks at whether the app works, whether it is honest about what it does and whether it handles personal data properly.
It is similar to a building inspection before a shop opens. The inspector does not judge whether the shop will be popular. The inspector checks that it is safe and follows the rules. If something is wrong, the owner fixes it and asks for another visit.
A practical example
A small team submits a meal-planning app with a subscription. The first submission is rejected for two reasons: the reviewer could not get past the login screen, and the app asked for location access without explaining why.
The team adds a demo account in the review notes, rewrites the permission message to explain that location is used to suggest nearby grocery stores, and makes the feature optional. They also confirm that the subscription uses the store’s in-app purchase system. The resubmitted build is approved within a day, and the team keeps a checklist of these items for every future release.