Shipping screenshots before you have users
Every app launches with an empty database. Here is how teams show a populated product without inventing a fake one.
Last updated: 27 August 2026
Three routes work: seed a real account and screenshot it, build the screen in a design tool, or render a mockup from a template. Seeding is the most faithful and the slowest; rendering is the fastest and needs the result to be labelled honestly. The route that never works is shipping the empty state.
Why the empty state loses
A store listing has a few seconds to answer one question: what does this look like when it is working? An empty list answers "nothing yet". Reviewers do not read the caption first; they look at the first image, and a barren screen reads as an unfinished product regardless of what the copy says.
Route 1 — seed a real account
Create an account, populate it through the app itself, screenshot the device. Nothing else is as faithful: real fonts, real rendering, real edge cases.
- Cost: you need working flows for everything you show. If the feature is half-built, you cannot screenshot it.
- Trap: real data drifts. Re-shooting six screenshots after a design change means recreating the exact same state, which is surprisingly hard without a fixture script.
- Do it if: the app is finished and you will ship the same screenshots for months.
Route 2 — rebuild the screen in a design tool
Figma or Sketch, at the target pixel size, exported directly.
- Cost: the comp drifts from the build. Six months later the store screenshots show an interface the app no longer has.
- Trap: design tools render type slightly differently from the device. Tight layouts that fit in Figma overflow on device, and the screenshot no longer matches what a user sees.
- Do it if: you are pitching a direction rather than documenting a shipped product.
Route 3 — render a mockup from a template
A tool that draws the screen from values you supply, at native resolution.
- Cost: you are limited to what the template covers.
- Benefit: changing a figure is a keystroke, so producing eight variants for eight locales takes minutes rather than an afternoon.
- Do it if: the screen is a known pattern — a portfolio, a feed, a dashboard — and you need it now.
The line that matters, whichever route you take
Numbers you invent are fine in an App Store listing, a deck or a landing page: everyone understands that a demo account is a demo account, and Apple's own marketing does exactly this. The context carries the meaning.
The same image stops being fine the moment it is presented as a record of something real — a balance shown to obtain money, an investment or someone's trust. That is not a grey area, and it is worth deciding which side you are on before you produce the asset rather than after.
A practical habit: keep a visible marker on renders that leave their context. It costs nothing where the context is explicit — you remove it for the store listing — and it saves an awkward conversation when an image ends up somewhere you did not send it.
Sizing, whichever route you pick
Produce at the largest device size and let the store scale down. See App Store screenshot sizes for the accepted pixel dimensions, and status bar dimensions if you are drawing the chrome yourself.
Build the screen instead of describing it
My Larp Wallet composes a wallet mockup in the browser and exports it at 1179 × 2556 px — the native resolution these figures describe. One plan, $19/month.
Open my walletKeep reading
- App Store screenshot sizes for iPhoneEvery accepted pixel size, and which ones you actually have to upload.
- iPhone status bar dimensions, measuredExact geometry of the clock, signal, Wi-Fi and battery glyphs.
- Anatomy of a crypto wallet portfolio screenThe measured layout behind a token list, card by card.