Guideline 2.3 Accurate Metadata: where ASO tricks turn into App Review rejections

Captions and framing are allowed — the rule is that the app's real interface is what the screenshot is about. A typical rejection reads: "We noticed that your screenshots do not sufficiently reflect your app in use." The usual causes:

• The first screenshot is a poster. A headline and an illustration, with no interface. Lead with a real screen and put the headline above it.
• The wrong device. Screenshots in a frame that doesn't match the size class they were uploaded for.
• Features that aren't in the build. If the screenshot shows it, the reviewer will look for it.
• Previews that aren't screen recordings. 2.3.4 says previews "may only use video screen captures of the app itself". Narration and text overlays are fine.

This is the sub-point where common ASO advice collides with App Review. Several widely repeated tactics are exactly what the guideline names:

Apple also reserves the right to change things for you: it "may modify inappropriate keywords at any time". For what top apps do inside these limits, see the listing snapshots for calorie trackers and habit trackers.

2.3.10 tells you not to include "names, icons, or imagery of other mobile platforms or alternative app marketplaces in your app or metadata". It's an easy one to trip in a cross-platform app, because the offending content is often inside the app rather than the listing.

A real example: "Revise the app's home page to remove Google Play references." When the reference is inside the app, the fix needs a new build — the one case where a 2.3 rejection isn't metadata-only.

• Flag what's paid. 2.3.2 asks that your description, screenshots and previews "clearly indicate whether any featured items, levels, subscriptions, etc. require additional purchases". If screenshot three shows a premium feature, say so in the caption or description.
• Describe new features in review notes. 2.3.1 requires new features and changes to be "described with specificity in the Notes for Review section", and warns that "generic descriptions will be rejected".
• No dormant features. A feature kept out of the reviewer's sight and switched on after approval is what 2.3.1 prohibits. Egregious or repeated cases are grounds for removal from the Developer Program.
• Don't promise what isn't there. Marketing a capability the app doesn't have, or a false price, on or off the App Store, is grounds for removal.

1. 01

   Read which field is named

   The message usually names the element — screenshots for a device size, the app name, the description.

2. 02

   Edit it in App Store Connect

   Fix every locale, not only the one quoted — the same problem in another localization can be flagged on the next submission.

3. 03

   Reply, don't re-upload

   Apple's help says: "If your app was rejected for a metadata issue, you can resubmit the same build after resolving the issue."

4. 04

   Check the app for the same problem

   If the offending text or image also appears inside the app, a metadata edit won't be enough — ship a new build.

Hello App Review team,

Thank you for the feedback on Guideline 2.3.[sub-point].

Metadata changes (no new build):
- Replaced the first two 6.9-inch screenshots; both now show the app's
  [screen name] in use.
- Removed "[word]" from the app name and subtitle in all localizations.
- Removed the reference to [other platform] from the description.

The binary is unchanged. Please let us know if anything else needs attention.

Thank you,
[Name]