Table of contents
- Quick nav
Can You Use Design Mockups as App Store Screenshots?
Direct answers
| Asset | App Store | Google Play / China Android | Notes |
|---|---|---|---|
| Real UI from a runnable build (device or simulator) | Preferred | Preferred | Matches the binary under review |
| Hi-fi design comps that match the binary | Medium risk / gray area | Spot-checked by many consoles | Mismatch → “inaccurate” / misleading |
| Wireframes / lo-fi prototypes | High risk | High risk | Does not look like actual use |
| Studio watermarks / “preview only” | High risk | High risk | Looks unfinished or stock |
| Competitor or unlicensed UI | Forbidden | Forbidden | IP + deception |
Store screenshots must show the app people install, not the deck from design critique. On Apple’s side that maps to Guideline 2.3 screenshot topics; broader rejects: screenshot rejection reasons.
Why this question trends
Indie teams often need creatives before the build is frozen, or only have Figma. Reviewers compare screenshot story ↔ installed flows. A slight color shift rarely matters; missing screens, different CTA copy, or a paywall that is not in the binary become 2.3.3-style “doesn’t accurately reflect the app” issues.
When comps might survive review
All of the following should be true (still not a guarantee):
- The submitted binary contains every screen and string shown.
- Comps are final visual, not exploration; components, type, and palette match the build.
- Exports are cropped to store sizes with no Figma chrome, grids, or comment layers.
- No unreleased features; no other-platform UI pretending to be this binary.
Safer path: capture from an installable build, then add captions/background only in design tools. Simulator export: iOS simulator screenshots for App Store.
Wireframes, diagrams, competitor UI
| Type | Guidance |
|---|---|
| Wireframes / gray boxes | Do not upload |
| Conceptual diagrams (not app UI) | Not for phone screenshot slots |
| Competitor UI | Never — even “for comparison” |
| System Settings pages as your feature | No — inaccurate |
Watermarks
| Watermark | Stance |
|---|---|
| Tiny own-brand mark in a corner | Still discouraged |
| “Internal / do not distribute” | No |
| Default mockup-site watermark | Remove before upload |
| Timestamps / debug HUDs | No |
Status bar cleanup: status bar cleanup guide. Device frames: frame rules.
Recommended workflow
- Freeze UI to the same tokens as the review build.
- Capture from the installable app along a five-frame story.
- Market only on the outer layer (caption, background, optional frame); do not repaint buttons/data into a prettier state the binary lacks.
- Export to slot specs without alpha issues (ASC upload errors).
- Tap-test: every primary control in the shots exists in the build.
Browser batching with real captures: AppShot Maker — captions on real pixels, not fake UI from empty wireframes.
If you were already rejected
- Reply that screenshots now come from the current binary, with a short before/after note.
- If the feature is unfinished: drop that frame or wait — do not “hold the slot” with comps.
- Custom Product Pages must be equally truthful: CPP guide.
Self-check
- Each frame is reachable in the binary
- No wireframes, annotations, or third-party watermarks
- No competitor UI or vaporware features as live UI
- Copy and paywalls match the build
- Sizes/formats match the target store
- Five-frame story is a real path, not a poster collage
RACI that prevents last-minute fake shots
| Role | Owns | Does not own |
|---|---|---|
| Design | Five-frame story, captions, type | Exporting exploration comps as store masters |
| Engineering | Installable build + stable test account | Photoshopping unimplemented features into shots |
| Marketing | Benefit priority + compliant claims | Forcing vaporware creatives to “hit a date” |
Make “screenshots from the installable build” part of launch DoD. If the calendar is brutal, at least make the first frame and anything paywall-related real.
Gray-area examples (still document the risk)
| Example | Risk | Safer alternative |
|---|---|---|
| Final Figma screen identical to build, exported without chrome | Medium | Prefer device capture of the same screen |
| Slightly newer illustration behind a real UI layer | Medium-high | Ship illustration only as caption background |
| Clickable prototype video used as App Preview | High if UI differs | Record the binary |
If legal or UA insists on comps for a pre-registration landing page, keep those off App Store Connect until the binary catches up.
Takeaway
Design mockups as store screenshots are a gray area only when they match the binary and export clean; wireframes, watermarks, and competitor UI are hard nos. The lowest-drama compliant path is capture the installable app, then add ASO captions outside the UI. Conversion and review both depend on “the app in the shots = the app they install.”
Ready to design your store screenshots?
Try AppShotMaker and turn raw captures into store-ready screenshots in minutes.