# App Review Guideline 2.3.3 rejection: screenshots are metadata that drifts

> Rejected under 2.3.3 (Accurate Metadata) because a screenshot set does not show the app as it really looks on that device. Why uploads pass and review does not, and the order that fixes it.

- Canonical page: https://obelisk.club/blog/app-review-guideline-2-3-3-screenshots-rejection
- Author: Peter Zhang
- Published: 2026-10-25
- Tags: app-review, app-store, guideline-2-3-3, screenshots, rejection, indie

**Guideline 2.3.3 (Accurate Metadata)** says your screenshots must show the app in use. We were rejected under it twice. In one case the iPad Pro (2nd generation) set "still" did not reflect the app on that device; "still" meant the previous finding came back unchanged with our resubmission. In the other, the review ran on an iPad, yet the set that was named was the 6.7-inch iPhone group, which did not show the app actually being used.

This is from our own submissions. Here is why it survives until a human looks, and what fixed it.

## Why it gets through

- **Upload checks pixels, not content.** App Store Connect validates size and format. A picture with the right proportions that is not the real interface passes every machine check.
- **Screenshots are per-size groups, and each group stands alone.** The non-primary sizes are often not captured at all: they are reused from the main size, stretched, or put in a device frame. The size check passes; "accurate" does not.
- **You look at the main group.** Review looks at every group, whichever device the reviewer holds.
- **Builds and tests only prove the binary.** Nothing compares an uploaded image with what the current build shows on that device. The binary moves on and the screenshots keep describing an older app.

## What fixed it, in order

1. **Write down what "really in use" means.** The real running interface at that size. Captions are fine; a marketing collage, a launch screen or empty placeholder content is not.
2. **Generate each required size natively from the build you are submitting.** Do not scale a master image into another slot. Re-using an old version's pictures means submitting metadata you cannot reproduce.
3. **Open every group and check it.** For each size and language, find the frame in the picture on a simulator of that size running the current build. "The export finished" does not tell you each group is right.
4. **Keep a list from size to source,** because required sizes change. With the list, the next round is a regeneration, not archaeology.
5. **Then resubmit,** and say in the reply which sizes you regenerated. Resubmitting without regenerating collects the same finding again.

## One-minute check

Open the screenshot manager and ask three things for each size group: is the proportion native to that size, is the picture the app really running, and could I retake it today? Any group you cannot answer for is the weakest metadata you have, and review reads it group by group.

*These notes are from Obelisk Club's own submissions. Apple's wording and requirements change; check the current App Review Guidelines and your own message for the exact terms.*