Figma mockup or real screenshot for a product image

Same pixel size, opposite weaknesses. Start from the situation you are in, then see what each route costs you.

Published: 30 August 2026 · Last reviewed: 25 September 2026

Start from your situation

• Documenting a shipped feature, or answering a sceptic who asks whether it truly does that: screenshot.
• Pitching a direction that does not exist yet: comp.
• A store listing for a product that has no users: a comp or a rendered mockup, swapped for real screenshots as soon as the app holds data.
• A deck due tomorrow that needs eight variants: rendered mockup.
• Anything a customer will take as proof: screenshot, and nothing else.

The rest of this page explains why those answers hold.

Evidence versus proposal

A screenshot says: this is what the app did, on this device, on this day. A mockup says: this is what the screen should look like. Both come out as a PNG, but only the screenshot can be proved wrong. That single difference governs what you may claim with the image, how long it stays accurate, and what it costs when the design changes on Friday.

So when a team argues about which to use, it is usually arguing about which kind of failure it can tolerate.

Size is a non-issue

Either route exports the same file. A 6.1-inch iPhone 14 Pro measures 393 × 852 pt at 3×, giving 1179 × 2556 px, and the App Store wants PNG or JPEG in RGB without an alpha channel. The accepted sizes and the arithmetic are in app store screenshot resolution and App Store screenshot sizes. If you draw the status bar yourself, the measured status bar geometry counts for more than the canvas size.

How a comp slips away from the device

Each gap is small. Together they are obvious: set a comp beside a real screenshot and it reads as slightly wrong before anyone can name the reason.

• Type. Apple's system font ships in optical sizes, and the platform switches between them by point size, changing letterforms and tracking along the way. A design tool applies the face you chose with the tracking you typed. Text that fits its box by two pixels in Figma is the text that wraps on the device.
• Data lengths. Comps carry content picked to fit. Real devices get a 26-character token name, a German label 40 % longer than the English one, a balance with seven digits. The comp shows the layout at rest; the screenshot shows it under strain.
• OS-drawn chrome. Status bar, home indicator, keyboard, scroll indicators and safe areas, which are 59 pt at the top on a Dynamic Island device and 34 pt at the bottom. Either you rebuild them by hand and they come out subtly wrong, or you leave them out and the image looks like a comp.
• Time. The costly one. A comp is true the week it was drawn. Six months on, the app has moved and the store page still shows an interface nobody can find, which breeds one-star reviews about false advertising rather than about bugs.

What a real screenshot demands

• The feature must exist. A half-built screen cannot be photographed, and urgency does not change that.
• State is awkward to recreate. Putting an account back in last month's exact condition is slow without a fixture script, and nobody writes one before the second re-shoot.
• Re-shoots come as a set. Edit one label and six images get redone, on one device, with one clock and one battery level, or the set stops looking like a set.
• New products photograph as empty. With no data, an honest shot is an empty list.

One thing the screenshot route offers for free and a comp must fake is a uniform status bar. On the iOS Simulator, xcrun simctl status_bar overrides the clock, carrier, signal bars and battery level, so six screenshots can all say 9:41 with a full battery and no retouching. A comp has to draw that chrome by hand, correctly, each time.

The three routes compared

Fidelity to the shipped build. The device screenshot matches it by definition. A comp matches only while someone maintains it; a rendered mockup does not match.

Must the feature exist? Yes for the screenshot, no for the other two.

Cost of one revision. Minutes for a comp, a full re-shoot for a screenshot, seconds for a rendered mockup.

Speed to a first usable image. Hours for a comp, hours to days for a screenshot, minutes for a rendered mockup. Ten localised variants stretch that to hours, days and minutes respectively.

Text rendering. Exact on the device, approximate in the comp and in the rendered mockup. All three export at an exact size.

Drift after six months. High for the comp and the rendered mockup, low for the screenshot.

Personal data. None in a comp or a rendered mockup, since nothing real is shown. A screenshot captured from a real account can expose a lot.

Edge cases (long strings, right-to-left, Dynamic Type). The screenshot reveals them on its own; the comp and the rendered mockup show them only if you draw or type them.

Use as evidence. Only the screenshot qualifies.

The middle option: render from a template

A tool that draws a known screen type from values you supply, on the device itself, sits between the two and yields a screenshot at native resolution. For fidelity it behaves like the comp. For revision cost it beats both, since changing a figure is a keystroke rather than an edit.

Rendered mockups that read as fake tend to fail on the same details:

• Round numbers. Nothing is exactly 10,000.00.
• The wrong era of status bar: a notch layout on a Dynamic Island device, or a battery at the wrong width.
• One typeface throughout. The system font alters optical size with point size, so using a single face for every string gets the biggest text subtly wrong.
• Flat card edges. Genuine cards have a thin graded border that lifts them off the page.
• Flawless content. No truncation and every name the same length is itself a giveaway.

Measured versions of these figures appear in the anatomy of a wallet portfolio screen and the status bar guide.

If the screen is a wallet

For a crypto wallet screen, composing it beats drawing or capturing it. That is what Flexdger Wallet does for one kind of app: it opens in the browser on your phone and you screenshot it there, 1179 × 2556 px on an iPhone 14 Pro. The result is a mockup and says so, which suits the cases where a mockup is the honest answer.

For a wallet layout to start from, see the crypto wallet template and the Ledger Live mockup page; for choosing between a drawing tool and a simulator, design tool vs wallet simulator. Flexdger Wallet is not affiliated with Ledger, Figma or Apple.

Where neither route may go

Made-up figures are ordinary in a store listing, a landing page or a deck. People read a demo account as a demo account, and platform vendors advertise their own products that way. The same image becomes unacceptable once it is offered as a record of something real: a balance shown to obtain money, an investment or someone's trust.

Where that boundary falls for a wallet screen is discussed in where the line is (not legal advice). In practice: decide which artefact you are making before you export, and if a comp will travel beyond the setting that explains it, label it. More on choosing a route is in shipping screenshots before you have users.