Shipshot guide

Six practical ways to prepare app-store screenshots

There is more than one legitimate way to produce store screenshots, and the right one depends on how often you ship, how many locales you serve, and whether you have design help. Here are six routes with the trade-off each actually carries, so you can pick one on purpose instead of by habit.

Raw captures, and composed captures

The first route is uploading unmodified device captures. It is fast, honest, and legitimate, but it wastes the caption space competitors use and gives you no way to explain a screen that is not self-explanatory. The second route composes those captures with headline text and a background, which is where most sets land, and where most of the craft lives.

  1. Use raw captures when the interface is genuinely self-explanatory and time is short.
  2. Move to composed frames when a screen needs a sentence to make sense.
  3. Keep the original full-resolution captures either way; they are your source.

A general design tool, or a purpose-built workflow

The third route is a general design tool, which gives complete freedom and no store knowledge: you manage every target dimension, locale duplicate, and export name yourself. The fourth is a workflow built for store output, which fixes the target sizes and the export step but constrains how far you can restyle. The trade is freedom against bookkeeping.

  1. Count how many files a full release needs across targets and locales.
  2. Choose the design tool if that count is small and the visual ambition is high.
  3. Choose the purpose-built workflow when the bookkeeping is the real cost.

Generated from code, or commissioned from a designer

The fifth route generates frames programmatically from a test run, which is excellent for many locales and reliable repetition, and requires engineering time whenever the design changes. The sixth commissions a designer, which usually produces the best-looking result and the slowest edit cycle, because every small copy change routes back through someone else.

  1. Use generation when locale count is high and the layout is stable.
  2. Use a designer when the visual identity matters more than turnaround speed.
  3. Whichever you choose, agree who can make a one-word caption fix and how.

Choose by your second release, not your first

Any route can produce a good first set given enough effort. The differences appear at the second release, when the product has changed slightly and you need to update six frames across several targets and languages. Pick the route whose update cost you can absorb repeatedly, and keep whatever source material makes that update an edit rather than a restart.

  1. Estimate the effort to change one caption across every target and locale.
  2. Prefer the route that keeps screens, text, and layout separately editable.
  3. Store the project alongside the release so the next person can find it.

Review checklist

✓ The chosen route matches the release cadence and locale count.✓ Original full-resolution captures are kept as source material.✓ The cost of a one-word caption change is known and acceptable.✓ Someone specific can make small fixes without a full handoff.✓ The project is stored where the next release will find it.

Questions to ask before handoff

Are plain unmodified captures acceptable?

Yes, they are valid store assets. They simply forgo the caption space that composed frames use to explain what a screen is showing.

Which route is fastest?

For a single first set, raw or lightly composed captures. Across repeated releases in several languages, the route that keeps everything editable usually wins on total time.

Can I mix routes?

Commonly, yes. Many teams generate the source captures programmatically and compose the final frames in an editor.

Share this guide