How to make app screenshots before launch
Every app launches with an empty database. Here is how teams show a populated product without inventing a fake one.
Last updated: 28 September 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.
Write the fixture first
A fixture is the small set of invented values every screen will draw from. Keep it to one page of notes and treat it as canonical: if a name, a number or a date appears on two screens, it comes from this page both times.
| Field | Rule | Why |
|---|---|---|
| Names | Plausible, not famous, not a real customer | A real person's name in a store listing is a problem you do not need |
| Amounts | Uneven, mid-range | A balance of exactly 10,000.00 reads as placeholder text |
| Dates | Relative to one fixed "today" | Absolute dates rot; the listing outlives the shoot |
| Counts | Small enough for a young product | "14,203 members" on a launch listing invites the obvious question |
| Avatars | Generated or licensed | Scraped faces are both a licence and a privacy problem |
| Locale | One per screenshot set | Mixed currency symbols across a set look like a bug |
Three rules for invented numbers
- Never perfectly round. Round numbers are the single clearest tell that nobody thought about the screen.
- Make the arithmetic hold. If a list shows three items, their values must sum to the total in the header. Most people never check. The one person who does is usually the one you were trying to impress.
- Avoid numbers that imply a claim. A performance figure, a yield, a growth rate: anything that would be a statement of fact if it were real belongs on a chart with a source, not inside a mockup.
Continuity across the set
A store listing shows its images in a row and people scan them as one sequence. Inconsistency between frames is noticed even when nobody can say what is wrong. Run this pass over the whole set, not screen by screen:
| Check | What breaks it |
|---|---|
| Same clock | One frame at 9:41, the next at 14:32 |
| Same identity | The account name changes between screens |
| Same status bar | Battery at 100% here, 43% and red there |
| Same totals | A header total that contradicts the previous frame |
| Same theme | One dark screen in a light set, unintentionally |
| Same language | An untranslated string in a localised set |
On the clock: Apple's own marketing imagery has shown 9:41 for years, which is why it reads as neutral rather than as a choice. Any fixed time works. A time that changes between frames does not.
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. For a crypto wallet app: what a rendered wallet screen can and cannot stand in for.
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.
Questions
How do you get app screenshots before you have users?
Write one small fictional dataset first, with the same names, amounts and dates on every screen. Then take one of three routes: seed a real account and screenshot it, build the screen in a design tool, or render a mockup from a template.
Which route should I choose?
Seeding is the most faithful and the slowest; rendering is the fastest and needs the result to be labelled honestly. The choice is a trade between fidelity and time, not between honest and dishonest.
Written by My Larp Wallet, a crypto wallet app simulator: a mockup that opens on your phone, never a real wallet. For your own app’s screenshots, shoot your build; where a wallet mockup fits, and where it does not.
Keep reading
- For crypto wallet app builders: screens before launchThe pitch, the concept test and the design review; not the store listing.
- App Store screenshot sizes for iPhoneEvery accepted pixel size, and which ones you actually have to upload.
- iPhone status bar height and size, 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.
- Larp wallet and crypto larping, explainedThe three meanings the sources confuse, and where the line falls.
- Screenshots for a crypto wallet listing, specificallyWallet listings fail review for reasons other categories never meet, and the images are where most of it happens.
- Fake data in a product demo: where the line actually isEvery launch screenshot contains invented numbers. That is normal. What turns it into a problem is not the invention; it is…
- What a crypto wallet simulator is, and where its limits areIt draws the interface of a wallet without being one. That distinction is the whole subject, and most of the confusion…