Binary rejections and metadata rejections: what each one means
App stores treat an app as two things that are reviewed together: the build that runs on the device, and the listing that describes it. A finding against one is not necessarily a finding against the other, and the distinction affects how a submission moves through review.
This guide explains the two categories, what falls into each and why the stores keep them separate.
What counts as the binary
The binary is the compiled app that a person installs. Findings against it concern what the app does: crashes, incomplete features, use of restricted technology, missing permission explanations, undisclosed behaviour or content inside the app. These findings relate to a specific build, identified by its version and build number.
What counts as metadata
Metadata is everything displayed in the listing: the name, subtitle, description, keywords, screenshots, preview videos, category, age rating, release notes, support and privacy links, and the review notes that explain the app to reviewers. On Google Play it also includes declarations in Play Console, such as the content rating and the Data Safety form. A metadata finding says that something in this material is inaccurate, misleading, inappropriate or missing.
Why the distinction exists
The two have different lifecycles. A build is fixed once it is submitted, while listing information can often be edited without producing a new build. The stores separate them so that a problem in a screenshot does not have to be treated like a flaw in the code, and so that review can focus on the right thing.
It also reflects how users meet an app. The listing is what they see before installing, and it is held to its own standards of accuracy, suitability and honesty. A perfectly working app can have a listing that overstates what it does, and the reverse is also possible.
Findings that straddle both
Some issues involve both. An age rating, for instance, is declared in the listing but judged against the content of the app. Features described in the release notes must exist in the build. Privacy information is declared in metadata but checked against what the code and its libraries do. These cross-checks are among the most common sources of findings, because an inconsistency between the two is itself the problem.
What the status labels reveal
Apple's status names often hint at the category, for example by indicating that the submission is rejected on metadata. Messages from Google usually say whether the action applies to a release, to the store listing or to the app as a whole. Reading that part of a message first tells you which side of the divide the reviewer is talking about.
Why metadata problems feel disproportionate
Because the listing can usually be edited without a new build, metadata findings are often described as minor. They are still real findings, and they sit in front of the app for every visitor. Reviewers take them seriously because the listing is where honesty about the product is judged, including accuracy of screenshots and descriptions.
Examples on each side
Typical binary findings include crashes, unfinished screens, missing permission explanations and use of restricted technology. Typical metadata findings include screenshots that do not show the app in use, keyword lists containing other brands, age ratings that do not match the content and descriptions that promise features the build does not contain.
Common questions
Yes. A listing problem can hold up approval even if the build itself is accepted.
Yes, and they are expected to describe the changes in the version.
It is a declaration made in Play Console about the app, which is checked against the app's content.
Review processes change often. This guide is a plain-language explanation written by AppReviewFix, not official guidance. Check Apple's App Store Review Guidelines and Google's Developer Program Policies for current details.