You uploaded a clean build, the binary passed processing, and the rejection email still arrives — citing Guideline 2.3.3 (screenshots showing the app in use), 2.3 (Accurate Metadata), or 2.3.1 (no time-bound or promotional claims) instead of anything about the actual app. The reviewer’s note pinpoints a specific surface: a screenshot showing a feature you don’t ship, a keyword field stuffed with competitor names, a description that overpromises, or a category that doesn’t match what the app does. None of these require an engineering change — they are content fixes. But each surface has its own rules, and most teams misread which surface is being flagged.
The fastest path: identify the exact surface (screenshots vs description vs keywords vs category), apply the surface-specific fix, and resubmit metadata-only — no re-archive, your existing binary is reused.
Which bucket are you in
Map the reviewer’s wording to the surface before you touch anything. The guideline number tells you which rule was broken.
| Reviewer phrase (paraphrased) | Guideline | Surface to fix |
|---|---|---|
| ”screenshots include content not in your app” | 2.3.3 | Re-capture screenshots from the real build |
| ”app description includes misleading content” | 2.3 | Rewrite description |
| ”keyword metadata contains irrelevant or trademarked terms” | 2.3 | Clean keyword field |
| ”app’s category does not accurately reflect” | 2.3 | Fix primary/secondary category |
| ”promotional text references time-limited offers” | 2.3.1 | Strip campaign/date language |
| ”localized metadata is not consistent” | 2.3.7 | Fix the flagged locale |
Treat each surface independently. Do not rewrite copy when the issue was screenshots.
Common causes
Ordered by hit rate. Roughly half of all metadata rejections are #1.
1. Screenshots show features absent from the build
A previous version had an “AI Assistant” tab. You shipped a version without it but kept the marketing screenshot showing it. The reviewer downloads the binary, doesn’t see the tab, and rejects under 2.3.3.
How to spot it: For each screenshot in your App Store Connect listing, identify the screen it shows. Open the build and try to reach that screen. If you can’t, the screenshot is stale.
2. Heavily mocked screenshots with claims the build doesn’t make
You shipped marketing-style screenshots — gradient backgrounds, oversized device frames, and slogans like “3x faster than ChatGPT” layered on top. Apple is lenient on stylistic framing but rejects when overlaid text makes a claim the app cannot demonstrate, or when the screenshot references a competing platform.
How to spot it: List every text overlay on every screenshot. For each, ask: can a user verify this claim by using the app for 5 minutes? If not, it is a 2.3.3 candidate. Also flag any overlay containing pricing (“Free”, “50% off”), a competitor name, or another platform’s name — Apple disallows those on screenshots regardless of accuracy.
3. Keyword field stuffed with competitor names or repeated tokens
The 100-character keyword field contains “notion,evernote,obsidian,roam,logseq,note,notes,notes app,notes app pro”. Apple flags this as both a metadata violation (trademarked competitor names) and low-quality repetition. Apple may reject the update or silently clear the entire keyword field for a trademark violation — as of June 2026 the enforcement is automated and unforgiving on brand terms.
How to spot it: App Store Connect → App Information → Keywords. Search the field for any third-party brand you don’t own. Count repeated stems (note, notes, notes app are the same root).
4. Description front-loads keywords with no context
Your description opens with “AI productivity assistant for Notion users, Slack users, Gmail users, Google Calendar users, Apple Calendar users…” — a list of integration claims with no narrative. The reviewer flags it as keyword stuffing under 2.3.
How to spot it: Read the first 170 characters (the part visible without tapping “more”). If it reads like an SEO meta tag rather than a coherent sentence describing the app, it is overweighted.
5. Primary category doesn’t match what users do in the app
You picked “Lifestyle” because it has more downloads, but your app is clearly a productivity tool. Or you picked “Productivity” for a game. The reviewer rejects under 2.3 (Accurate Metadata).
How to spot it: Open the app and write a one-sentence description of the user’s most common action. Match that against Apple’s category definitions. If the gap is more than one category away, your pick is wrong.
6. Promo text or subtitle makes time-bound or promotional claims
“New: AI summarization, 50% off this week” — promotional text is the only field you can edit without review, so teams stuff it with campaigns. Apple rejects time-limited offers and dated claims under 2.3.1. The same applies to a subtitle that still says “New: AI summarization for iOS 17” written 18 months ago.
How to spot it: Search subtitle, promotional text, and description for new, just launched, coming soon, beta, latest, % off, limited time, free for the first, 2024, 2025. Move any active campaign into an in-app banner or push notification; keep store metadata evergreen.
7. Localized metadata diverges from base language
See App Store product page localization confusion — covered separately under 2.3.7.
Information to collect
- The full reviewer message including the exact guideline number.
- A current dev-build set of canonical screenshots, one per advertised feature.
- The current keyword field and a list of every brand name in it.
- Description text split into the visible-on-first-tap section (~170 chars) and the rest.
- Promotional text and subtitle current values.
- A decision: metadata-only fix (fast) vs a new binary (slower). Metadata-only reuses your existing build — no re-archive.
Before editing, screenshot every current store field. App Store Connect does not keep a history of overwritten metadata.
Shortest path to fix
Step 1: Identify which surface was flagged
Re-read the rejection and match it against the table above. Don’t waste time rewriting copy when the issue was screenshots, and don’t re-shoot screenshots when the issue was a keyword.
Step 2: Re-capture screenshots from the actual build
Important 2026 change: App Store Connect now requires only one screenshot set per device family, at the largest size, and scales it down to every smaller device automatically. As of June 2026 you need:
- iPhone: 6.9” display,
1320 x 2868px portrait (iPhone 17 Pro Max / 16 Pro Max). A 6.5” set at1284 x 2778is still accepted as a fallback. The old 5.5” / 4.7” requirements are gone for new submissions. - iPad (only if your app runs on iPad): 13” display,
2064 x 2752px portrait. Apple will not accept an iPad listing that contains only iPhone screenshots.
Run the build on each required simulator and capture the canonical screens:
xcrun simctl io booted screenshot ~/Desktop/screen-6.9.pngFor automation across the current required device classes and locales:
fastlane snapshot --devices "iPhone 16 Pro Max,iPad Pro (13-inch) (M4)"Verify the device names against your installed simulators first — they must match xcrun simctl list devices exactly, and the names shift with each Xcode release. Replace every stale screenshot in App Store Connect with the freshly captured ones, and keep marketing styling minimal: text overlays must match in-app reality and must not include pricing, competitor names, or other platforms.
Step 3: Clean the keyword field
Rewrite the 100-character keyword field with these rules:
- Comma-separated, no spaces after commas (
one,two,three, notone, two, three— spaces waste characters). - No third-party brand names you don’t own (automatic rejection or silent field-clearing as of June 2026).
- No repeated stems — pick one of
note/notes/notes app; Apple already pluralizes and combines. - No words already in the app name or subtitle (those 30+30 characters are indexed automatically).
- Locale-specific — a separate keyword field per locale.
Example clean field: gpt,llm,prompt,writing,summary,translate,voice,markdown,scan,ocr,docs
Step 4: Rewrite the description
Open with a sentence that says what the app does in plain language. Apple’s first-screen reveal is roughly the first 170 characters; everything important goes there.
Acme Studio turns any photo into a polished portrait using on-device AI.
No subscription required for basic edits; Pro unlocks batch and 4K export.
Features:
- One-tap enhance: lighting, skin, sharpness
- Background removal and replacementRemove these bad signs: keyword lists, exclamation marks, all-caps phrases, and claims you can’t prove in-app within five minutes.
Step 5: Pick the right category
Apple’s category list is short. Open the app and decide:
- What does the user do most? That is the primary category.
- What is a closely related secondary? Optional.
Set it under App Store Connect → App Information → Category, then save.
Step 6: Resubmit (metadata-only if the binary is unchanged)
In App Store Connect, open the app’s submission, attach the rejected version, and tap Add for Review → Submit for Review. For a metadata-only fix you reuse the existing build — no re-archive and no new upload. If the reviewer asked a question, also reply in Resolution Center → Reply to App Review describing exactly what you changed.
How to confirm it’s fixed
- Every screenshot in the listing corresponds to a screen reachable in the current build.
- No screenshot overlay contains pricing, a competitor name, or another platform’s name.
- The keyword field has zero competitor names and zero repeated stems.
- The description’s first 170 characters describe what the app does without keyword stuffing.
- The primary category matches the user’s most common action in the app.
- The submission moves from Metadata Rejected to Waiting for Review, then In Review — usually within 1-2 hours for a metadata-only resubmission.
If it still fails
- Reply in Resolution Center with a screen-by-screen mapping: “screenshot 1 → app’s home screen, reachable by…”.
- If a specific claim was flagged, prove it in-app: record a 30-second screen recording and attach it via Attach File in your reply.
- Ask for clarification when the rejection is vague (“misleading” without specifics). Apple usually responds in Resolution Center with the exact surface.
- Escalate via Contact App Review if a stylistic screenshot is rejected as “inaccurate” when the underlying feature actually exists.
Prevention
- Maintain a
metadata/folder in your repo with one file per surface (screenshots, description, keywords, category) per locale, version-controlled. - Add a release-checklist item: re-capture screenshots from the current build at
1320 x 2868(and2064 x 2752if you ship iPad). - Keep the keyword field clean — within the 100-character limit, relevance beats volume, and no brand names.
- Keep store metadata evergreen; push time-bound campaigns to in-app banners, not promotional text (2.3.1).
- Run
fastlane deliverto sync metadata from your repo to App Store Connect, so the listing matches the build that shipped.
FAQ
Do I need to upload a new build for a metadata rejection? No. A metadata rejection lets you edit metadata and reuse the existing binary. Re-archive only if the reviewer flagged behavior in the app itself, not the store listing.
What’s the difference between 2.3 and 2.3.3? 2.3 is “Accurate Metadata” broadly (description, keywords, category). 2.3.3 specifically covers screenshots and app previews — they must show the app in actual use. 2.3.1 covers promotional and time-limited claims. The number in your rejection tells you which surface to fix.
How many screenshot sizes do I actually need in 2026?
One per device family at the largest size. iPhone: 6.9” at 1320 x 2868. iPad (if supported): 13” at 2064 x 2752. Apple scales these down to smaller devices automatically, so the old multi-size matrix is no longer required.
Why did Apple clear my whole keyword field? A trademarked competitor name triggers it. As of June 2026 Apple’s automated check can wipe the entire 100-character field rather than just the offending term. Remove all brand names you don’t own and re-enter clean keywords.
Can I keep a “New” badge or a launch-week discount in my promotional text? No — time-bound and promotional claims violate 2.3.1. Promotional text should describe evergreen value. Run the campaign through an in-app banner or push notification instead.
How long does a metadata-only resubmission take? The status usually moves to Waiting for Review within 1-2 hours, with the actual review typically completing within a day. It does not restart the full multi-day binary review queue.