How to read an App Review or Google Play policy message

The guideline reference

An App Store message begins with a guideline number and a short heading, such as a number from the Performance section followed by a title. The number tells you which part of the guidelines the reviewer is citing, and the section it sits in tells you the general area: safety, performance, business, design or legal. The same number can cover several distinct problems, so the reference is a pointer rather than a diagnosis.

Google Play notices name a policy, for example User Data or Deceptive Behavior, and often a specific sub-requirement. Because Play policies are broader, the sub-requirement and the description of the issue carry more of the detail.

The finding

After the reference comes a short description of what the reviewer found. Apple's text is often a template with a few specifics filled in, which is why different developers receive near-identical wording for different underlying problems. Details that tend to matter are the build number, the device and operating-system version used, and any screens or flows named.

Where a message includes a list of numbered requests, the order is usually the order in which the reviewer encountered the issues or the order of Apple's standard template. It is not a ranking of importance.

Sections such as "Next Steps" and "Prevent Common Issues"

Some Apple messages end with a block describing next steps and a second block listing common issues to avoid. These are partly generic. The next-steps block describes what Apple wants in reply. The common-issues list is a reminder of related guidelines and does not mean that each item was found in your app.

A frequent misreading is to treat every bullet in a common-issues list as a separate finding. The distinction matters because, as the guidelines themselves say, only the items stated in the finding describe what the reviewer actually observed.

Binary and metadata findings

Reviewers distinguish between the build itself and the listing around it. Findings about screenshots, descriptions, keywords, age ratings and previews belong to the listing, while crashes, missing features and technical rules belong to the build. Messages usually make clear which one they concern, and the distinction determines what has to change for the review to proceed. A separate guide on this site explains the difference in more detail.

Reading Google Play notices

Google's notices typically state the app and release affected, the policy cited, an explanation, and the status that results, such as a rejected update or a removed app. They also describe what is reviewed next. Because Google runs many checks automatically, notices can arrive after a release has already gone live, and the wording will say whether the action applies to a specific version or to the app as a whole.

Common phrases and what they usually indicate

Phrases such as "we were unable to" or "we could not" generally describe something the reviewer tried and could not complete, for example signing in or reaching a feature. Wording such as "your app appears to" often introduces a judgement made from observation, and "your app does not" describes something more definite. Reading these cues helps separate a technical obstacle from a policy finding.

Information about the review environment

Messages often state the device model and operating-system version used. This is not decoration. It tells you what environment the reviewer used, which can matter when behaviour differs between devices, and it shows that review takes place on real hardware.

Common questions