Replace screenshots that do not match the reviewed iOS experience. Capture the current build, use the correct device family, remove unsupported claims, and check every localization before resubmitting.
The short version
- Replace screenshots that do not match the reviewed iOS experience.
- Find the exact mismatch: obsolete UI, wrong platform frame, inaccessible feature, misleading annotation, price difference, or incorrect device slot.
- Open Apple’s attachment and identify the specific asset.
- Do not promise approval; give App Review a testable path.
Identify what the screenshot claims
Treat Apple’s screenshot or note as a visual diff. Identify the unsupported claim: a missing feature, wrong navigation, obsolete design, wrong device frame, unrepresentative state, or content that cannot be reached in the reviewed version.
Launch the selected build on each required device family, set the intended localisation, and reproduce a user-reachable state. Capture the actual interface before adding surrounding typography or a background. Preserve important controls and disclosures.
Recapture a truthful device sequence
Review the set as a sequence. The first images should not imply that a paid, logged-in, seeded, regional, or hardware-dependent state is universally available. Label context where the image would otherwise overstate access.
- Open Apple’s attachment and identify the specific asset.
- Reproduce the screen in the submitted build and review account.
- Capture current iOS UI at the proper device size.
- Check overlays and captions against reachable behavior.
- Repeat the audit for every localization and device family.
Keep a capture manifest with build, device class, locale, account state, source image, and edited output. That makes stale exports and cross-localisation mix-ups visible before upload.
Choose new assets or a new build
Replace assets when the binary already supports the depicted experience. Submit a new build when the honest fix is to add the missing feature or change the in-app UI. Removing an unsupported claim is not the same as implementing it.
| Situation | Next action | New build? |
|---|---|---|
| UI changed; screenshot is old | Replace screenshot metadata | Usually no |
| Screenshot shows an unshipped feature | Remove it or ship the feature | Depends |
| Android chrome or non-iOS frame appears | Replace with accurate iOS presentation | No |
| Feature exists but review account cannot reach it | Fix access and explain the path | Depends |
| Bundled in-app gallery is wrong | Correct bundled asset | Yes |
Choose new assets when the reviewed build already supports the honest depiction; choose a new build when only a product change can make the claim true.
Use Apple’s evidence as the diff
Compare the attached screenshot with the current reviewed build. Mark each difference in navigation, labels, colors, data, controls, pricing, and platform chrome. The problem may be one visible element rather than the whole set.
Use the same account state the reviewer receives. A premium screenshot is inaccurate when the review account cannot unlock the feature.
Recapture from the reviewed version
Use the current iOS build and an appropriate simulator or device capture workflow. Keep the content readable and truthful. Device frames and marketing text must not imply another platform or a capability the app lacks.
Annotations can explain a real screen. They should not invent interface, outcomes, rankings, prices, or content.
Check slots and localizations
A corrected base-language screenshot does not repair old assets in other localizations. Inspect every submitted device display and language. Confirm captions, currencies, subscription terms, and interface language all belong together.
Keep screenshot strategy separate from compliance. Conversion polish comes after every asset accurately represents the build.
Choose whether a build is necessary
Screenshots are App Store Connect metadata, so replacing them usually does not require a binary. A build is needed when you change the app to make the advertised experience true, or when the wrong asset is bundled inside the app.
Reply with the asset set changed and confirm that the new captures come from the submitted iOS version.
If the reviewer note crosses failure classes, use the App Store rejection map to separate the screenshots mismatch rejection symptom from unrelated issues.
Audit each image as a claim
For every screenshot, write the feature shown, the entry path, required account state, payment state, locale, device family, and build. If you cannot reach the image from the submitted version under the stated conditions, the asset is not ready.
Designed frames, backgrounds, and captions should not conceal or materially replace the app experience. Keep the core interface legible and make context explicit when the state is conditional.
Recapture without stale state
Start from the selected release build, not a design file or future branch. Reset the device, locale, content, subscription, and permission state intentionally. Capture source images again rather than compositing new chrome around an obsolete screen.
Review ordering after export. A sequence can mislead even when each frame is individually real, for example by presenting a paid result before any indication that purchase or login is required.
Check overlays after export at the actual uploaded dimensions. Captions must not cover controls or disclosures that are necessary to understand the state. Keep status bars, system prompts, and device-specific navigation internally consistent so the composition does not imply an impossible screen.
Open the uploaded preview rather than trusting the local export. Confirm crop, scale, sequence, caption legibility, and device assignment after App Store Connect processing; the final slot is the asset Apple evaluates.
Verify device sets and localisations
Open every submitted slot and compare language, orientation, interface, and visible feature state. Do not reuse a phone capture as if it were a native tablet experience. Check that text baked into artwork matches the localisation selected in App Store Connect.
Replace only the affected set when the build already supports it, then tell Apple which device sets and locales changed. If the underlying UI must change, submit the new binary and recapture from that build.
Keep the source capture and final exported asset together. Before upload, compare dimensions, orientation, status-bar treatment, device frame, and visible text against the slot you selected in App Store Connect. Compression and design tooling can reintroduce an old screen after the product team approved the capture, so inspect the actual uploaded preview rather than trusting the local filename.
Verify against Apple before resubmitting
Rules and App Store Connect interfaces can change. Reopen the Apple pages that support this decision before you act: App Review Guidelines, 2.3 Accurate Metadata, Reply to App Review messages. These are the primary policy and workflow sources used for this guide, opened on 4 August 2026.
FAQ about App Store screenshots mismatch rejection
Can I use designed marketing screenshots?
Yes, provided they accurately represent the app and do not mislead users about interface or functionality.
Do I need a new build to replace App Store screenshots?
Usually no. Screenshots are metadata. Rebuilding is necessary only when app behavior or bundled assets change.
Can a screenshot show a paid feature?
It can, but the claim and price must be accurate, and App Review needs a working way to reach the relevant experience.
Should I change every screenshot after one rejection?
Audit every asset, but replace only what is inaccurate or inconsistent. Avoid unnecessary new mismatches.
Conclusion
Recapture the reachable experience from the selected build, verify every device set and locale, and upload a new binary only when the truthful interface must change.
Sources and references
- App Review Guidelines, 2.3 Accurate Metadata (accessed 2026-08-04)
- Reply to App Review messages (accessed 2026-08-04)