Where a wallet simulator earns its place in a product team

Not the screenshots. The five places a composed screen saves a team actual time are the ones nobody lists, because they are unglamorous.

Published: 14 September 2026

1. Listing images before there are users

The chicken-and-egg problem of every new app: the listing needs screenshots, the screenshots need data, the data needs users, and the users come from the listing. Composing the screens breaks the loop, which is why almost no listing image on any store is a capture of a real account.

2. Empty and full, side by side

Design review usually asks for both at once: what does this look like with nothing in it, and with more than anyone expects? A real account gives you one state — whichever it is in today. Composed screens give you both in the same afternoon, at the same resolution, so the comparison is about the layout rather than about the two devices they came from.

3. Layout QA at values real accounts do not produce

The bugs live at the extremes. A balance long enough to collide with the change badge. A token name that wraps. Twenty rows where the design assumed five. A negative change wide enough to push the amount off the card. You will not get there by waiting; you get there by typing the value and looking.

4. Support documentation

A help page outlives the release it documents and is read by strangers. Any real balance inside it is a permanent disclosure, and the person whose account it was is rarely the person who notices. A composed screen carries the same instructional weight with nothing attached to it.

5. Deck slides where the number is a hypothesis

An investor slide showing a portfolio screen is illustrating a product, not reporting a holding. Stating that plainly on the slide costs one line and removes the only genuine risk: an audience that reads an illustration as a claim. Say it is a mockup, and it is one.

What this is not

None of the five involves persuading anyone that a balance is real. The moment that becomes the point, the tool stops being a design instrument and the question stops being about design. That line is worth naming inside a team, once, before anyone has to decide it alone in a hurry.

Questions

Why not just screenshot the real app?

Because a real account gives you the state it happens to be in. A team usually needs a specific state — empty, full, mid-loss, one token, twenty — and waiting for the account to reach it is not a plan.

Is a composed screenshot acceptable in an App Store listing?

Yes, and it is the norm. What Apple asks is that the images represent the app accurately; it does not ask that the data be yours.

What about screenshots in support documentation?

Composed screens are the safer default. A support page lives for years and is read by strangers, and a real balance in it is a disclosure with no expiry.