App Store Metadata Review: 5 Edit Tiers [2026]

Apple's App Store review of metadata changes is graded, not binary. The same submission flow handles edits that auto-approve in minutes and edits that go through 24-to-48-hour human review with required Notes for Review [1][4]. Knowing which tier your edit falls into changes when to submit, what to write in the notes, and whether you can ship today or have to wait. Apple doesn't publish a tier table; the framework below is practitioner-observed from review-time patterns. Where Apple's docs are explicit, citations point to primary sources.

The metadata-only update guide covers the field-by-field map of what counts as metadata. The cadence guide covers refresh triggers and the 4-week keyword stabilization window. This piece covers what Apple actually does to your submission once it lands in the review queue.

TL;DR:

• Apple supports parallel metadata submissions: "one app version per platform, plus one additional submission with items only" (in-app events, custom product pages, asset packs, Game Center components) [1]. The metadata-only side has its own review track separate from binary submissions.
• 5 edit tiers (practitioner-observed) from no-review to extended human review:
  1. No-review fields (promotional text [2], per-locale typo fixes in already-approved copy)
  2. Automated checks only (screenshot swaps that don't add feature claims, caption tweaks within existing claims)
  3. Light human review (subtitle changes, keyword field reshuffles, description copy edits)
  4. Full human review (description rewrites, category changes, age rating changes, screenshots showing new features)
  5. Extended review with required Notes (regulatory-adjacent changes: health, finance, privacy, gambling, user-generated content)
• The 4-week keyword stabilization window resets on any indexed-field change (title, subtitle, keyword field). Screenshot swaps and promotional text edits don't reset the window in the same way [3].
• "Substantive" on the App Store is defined by Apple, not by you. Apple's Review Guidelines require Notes for Review to describe changes with specificity: "generic descriptions will be rejected" [4]. A description rewrite without notes flagging the rewrite is a rejection vector.
• Expedited review for metadata is rarely granted. It applies to time-sensitive events with documented deadlines or critical-bug fixes, not routine metadata refreshes.

Table of Contents

• Why does Apple treat metadata changes differently than full app updates?
• Which metadata changes auto-approve vs go to human review?
• What resets your keyword stabilization window?
• What makes a metadata change "substantive" vs "cosmetic" on the App Store?
• When does expedited review apply to metadata-only submissions?
• How should you write Notes for Review for a metadata-only submission?
• Ship by tier, not by hunch

Why does Apple treat metadata changes differently than full app updates?

Metadata-only submissions sit on a parallel review track because they don't change the compiled binary users would download. Apple's own submission docs confirm developers can have "one app version per platform, plus one additional submission with items only" in flight at the same time [1]. The "items only" track handles things like in-app events, custom product pages, asset packs, and Game Center components, with metadata edits riding the same lightweight path.

The asymmetry is structural. A binary submission has to be tested for crashes, runtime privacy violations, permission misuse, and IAP behavior. A metadata-only submission has none of that surface, so Apple's review effort scales to what changed in the text fields, the screenshots, or the preview videos. A subtitle reshuffle gets a fraction of the review attention a description rewrite gets. A screenshot swap that doesn't add new feature claims gets less scrutiny than one that introduces a feature reviewers can't verify against the live binary.

Three structural consequences follow:

• Faster turnaround on light edits. Promotional text rolls out in 2 to 48 hours with no version submission at all [2]. Subtitle and keyword field reshuffles often clear in under 12 hours. Description rewrites still take 24 to 48 hours of human review.
• Different rejection vectors. Metadata submissions don't get rejected for crash bugs; they get rejected for keyword stuffing, screenshots showing unreleased features, regulatory claims without backing, or competitor name references. The bundling guide covers the specific rejection patterns at depth.
• Parallel-track timing matters. You can submit a metadata version while a binary version is in review, but they shouldn't land approval on the same day. The refresh cadence guide explains why same-day approvals contaminate conversion measurement.

Which metadata changes auto-approve vs go to human review?

The 5-tier matrix below is practitioner-observed, not Apple-documented. Apple's docs describe the review process as a single workflow without publishing edit-by-edit timing or treatment. The tiers below come from indie developer and ASO consultant observation of review queue patterns. Treat them as a working framework, not a guarantee.

A few patterns the tier system reveals:

• Tier-shifting your submission by sequencing matters. A bundled submission containing a tier-1 edit (promotional text), a tier-3 edit (subtitle), and a tier-5 edit (regulatory disclosure) reviews at the highest tier in the bundle. The whole submission waits for the slowest field. If the regulatory disclosure has a deadline, isolate it; bundle the other edits separately so they don't get held up.
• Same-content-class edits travel together. Editing two text fields in the same submission usually keeps the review at the tier of the slower one. Editing four text fields doesn't compound; the reviewer evaluates the listing as a whole.
• Reviewer eyeballs sweep the rest of the listing. A tier-3 edit can surface a reviewer-flag on an unrelated tier-5 issue (a long-standing health claim, an accessibility line). If your listing has any latent compliance debt, edit it knowing the reviewer may notice.

The honest caveat: Apple can shift the timing of any tier at any time. Holiday seasons, OS release windows, and developer-event weeks all compress or extend queues. The tier numbers are a planning heuristic, not a guarantee.

What resets your keyword stabilization window?

Apple's search algorithm needs roughly four weeks after an indexed-field change to stabilize keyword rankings, per Apptweak's own benchmark guidance [3]. Not every metadata edit triggers the reset. Indexed fields (title, subtitle, keyword field, and as of June 2025 some screenshot caption text) start the four-week clock. Non-indexed fields (description, promotional text) don't restart the keyword stabilization window in the same way. The indexed fields map covers which iOS and Google Play fields are search-indexed vs conversion-only.

The split, with the honest caveat that practitioner consensus is stronger than Apple's documentation here:

Resets the 4-week window:

• App name / title change
• Subtitle change
• Keyword field edit (even a single comma reshuffle)
• New screenshots with new caption text (since the June 2025 algorithm update treating caption OCR as a signal)
• Category change

Does NOT reset the window (per practitioner observation):

• Promotional text edit [2]
• Description rewrite without title/subtitle/keyword change
• Screenshot swap where new screenshots have identical caption text to old
• App preview video swap without new claims
• In-app event metadata edits (parallel review track)

The implication for your release cadence: if you're running 2-4 metadata refreshes per year per the refresh cadence guide, each refresh that touches title / subtitle / keyword field restarts the clock. Apple recommends measuring keyword performance only after the window closes [3]. Bundling all indexed-field changes into a single submission means you wait one stabilization cycle, not three.

The wrong move: editing title in one submission, then subtitle two weeks later, then keyword field two weeks after that. Three stabilization windows running back-to-back means roughly 3 months of unstable measurement and a search algorithm that never settles. The right move: queue all three changes, ship in one submission, wait four weeks, measure. The title, subtitle, and keyword field guide covers what to put in each indexed field. The free ASO audit tool helps surface which fields are due for change so you can bundle.

What makes a metadata change "substantive" vs "cosmetic" on the App Store?

Apple defines "substantive" indirectly through the Notes for Review requirement: "All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected)" [4]. A change is substantive in Apple's review framework if it changes what the listing claims the app does. A change is cosmetic if it polishes wording or design without changing the claim.

This maps roughly onto Google's Search Quality Rater Guidelines distinction (cosmetic edits without content delta produce no ranking benefit), but with App Store-specific mechanics layered on top:

Substantive (Apple's review treatment escalates):

• Adding a new capability claim to subtitle, description, or screenshot caption
• Removing a previously-claimed capability (Apple checks against current binary)
• Changing the target audience description in age rating or category
• Updating health, finance, or privacy claims (always tier 5, see above)
• Adding a new platform mention (Apple Watch, iPad, Vision Pro) in copy without supporting binary

Cosmetic (review treatment stays low-tier):

• Tightening sentence rhythm without changing claims
• Swapping synonyms in non-indexed text
• Fixing typos in already-approved copy
• Re-ordering bullet points in the description
• Adjusting line breaks or formatting

The wedge most ASO writers miss: substantive vs cosmetic on the App Store is about CLAIMS, not character count. A 1,000-character description rewrite that keeps every claim intact is cosmetic. A 50-character subtitle change that adds a new capability claim is substantive. Apple cares about what the listing tells users the app does, not how many keystrokes you spent rewriting it.

The practical rule: if your edit changes what the listing CLAIMS, write specific Notes for Review describing the claim change. If your edit polishes wording without changing claims, the standard "metadata refresh" note is enough. Get this wrong and you trigger a review escalation or a metadata rejection.

When does expedited review apply to metadata-only submissions?

Expedited review applies to metadata-only submissions only when the change is tied to a documented time-sensitive event or a critical user-facing issue. Routine metadata refreshes, A/B test launches, seasonal swaps, and "we want to ship today" requests don't qualify. Misuse of the expedited request system can lead to future requests being denied.

The criteria Apple typically honors for metadata-only expedited requests:

• Time-sensitive event with documented deadline. A Black Friday sale, a tied product launch (movie release, sports event, conference), an OS release that requires updated copy.
• Critical compliance fix. A regulatory disclosure that must update by a deadline. A removed claim that's actively misleading users.
• Critical brand or PR issue. A press hit that requires updated promotional text. A trademark dispute resolved that requires a copy change.

Criteria Apple typically rejects:

• Routine subtitle or keyword field updates
• "We want to test this faster" requests
• A/B test treatment launches that aren't tied to an external event
• Promotional text changes (these don't need expedited; they update in 2-48 hours without submission [2])
• General "make this faster" requests without a specific external deadline

The practical advice: pre-plan metadata changes around your existing release cadence so you don't need expedited review. Bundle changes into a single submission well before any external deadline. Reserve the expedited request for genuine emergencies; using it for routine work burns the option for when you really need it.

If your event is an actual launch tied to a date, document it in the expedited request: "Black Friday sale launches November 28; promotional text and seasonal screenshots need to be live by November 26." The specificity matters; Apple grants expedited based on the documented deadline, not the urgency you feel.

How should you write Notes for Review for a metadata-only submission?

Notes for Review for metadata submissions should describe what changed, why it changed, and what reviewers need to know to evaluate the new claims. Apple's guidelines are explicit that "generic descriptions will be rejected" [4]. A note that says "metadata refresh" or "minor copy improvements" is a metadata-rejection vector for any tier-3-or-higher edit.

A working template for metadata-only Notes for Review:

Submission type: Metadata-only (no binary change; submitting against build [X.Y.Z]).

Changes in this submission:
- Subtitle: [old] → [new]. Reason: [specific reason]
- Description: [paragraph 2 rewrite, no new claims / first paragraph rewrite + 1 new feature claim about offline mode]
- Screenshots: [frames 1 and 3 swapped to reflect new UI shipped in version X.Y.Z]
- Keyword field: [3 keywords removed, 4 added, list them]
- [Other field changes]

If feature claims changed:
- [Feature claim 1]: Verify in build by [specific path, e.g., "Settings > Premium > Offline mode toggle"]
- [Feature claim 2]: [Verification path]

Compliance notes if applicable:
- [Regulatory disclosure update, with citation to source]
- [Health/finance/privacy change, with documentation reference]

What makes the difference between a fast-cleared note and a rejected one:

• Specificity about what changed. "Subtitle changed from X to Y" beats "subtitle updated."
• Verification paths for new claims. If a new screenshot caption says "offline mode," tell the reviewer where to find offline mode in the live build.
• Calling out compliance changes explicitly. Regulatory or age-rating-adjacent updates need their own line.
• Avoiding marketing language in the note itself. "We improved our value proposition" is generic and rejection-prone. "Replaced subtitle 'Save time' with 'Plan trips in 5 minutes' to better describe the trip-planning feature shipped in v2.1" is specific and clears review.

The note isn't customer-facing copy; it's a reviewer's working document. Write it like you're writing a PR description for the reviewer to verify your changes against the binary.

For the broader workflow of getting metadata-only submissions accepted, the bundling and rejection patterns guide covers what gets rejected at each tier. For checking that your description first paragraph survives the visible above-fold surface before you submit, the first paragraph hook analyzer scores your hook against 5 verified opening patterns.

Ship by tier, not by hunch

Apple's metadata review is graded, not binary. Knowing which of the 5 tiers your edit falls into lets you predict timing, decide what to bundle, and write Notes for Review that actually clear human review. The tier framework is practitioner-observed (Apple doesn't publish it), but the underlying mechanics that drive it are documented: parallel submission tracks [1], promotional text exception [2], generic-notes rejection [4], 4-week stabilization on indexed fields [3].

Plan your metadata refresh cycle around the highest tier in any bundle. Reserve expedited review for documented deadlines. Write Notes for Review with reviewer-verifiable specificity for any tier-3-or-higher edit. The combination of those three habits is what separates teams that ship metadata refreshes cleanly from teams that hit avoidable rejections.

When you've locked your metadata changes and want screenshots that match the new claims, Try AppScreenshotStudio today for free and submit the bundle in one metadata version.