App Store Guideline 2.3.3 screenshots rejection: how to fix it
What App Store Guideline 2.3.3 says
Guideline 2.3.3 sits under Section 2.3, Accurate Metadata. It states that screenshots should show the app in use, not merely the title art, login page, or splash screen. Screenshots may include text and image overlays, for example to demonstrate an input method, and may show extended functionality where relevant.
The wider 2.3 rule is that all of your metadata, including screenshots, must accurately reflect the app's core experience. A reviewer compares the screenshots against the running app, so the screen inside the frame has to be the real shipping app, and any feature shown has to exist in the build under review. The official text lives on the App Store Review Guidelines page.
Why apps get rejected under 2.3.3
Common triggers:
- The screenshots show a login screen, a splash screen, or title art instead of the app in use.
- The screenshots are concept mockups or designs that do not match the actual interface.
- A feature shown in a screenshot is not in the submitted build, for example a screen that was cut or is still planned.
- Numbers, prices, or metrics in the screenshots are fabricated rather than real app content.
- An in-app purchase feature is shown without indicating it requires a purchase.
The thread is that the screenshots promise something the app does not deliver, which is what 2.3.3 and the broader accurate-metadata rule are written to prevent.
How to fix it
- Capture real screens. Take screenshots from the actual shipping build, showing the app being used rather than a splash or login screen.
- Remove anything unshipped. Cut screenshots of features that are not in the build under review, and add them back only once those features ship.
- Keep overlays honest. Marketing text, backgrounds, and device frames are fine, but the underlying screen and any stated numbers must be real.
- Mark in-app purchase content. If a screenshot shows a feature that needs a purchase, make that clear so the screenshot is not misleading.
- Match every device size. Make sure each required size shows the same real app, then reply in the Resolution Center, following the App Store Connect Help.
Remember that submitted is not approved. New screenshots go back through review, and Apple compares them against the running app.
How AppFlight helps
AppFlight builds your native iOS app and includes marketing autopilot that generates screenshots from the app itself, so the images start from the real interface rather than a separate mockup that can drift from the build. Because the screenshots come from the shipping app, they are more likely to satisfy the 2.3.3 requirement that they show the app in use. When Apple returns a 2.3.3 rejection, AppFlight reads the rejection reason, works on the metadata, and resubmits. AppFlight does not guarantee approval. The screenshots still have to match the build, and Apple reviews every app and every resubmission.
FAQ
What does Guideline 2.3.3 require for screenshots?
Screenshots should show the app in use, not merely the title art, login page, or splash screen, and they must accurately reflect the app. The screen inside the frame has to be the real shipping app, and any feature shown must actually exist in the build under review.
Can I use marketing text and device frames in screenshots?
Yes. Overlay text, colored or image backgrounds, and 3D device frames are allowed and common. What is not allowed is fictional UI, unshipped or removed features, mismatched in-app purchase prices, or fabricated metrics presented as real app content.
Do I need a new build to fix a 2.3.3 screenshot rejection?
Usually not. Screenshots are metadata in App Store Connect, so you can replace them and reply in the Resolution Center without uploading a new binary, unless the rejection also asks you to change the app itself.