Audit the images people can see now

Open each published image beside the corresponding screen in the version users can currently install. Review every relevant listing, language and device set rather than assuming one approved image covers them all. For each image, record what the screenshot depicts, what its caption claims, and what a user actually encounters. Check the whole composition: a truthful app capture can still have an outdated headline above it.

Mark an image replace if its central demonstration is wrong, revise if the same message works but the pictured UI or wording needs refreshing, or keep if both remain accurate. This is an editorial triage, not a rule that every changed pixel has equal urgency. Apple’s guidance says screenshots should show the actual app in use and should not misrepresent its interface; use that standard when judging whether a visible cosmetic difference is acceptable to leave in place.

  • Visible UI: Are the controls, labels, colors and screen state still recognizable in the current app?
  • Demonstrated journey: Could a new user still follow the pictured steps, or does the image teach a route that no longer exists?
  • Promise and caption: Does the feature still work as the image suggests, and does every line of overlay text remain true?

Separate an obsolete workflow from a cosmetic change

Consider a hypothetical budgeting app. Its redesign replaces one-tap transaction entry with an amount screen followed by category selection. It also changes the color of a settings header, but leaves its spending chart unchanged. Here is the resulting screen-by-screen decision—not a blanket request for an entirely new set.

The entry image is the urgent fix: its old controls and “Log a purchase in one tap” claim would set the wrong expectation. The chart can stay because neither the chart screen nor its claim changed. The settings image still explains the right feature, but its visible header no longer matches; recapture that screen when preparing the revised set. If the redesign had only recolored a part of the app that appears in none of the published images, those images would need no replacement on that account.

Hypothetical audit of a budgeting app’s published images
Published imageCurrent appDecisionReason
Quick-add transaction; “Log a purchase in one tap”Amount, then category selectionReplaceBoth the steps and caption are obsolete.
Spending chart; “See spending by category”Chart and category view unchangedKeepThe pictured feature and claim remain accurate.
Settings screen with old header colorSame settings, new header colorReviseRecapture the UI; the feature message can stay.

Turn the audit into a focused replacement brief

A useful brief names the exact files to make and the images not to remake. For the hypothetical app, give whoever prepares the artwork access to captures from the current app and specify the intended store listing, language, device slot and image position for each change. If you use Minimalist Screens to prepare revised artwork, treat the resulting images as drafts to check against this brief—not as a store update.

  • New capture: show the current amount-and-category entry flow in place of the quick-add image. Replace “Log a purchase in one tap” with “Add a transaction and choose a category,” provided that wording matches the released flow.
  • Refreshed capture: show the settings screen with its current header color. Keep its existing caption only after checking that the pictured setting still works as described.
  • Retained image: keep the spending-chart artwork and “See spending by category” caption if the final audit confirms that both still match the released app.
  • Handoff details: identify which published file each new image replaces, plus the listing, language, device variant and reviewer for the final visual check.

Check the artwork, then update the store listing

Before submission, compare the finished images with the app experience users will receive. Inspect the rendered captions as well as the captures, and revisit any other image whose claim depends on the redesigned feature. For Apple, plan screenshot maintenance alongside the app version: its screenshot guidance recommends updating images with each new version to reflect the current UI. Do not treat an artwork handoff as publication; the store listing still needs its own update.

On Google Play, Google identifies the Main store listing page in Play Console as the place to manage preview assets, including images in the Graphics section. After the listing changes are live, inspect the public listing on the relevant devices and languages to confirm the replaced images and captions appear where intended. If the redesigned app is not yet available to users, coordinate the imagery with its release rather than showing a journey they cannot use.

Sources

  1. 2.3.3 — Show your app in use with screenshots — Apple Developerdeveloper.apple.com
  2. Helpful tips to get your app published on Google Play — Play Console Helpsupport.google.com
  3. Add preview assets to showcase your app — Play Console Helpsupport.google.com