Common App Store and Google Play rejections, and what they actually mean

Store rejection messages are short, generic, and usually do not name the offending asset. Here is what the common ones actually mean when the cause is metadata or screenshots — which it often is.

"The dimensions of one or more screenshots are wrong"

Cause: at least one file's exact pixel size is not on Apple's accepted list for that display class — or files within one class disagree with each other.

Fix: resize to an exact target with a cover fit, as the last operation before writing the file. Full walkthrough in the dimensions post, including the one-line command that finds the offending file.

Screenshots do not show the app in use

Apple guideline 2.3.3 territory. Your screenshots have to show the app actually running.

Typical causes: a title card or marketing splash as the first screenshot, a panel that is all text with no UI, a concept image of what the app might look like, or a login screen as the only visible interface.

Fix: every panel should contain real UI from the shipped build. Art direction belongs around the device, not inside the screen.

Screenshots include content the app does not have

Cause: a feature in a screenshot that is not in the submitted build — often a feature that got cut late, or screenshots carried over from a build where it existed.

Fix: recapture against the build you are submitting. This is also why generated screenshots that redraw your UI are dangerous: a model that invents a plausible button has just created this rejection for you. See what to trust in AI generators.

Fabricated ratings, counts or reviews

Cause: a number inside a device screen that is not real — a star rating, a download count, a streak, revenue, testimonials.

Fix: remove it. Seed real data so the genuine number is good. This one is worth taking seriously because it can escalate beyond a rejection.

Another platform's device or branding

Cause: an Android device frame in an App Store listing, a Play badge in an iOS screenshot, or references to the other store in your description.

Fix: per-store assets. This is a real reason not to reuse the same exported files across both stores even when the design is identical.

Metadata: name, subtitle or keywords

Causes: exceeding character limits, competitor names in keywords, irrelevant keyword stuffing, or claims in the subtitle you cannot support.

Limits worth keeping to hand — iOS name 30, subtitle 30, promotional text 170, keywords 100, description 4000. Android name 30, short description 80, full description 4000.

"We were unable to review your app"

Cause: the reviewer could not get in. Almost always a demo account that does not work.

Fix: log in with the credentials yourself, on the build you are submitting, immediately before submitting. Add notes for anything non-obvious — hardware requirements, region locks, data that needs seeding. This is the single most common cause of a slow review and the easiest to prevent.

Privacy labels do not match behaviour

Cause: your nutrition labels declare less than the app and its SDKs actually collect.

Fix: audit what your third-party SDKs collect, not just your own code. Analytics and ad SDKs are the usual gap.

Google Play specifics

Feature graphic missing or wrong size. 1024 × 500 exactly, required to publish. Notes on the feature graphic.

Screenshot aspect ratio out of range. Play caps at 2:1, and a raw modern Android capture exceeds it. Details on the Play sizes page.

Misleading store listing. Play's equivalent of 2.3.3 — screenshots must represent the app.

Missing tablet screenshots. Not always a hard rejection, but Play will flag it and it affects how you are surfaced to tablet users.

Preventing the whole category

Nearly everything above is caught by a pass before submission rather than after:

1. Verify every file's exact dimensions, and that files within a class match.
2. Open every screenshot and confirm it shows real UI from the submitted build.
3. Check no number inside any device screen is invented.
4. Log in with the demo account on the actual build.
5. Re-read metadata against the character limits.

The full version is the release checklist.