How to make app screenshots before you have any users

The screenshot takes ten minutes. Deciding what should be on the screen is the actual work — and it starts with writing a fixture, not opening a design tool.

Published: 27 August 2026

The hard part is the data, not the capture

Every team hits this in the same week. The build runs, the store listing is half-written, and the only account in the database is yours, with three rows named asdf. Taking the screenshot is ten minutes of work. Deciding what should be on the screen takes longer, and it is what separates a listing that reads as a product from one that reads as a staging environment.

So start there, before you open any tool: write the fixture.

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.

Three ways to produce the pixels

Once the fixture exists, the production route is a scheduling decision more than a creative one:

• Seed a demo account and capture it. Most faithful, slowest, and it requires every flow you want to show to actually work. Xcode's Simulator is the practical version of this: it captures at the simulated device's native pixel size and contains no personal data.
• Rebuild the screen in a design tool. Fast for one image, and it drifts from the build within a release or two.
• Render from a template. Fastest when the screen is a known pattern — a portfolio, a feed, a dashboard — and it makes variants cheap. This is the route My Larp Wallet covers for wallet screens: you type the values in and it exports at native resolution.

The trade-offs of each are worked through in shipping screenshots before you have users.

Get the chrome right

If you are drawing the screen rather than capturing it, the frame around your content is where mockups usually give themselves away. The measured figures for a 393 × 852 pt iPhone screen at 3× — that is 1179 × 2556 pixels — are a 59 pt status bar at the top and a 34 pt home indicator area at the bottom. Glyph-level geometry is in the status bar guide.

Produce at the largest device class you intend to ship, currently 1290 × 2796 for the 6.7-inch and 6.9-inch families, and let the store scale down rather than building every size by hand.

The line to decide before you export, not after

Invented numbers in a store listing, a landing page or a demo are ordinary. Everybody understands that a demo account is a demo account, and the context carries the meaning. Apple's own product pages do exactly this.

The same image stops being ordinary the moment it is presented as a record of something real: a balance shown to obtain money, credit, an investment or someone's trust. That is not a design question and it does not have a grey zone. Decide which side of it you are on while you are still choosing the numbers.

A cheap habit that helps: keep a visible marker on any render that leaves the context you made it for. It costs nothing where the context is explicit — you remove it for the store listing — and it saves an awkward conversation when an image turns up somewhere you did not send it.

A short pass before you upload

1. Every frame drawn from the same fixture, with the arithmetic holding.
2. Clock, battery and signal identical across the set.
3. No placeholder strings left — Lorem ipsum, TODO, Test User, a truncated ... where a real string would fit.
4. Exact pixel dimensions for the device class, RGB, no alpha channel.
5. Nothing on screen that the build does not actually do.

That last one is the one that costs a review cycle. Everything else you can fix in the exporter.