Shipshot guide

How app screenshot workflows have changed

If you last built a store screenshot set a few years ago, some of your assumptions are now expensive and some are still exactly right. It is worth separating the two before you rebuild a process around habits that no longer pay.

Device sizes moved, and kept moving

The specific pixel dimensions you memorised have been superseded, and display groups now list several accepted alternatives rather than one canonical size per device. Any process that hard-codes a remembered number will eventually produce a rejected upload. The durable habit is to check the current specification at release time rather than trusting a note from a previous launch.

  1. Discard remembered dimensions and check the current published specifications.
  2. Note that a display group may accept more than one pixel pair.
  3. Re-check at each release rather than once per project.

Localization stopped being optional-feeling

Serving several languages used to be an advanced move. It is now ordinary, which changed the shape of the work: the cost is no longer producing one beautiful set, it is producing and maintaining the same argument across many versions. Processes built for a single English set tend to collapse quietly at that point.

  1. Plan for multiple language versions from the first release, even if you ship one.
  2. Keep captions separate from images so languages are an edit, not a rebuild.
  3. Budget for the recurring per-release cost rather than a one-off translation.

Generated imagery raised the accuracy stakes

It is now easy to produce a screenshot that looks like an app and shows an interface that does not exist. That makes verification a real step in a way it was not when every frame came from a capture. The rule that has not changed is that a screenshot is a claim about your product, and it has to be one the installed app can honour.

  1. Trace every frame back to a screen a user can actually reach.
  2. Treat generated imagery as a draft to verify, never as evidence.
  3. Remove any interface element the product does not really render.

What did not change at all

The first frame still does most of the work. Legibility at listing size still beats visual ambition. Realistic content still outperforms empty states. An accurate claim still outperforms a bold one you cannot support. These have survived every platform revision, and they are worth more than any specific tool decision.

  1. Spend disproportionate effort on the opening frame.
  2. Judge every frame at listing size before judging it at full size.
  3. Keep claims within what the submitted build actually does.

Review checklist

✓ Remembered dimensions were replaced by a check of the current specification.✓ The process assumes several languages rather than one.✓ Every frame traces back to a real, reachable product screen.✓ The opening frame received disproportionate attention.✓ Frames were reviewed at listing size, not only at full size.

Questions to ask before handoff

Are my old screenshot dimensions still valid?

Check rather than assume. Display groups have changed and several now accept more than one pixel pair, so a remembered number is a common cause of a rejected upload.

What is the biggest process change?

Localization moving from optional to normal. It changes the cost structure from producing one set to maintaining many versions of one argument.

What advice has aged best?

Make the first frame do the work, keep it legible at listing size, and never claim more than the shipped build does.

Share this guide