Home › FAQ › App Store 2.3+4.3 playbook
APP STORE REVIEW

2.3 + 4.3: metadata manipulation & spam signals

Most teams treat 2.3/4.3 as “metadata copy issues”. In practice, Apple reacts to something more concrete: verifiable inconsistencies between what metadata promises and what a reviewer can reproduce inside the app. This playbook turns rejection into a diagnostic map: which signals trigger suspicion, what to fix first, and how to prove your remediation with an evidence pack.

Get remediation advice See 4.3 practical checklist

Translate “guidelines” into “signal inconsistency”

Reviewers do not guess whether you manipulate. They verify mismatches: metadata story, in-app reality, and the path you provide. When those don’t align, 2.3 and 4.3 become likely.

01 Title implies features you can’t verify

Keyword-heavy titles suggest capabilities that have no verifiable in-app entry, or rely on an external web flow for key actions.

02 Screenshots don’t match the real UI

Reviewers cannot find what screenshots claim, or visuals are overly “marketing” and diverge from actual interfaces.

03 Keyword stuffing shifts category semantics

Hot keywords pull your story into another category, but the app lacks corresponding content, triggering “misleading” and “coverage manipulation”.

04 High similarity across multi-app matrix

Multiple apps submitted within a short window share the same UI skeleton, flow, and asset style, increasing duplication/spam suspicion.

05 Review notes are not reproducible

Long explanations without credentials, clear steps, expected results, and screenshots are hard to verify and often fail.

06 Subscription disclosures don’t match in-app entry

Price, trial, cancellation, and paywall behaviors must align across metadata and in-app experience. Mismatch is a red flag.

Diagram: signals → actions

Use this as an internal map: decide whether you need metadata edits, in-app path redesign, or matrix governance changes.

App Store 2.3 + 4.3 signals and actions diagram
Recommended order: verification consistency first (metadata ↔ in-app path ↔ disclosure), differentiation governance second (multi-app boundaries, asset style, submission pacing). Reverse it and you usually do more rework.

Remediation: a four-step order (lowest cost → highest)

If you want a practical priority: make the app verifiable first, then make it differentiated. Many teams start with visual reskinning; reviewers still reject because the core story remains unverifiable.

  • Step 1 — Make metadata a verifiable promise: remove claims that can’t be reproduced in-app. Keep only features that can be verified within 3 minutes.
  • Step 2 — Turn screenshots into review navigation: screenshot captions should describe entry and outcome, not concepts. Let reviewers find the page fast.
  • Step 3 — Shorten the critical path: don’t hide core entry behind deep menus. Add a reviewer-friendly entry or guide page if needed.
  • Step 4 — Govern matrix and prove differentiation: for multi-app/multi-region matrices, define clear boundaries per app and provide a differentiation table.

Evidence pack: how to make reviewers trust your fix

Don’t debate. Provide a short verification script. A reliable structure is:

  • Guideline mapping: which parts relate to 2.3 and/or 4.3, and your interpretation.
  • Changes made: 3–6 concrete changes (metadata edits, screenshot replacements, in-app entry/path adjustments).
  • Reproduction path: steps from launch to core loop (ideally ≤ 8 steps), with test credentials.
  • Screenshot evidence: pair “metadata screenshot” with “in-app page screenshot” to show one-to-one alignment.

Submission pacing: avoid stacking similarity signals

If you run a matrix or update metadata frequently, pace your submissions. Get one version through and keep the pass record, then proceed. Batch submissions of highly similar apps increase the probability of stricter review.

  • Multi-app under one account: stagger submissions; avoid same-day batch submissions of similar apps.
  • Frequent metadata updates: change with a purpose; avoid changing title+screenshots+subscription+links all at once.
  • Stabilize first, optimize later: return to verifiable consistency before expanding keywords and conversion tactics.

FAQ

How do we distinguish 2.3 vs 4.3 (Spam)?+
2.3 is primarily about inaccurate or misleading metadata. 4.3 focuses on duplication and spam-like behavior. In reality, they often appear together when metadata promises cannot be verified in-app, pushing the app into a stricter trust and similarity check.
Why can changing only keywords/title still trigger rejection?+
Because Apple evaluates the whole story: title, subtitle, description, screenshots, in-app copy, subscription disclosures, and external landing pages. If they tell different stories, it looks like manipulation.
What’s the most effective remediation order?+
Consistency first, differentiation second. Align metadata with a verifiable in-app path, then reduce similarity across apps if you run a matrix.
How long should the review notes be?+
Length is not the point. Verification is. Use a four-part structure: guideline mapping, changes made, reproduction path, and screenshot evidence.
How do we lower 4.3 risk for multi-app matrices?+
Treat it as matrix governance: clear boundaries per app (feature and assets), stagger submissions, avoid batch submissions of highly similar apps, and provide a differentiation evidence table when needed.
App Store 2.3 rejection fixes App Store 4.3 spam rejection fixes App Store 5.1.1 privacy rejection fixes App Store rejection hub Back to FAQ