Ren Hollis

Guideline 2.3 rejection: metadata and screenshots, decoded

Short answer: your listing doesn't match your app — the description promises what the build doesn't do (2.3.1), or your screenshots show a login wall or title art instead of the app in use (2.3.3). These are among the fastest rejections to clear because the fix lives in App Store Connect, not in your code — as long as the listing was the only liar. If the feature genuinely doesn't exist, the listing edit has to wait for the feature or the claim has to go.

Apple treats the listing as a contract with the user. Audit every claim against what a first-launch user can reach in the submitted build, including the claims your screenshots make visually.

Got the actual message? Paste it into the free rejection decoder — it matches your rejection against documented store rules and returns the fix steps, the resubmission checklist, and a reply draft. Three free decodes, no account.

2.3.1 — Accurate Metadata

Your store listing promises something the app doesn't do — features, content, or outcomes that aren't in the binary the reviewer tested. Apple treats the listing as a contract: if it isn't in the app, it can't be in the metadata.

Severity: major · Decoder confidence for this class: A (see the honesty note below)

The fix

  1. Compare every claim in the name, subtitle, description, and previews against what a first-launch user can actually reach in the submitted build.
  2. Remove or rewrite any claim for features that are planned, server-flagged off, region-limited, or behind conditions the description doesn't state.
  3. If the feature exists but is hard to find, add step-by-step access instructions to the App Review notes instead of editing metadata.
  4. Check screenshots and previews too — they are metadata under this guideline.

Resubmission checklist

  • Every description claim verified reachable in the submitted build
  • No 'coming soon' or roadmap features presented as current
  • Screenshots/previews consistent with the description

Reply draft

Hello App Review Team,

Thank you for the feedback. We audited our App Store metadata against the submitted build and corrected the following: [LIST EACH CHANGE]. Every feature now described in the listing is reachable in the submitted version. [OR: The referenced feature is available in the app at [PATH] — steps added to the review notes.]

Thank you for your time.

[NAME]

What the decoder can diagnose here: Which listing elements Apple named, and whether the fix is metadata-side (edit the listing) or product-side (the feature is genuinely missing). What it cannot: Whether the feature exists but was hidden behind a flow the reviewer didn't find — if so, the fix is review notes with a path, not a metadata edit.

Rule text: “App Store metadata should accurately reflect the app's content and functionality.” — App Review Guidelines §2.3.1, retrieved 2026-10-23

2.3.3 — Screenshots Must Show the App in Use

Your App Store screenshots are marketing art, a login wall, or a splash screen instead of the app actually being used. Apple requires screenshots to show the app in use so users (and reviewers) can see what it does.

Severity: major · Decoder confidence for this class: A (see the honesty note below)

The fix

  1. Capture the actual app UI on the main screens a user spends time in — not the login screen, splash screen, or title art.
  2. Populate the screens with realistic content (a demo account state is fine) so the functionality is visible.
  3. Upload replacements for every affected device size in App Store Connect.
  4. Make sure the screenshots match the current version's UI — outdated UI triggers 2.3.1 as well.

Resubmission checklist

  • Screenshots show core app screens in use
  • No login/splash/title-art-only sets
  • All required device sizes updated

Reply draft

Hello App Review Team,

Thank you for the feedback. We have replaced the screenshots for [DEVICE SIZES] with captures of the app in use, showing [CORE SCREENS/FEATURES]. The new screenshots are uploaded in App Store Connect for this version.

Thank you for your time.

[NAME]

What the decoder can diagnose here: That the fix is a screenshot replacement, not an app change — this is one of the fastest rejections to clear. What it cannot: Which replacement frames Apple will consider sufficient — the rule of thumb is real UI with real content on the core screens.

Rule text: “Screenshots should show the app in use, and not merely the title art, login page, or splash screen.” — App Review Guidelines §2.3.3, retrieved 2026-10-23

Related guides

Sources

  • App Review Guidelines §2.3.1, retrieved 2026-10-23
  • App Review Guidelines §2.3.3, retrieved 2026-10-23

Last updated October 23, 2026. Rules change; the retrieval dates above say when this page was last checked against the store's published text.

Decode your rejection — free

The decoder covers 41 documented rejection patterns across the App Store and Google Play, grounded in the stores' own published rules. Three free decodes; the $29 Pre-Flight Founding pre-sale unlocks unlimited decoding plus a full pre-flight check credit when the checker ships.

Open the free decoder

The decoder classifies and guides from the message you paste. It cannot see your app or your binary, and it never promises an approval outcome — that decision is always the store's.