Devoria
Guideline 2.3.3: Apple rejected your screenshots, redo them
By Mehdi Azizi
Published , 8 min
Guideline 2.3.3: more than half your screenshots must show the real app screen in use. What passes, what gets rejected, and the fix without a new build.
A "Guideline 2.3.3 - Performance - Accurate Metadata" rejection means Apple thinks your screenshots don't show the app actually being used. The rule comes with a number: for each device type, more than half of the screenshots must show the real app screen in use. The rejection is about your product page, not your binary: you swap the screenshots and resubmit the same build.
It happened to me on October 27, 2026 with Vigie, my ASO tracking app. My screenshots showed UI cards redrawn around a mascot, with no phone. Apple rejected them. This guide covers the message I got, what Apple means by "app in use," what passes and what doesn't, then the checklist I've used ever since. The rules quoted here come from Apple's official pages, reread on November 3, 2026.
Apple's message, word for word
The message starts with the guideline title, then names the targeted device size. For Vigie, the sentence carrying the rejection was this one:
The 6.7-inch iPhone screenshots do not show the actual app in use.
Other 2.3.3 rejections spell out what the reviewer expects. This one was posted on Apple's forums in October 2024 by a developer whose iPad slots showed an iPhone frame. Here's the part listing the requirements, word for word:
Some or all of the provided screenshots do not sufficiently show
the app in use. Screenshots should highlight the app's core concept
to help users understand the app's functionality and value.
- Marketing or promotional materials that do not reflect the UI
of the app are not appropriate for screenshots.
- The majority of the screenshots should highlight the app's main
features and functionality.
- Confirm that the app looks and behaves identically in all
languages and on all supported devices.
- Make sure that the screenshots show the app in use on the
correct device, unless they are included to demonstrate that
the app can be used on multiple Apple platforms. For example,
iPhone screenshots should be taken on iPhone, not on iPad.
In plain terms: a promotional visual that doesn't show the app's interface doesn't belong among your screenshots. Most of them must show the main features. And each screenshot shows the right device: an iPhone screenshot is taken on iPhone, not iPad, unless it's there to show the app works on several Apple platforms.
What Apple calls "app in use"
The text of guideline 2.3.3 is short: "Screenshots should show the app in use, and not merely the title art, login page, or splash screen." Your screenshots must show the app in use, not just the logo, the login screen or the launch screen. The same text allows text and images layered on top.
The App Review help page on 2.3.3 explains how it's judged. Apple evaluates the set for each device type, and only approves if more than half of the screenshots show the app in use. Each language is judged separately. The page also lists what to avoid:
- screenshots that only show a login page or a launch screen;
- an interface that doesn't match the real one, or misleading promotional artwork;
- decorations that overpower the app, or the hardware alone, with no interface behind it.
Put simply, "in use" means: the real interface of your build, with content, doing what people download the app for. A short headline above a real screen is still a screenshot in use.
How many screenshots must show the app
Apple gives two examples: with three screenshots, two must show the app. With four, three. The rest follows from the same rule, more than half.
| Screenshots submitted | Minimum in use | Marketing visuals allowed |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 8 | 5 | 3 |
| 10 | 6 | 4 |
The count is per device type and per language. A single screenshot per device is enough, if it shows the app in use. According to the screenshot specifications, Apple requires at least one screenshot for the medium-size iPhone with Dynamic Island, and accepts up to 10 per size. If your interface is the same across all sizes and languages, the highest required resolution is enough: App Store Connect scales it down for smaller sizes. Exact dimensions are in App Store screenshot sizes.
What passes, what doesn't
| Screenshot | Verdict | What decides it |
|---|---|---|
| Real app screen, short headline above | Passes | Added text is allowed by 2.3.3 |
| Real screen placed inside an iPhone | Passes | The real interface, on the right device |
| Logo, launch screen or login alone | Rejected | Named word for word in the rule |
| Marketing visual with no interface | Tolerated as a minority | Only if the majority shows the app |
| Redrawn UI cards, without the app | Rejected | My rejection on October 27, 2026 |
| Mocked-up screen that doesn't exist in the build | Rejected | Interface that doesn't match the real one |
| Empty phone or decor with no interface behind it | Rejected | Listed under what to avoid |
| iPhone screenshot in the iPad slots | Rejected | Wrong device, per the forum rejection |
| Image spanning two screenshots | Passes | Allowed, as long as the app stays visible |
| Status bar from another platform | Rejected, under 2.3.10 | Apple points to guideline 2.3.10 |
Apple doesn't require a phone frame. A full-screen screenshot of the app is enough. The frame has one advantage: it makes it obvious at first glance that the image is the app.
My case: Vigie rejected on October 27, 2026
For Vigie version 1.1, I'd followed a trend from screenshot studios: one continuous panorama, a mascot, and floating UI cards instead of a full phone. The cards were redrawn for the occasion, with fictional apps. It looked nice. It wasn't the app.
The reviewer wrote that the 6.7-inch iPhone screenshots didn't show the app in use. I didn't push back: he was right. I redid the whole set with one simple rule:
- Each panel shows an iPhone with a native simulator screenshot, placed pixel-perfect, with no edits to the interface.
- A zoomed-in card only appears in addition to the phone, never instead of it, and it's cropped from that same screenshot.
- The decor stays around the screen, never on top of it.
This rejection didn't require a new build. I replaced the screenshots and resubmitted the same version that evening. I later switched builds to fix a title inside the app, unrelated to the screenshots. Vigie 1.1 was on sale on October 29 with this set.
A redrawn card, even a faithful one, isn't the app. The reviewer wants to see the screen the user will actually hold.
Fixing it without a new build
- Read the whole message. It tells you which device size is targeted, sometimes which language. Every affected set has to change, not just the first one.
- Retake the screenshots from the submitted build. Simulator or device, with real content. More than half in use, for each device and each language.
- Replace the screenshots in App Store Connect. According to the help page on managing assets, you can do this when the app is in one of these statuses: Prepare for Submission, Invalid Binary, Rejected, Metadata Rejected or Developer Rejected.
- Resubmit, based on the status shown. For Metadata Rejected, the status table says: read the message, fix the metadata, then reply to the App Review message. If the submission shows Unresolved Issues, follow Apple's procedure: in Apps, View App Review Issues & Messages, then Resolve, Edit on the rejected item, Add for Review, and finally Resubmit to App Review.
- Don't touch the screenshots once you've submitted. According to the same status table, in Waiting for Review you can neither upload nor edit screenshots.
Each rejected item can only be edited once before resubmitting: check your new set before you click. Here's the reply I'd write to the reviewer:
Hello App Review team,
Thank you for your feedback regarding Guideline 2.3.3.
We replaced the [6.9-inch iPhone] screenshots in all localizations.
Each screenshot now shows the actual app interface, captured from
the submitted build: [main screen], [key feature], [result screen].
The build is unchanged.
Best regards,
[Your name]
The tone and format of a good reply are covered in replying to App Review.
The checklist before you submit your screenshots
- More than half the screenshots for each device type show the real screen, with content.
- The same rule holds in every language, not just English.
- No screenshot shows only the logo, launch screen or login.
- The interface shown exists in the submitted build, exactly as is.
- Headlines and decor keep the interface readable.
- iPhone screenshots are taken on iPhone, iPad ones on iPad.
- No trace of another platform, not even in the status bar.
- If your app has dark mode, one screenshot shows it: Apple's help page recommends it.
- Files are JPEG or PNG, with no transparency.
Apple also notes, on its product page guide, that the first screenshots can appear in search results. For me, a screenshot that clearly shows the app doing its job sells better than a slogan. The other product page rejection reasons are in why Apple rejects an app.
Screenshots that pass the first time
The App Store Screenshots Kit bundles my templates and the skill that builds your screenshots from your app's real screens, in the sizes Apple asks for. If your product page just got rejected, the Review Kit includes my pre-submission checklist, my fixed rejections and reply templates for the reviewer. The full process is on the app rejected by Apple page.
If you're preparing your first launch, take the free diagnostic: it puts the steps in order and sends you my Apple anti-rejection checklist.
Frequently asked questions
What does "Guideline 2.3.3 - Performance - Accurate Metadata" mean?
It's the rejection title for screenshots that don't show the app in use. Apple thinks too many screenshots are marketing visuals, launch screens or interfaces that aren't the app's. The message often names the device size involved.
Do you need a new build after a 2.3.3 rejection?
No. The rejection is about the App Store product page. You replace the screenshots in App Store Connect, then resubmit the same version by replying to the App Review message.
How many screenshots must show the app in use?
More than half, for each device type and in each language. With three screenshots, two must show the app. With four, three. A single screenshot is enough if it shows the app in use.
Can you put marketing text on App Store screenshots?
Yes. Guideline 2.3.3 allows text and images layered on top. They must not hide the interface, and most screenshots must still show the app in use.
Do you need an iPhone frame around your screenshots?
No, Apple doesn't require it: a full-screen app screenshot passes. The frame helps viewers understand the image is the app. It has to be the right device: never an iPhone frame on a screenshot meant for iPad.
Can you edit screenshots while the app is waiting for review?
No. In Waiting for Review status, App Store Connect won't let you upload or edit screenshots. To change them, remove the submission from review or wait for the decision.
