Figma mockup vs real screenshot for a product demo

Both produce an image at the same pixel size. They fail in opposite ways, and the failure mode is what should decide.

Published: 27 August 2026

They are not the same artefact

A screenshot is evidence: this is what the app did, on this device, on this day. A mockup is a proposal: this is what the screen should look like. Both export a PNG. Only one of them is falsifiable, and that difference decides everything downstream — what you can claim with it, how long it stays accurate, and what it costs when the design changes on Friday.

Most arguments about which to use are really arguments about which failure the team can live with.

The pixel arithmetic is identical

This is the part people expect to be hard and it is not. An iPhone screen is its size in points multiplied by its scale factor. A 6.1-inch iPhone 14 Pro is 393 × 852 pt at 3×, which is 1179 × 2556 px. So:

• Design a Figma frame at 393 × 852 and export at 3×.
• Or design at 1179 × 2556 and export at 1×.

Either produces a file the App Store accepts, provided you export PNG or JPEG in RGB with no alpha channel. The exact list of accepted sizes is in our guide on App Store screenshot sizes. If you draw the status bar yourself, the measured status bar geometry matters more than the canvas size does.

Where a Figma comp drifts from the device

A design tool is not a rendering engine for the platform. The gaps are small individually and obvious in aggregate — a comp next to a real screenshot reads as slightly wrong before anyone can say why.

Type

Apple's system font ships in optical sizes and the platform swaps between them by point size, adjusting letterforms and tracking as it does. A design tool applies whatever face you selected at whatever tracking you typed. Text that fits a container by two pixels in Figma is the text that wraps on device.

Real data lengths

Comps get placeholder content chosen to fit. Devices get a 26-character token name, a German label 40 % longer than the English one, and a balance with seven digits. The comp shows the layout working; the screenshot shows what it does under pressure.

Everything the OS draws

Status bar, home indicator, keyboard, scroll indicators, the safe areas — 59 pt at the top on a Dynamic Island device, 34 pt at the bottom. A comp either recreates them by hand, and is subtly off, or omits them, and looks like a comp.

Drift over time

This is the expensive one. A comp is accurate the week it is drawn. Six months later the app has moved and the store listing still shows an interface nobody can find, which is the sort of thing that generates one-star reviews about false advertising rather than build failures.

Where a real screenshot costs you

• The feature has to exist. Half-built means unshootable. No amount of urgency changes this.
• State is hard to reproduce. Getting an account back into the exact condition of last month's screenshot is slow without a fixture script, and nobody writes the fixture script until the second re-shoot.
• Re-shoots are all-or-nothing. Change one label and you redo six images, on the same device, with the same clock and the same battery level, or the set stops looking like a set.
• Empty products photograph badly. A new app has no data; shooting it honestly produces an empty list.

There is one thing the screenshot route gets for free that comps have to fake: a consistent status bar. On the iOS Simulator, xcrun simctl status_bar overrides the clock, the carrier, the signal bars and the battery level, so a set of six screenshots can all read 9:41 with a full battery without any retouching. A comp has to draw that chrome by hand, correctly, every time.

Side by side

Criterion	Figma comp	Device screenshot	Rendered mockup
Matches the shipped build	Only when maintained	By definition	No
Feature must exist	No	Yes	No
Cost of one revision	Minutes	A full re-shoot	Seconds
Exact export size	Yes	Yes	Yes
Platform-accurate text rendering	Approximate	Exact	Approximate
Ten localised variants	Hours	Days	Minutes
Drift risk after six months	High	Low	High
Can be used as evidence	No	Yes	No

The third route: render from a template

Between the two sits a tool that draws a known screen type from values you supply and exports at native resolution. It behaves like the Figma column on fidelity and beats both on revision cost, because changing a figure is a keystroke rather than an edit.

That is what My Larp Wallet does for one specific screen — a crypto wallet portfolio — exporting at 1179 × 2556 px. It is worth being blunt about the trade: what comes out is a mockup, openly a mockup, and useful exactly where a mockup is the honest answer.

How to decide in ten seconds

• Documenting a shipped feature, or answering "does it really do that?" — screenshot.
• Proposing a direction that does not exist yet — comp.
• Store listing for a product with no users yet — comp or rendered mockup, then replace with real screenshots once the app has data.
• A deck due tomorrow with eight variants — rendered mockup.
• Anything a customer will treat as proof — screenshot, and nothing else.

The line neither route lets you cross

Invented figures are unremarkable in a store listing, a landing page or a deck. Everyone reads a demo account as a demo account, and platform vendors market their own products this way. The same image stops being acceptable the moment it is offered as a record of something real — a balance shown to get money, an investment or someone's trust.

The practical version of that rule: decide which artefact you are making before you export it, and if a comp is going to travel outside the context that explains it, label it. There is more on choosing a route in shipping screenshots before you have users.