Shipshot guide

How to capture app-store screenshots from a simulator or device

Everything downstream depends on the captures you start from. A composed frame cannot rescue a screenshot taken at the wrong scale, full of placeholder data, or showing a personal email address. Capture deliberately and the composition step becomes straightforward.

Decide simulator or device before you start

A simulator gives you exact device classes on demand, a clean environment, and easy repetition, which matters when you need several device sizes. A physical device gives you genuine rendering, real performance, and real content, which matters when the app depends on the camera, sensors, or hardware that a simulator approximates. Choose per app rather than by preference.

  1. Use a simulator when you need several device classes and repeatable state.
  2. Use a device when camera, sensors, or real performance are part of the story.
  3. Keep one method for the whole set so rendering stays consistent between frames.

Seed content that looks like a real account

This is where most capture sessions go wrong. Empty states, Lorem ipsum, test entries named asdf, and a contact list of one person all signal an unfinished product. Prepare an account whose content is plausible, varied, and appropriate for the audience you are selling to, then capture from that account every time.

  1. Build a demo account with realistic names, amounts, dates, and history.
  2. Vary the content so lists do not look duplicated or generated.
  3. Reuse the same account for every frame so the story stays continuous.

Remove anything that is not yours to publish

Captures routinely carry personal email addresses, real names, phone numbers, account balances, third-party logos, and other people's copyrighted content. All of it ends up on a public store page. Review each capture specifically for material you do not have the right to publish, and replace it in the app before recapturing rather than painting over it afterwards.

  1. Scan every capture for personal data, real contacts, and third-party content.
  2. Fix the underlying demo data and recapture rather than editing pixels.
  3. Check notification banners and overlays that appeared mid-capture.

Capture at native resolution and name files predictably

Capture at the device's native resolution and never upscale a smaller capture to reach a required size; enlargement is visible as soft text and it is a common cause of a set that looks slightly wrong without an obvious reason. Name files so their device class, frame order, and locale are readable at a glance, because you will be matching dozens of them later.

  1. Capture natively and keep the untouched originals in a source folder.
  2. Never enlarge a capture to fit a larger target.
  3. Adopt a naming pattern covering device class, order, and locale.

Review checklist

✓ Simulator or device was chosen deliberately and used consistently.✓ Demo content is realistic, varied, and audience-appropriate.✓ No personal, third-party, or unlicensed material remains visible.✓ Every capture is native resolution with no upscaling.✓ Files are named so device, order, and locale are obvious.

Questions to ask before handoff

Do I need captures for every device size?

Capture the largest required class well, then check how smaller classes look. Apple documents scaling fallbacks between display classes, so a native capture for every listed size is not always necessary.

Can I scale a capture up to reach a target size?

Avoid it. Enlargement softens text and interface edges in a way that is noticeable at listing size. Recapture at the larger class instead.

Should the demo account use my own data?

No. Build a separate demo account so no personal contacts, balances, or messages reach a public listing.

Share this guide