# Wallet app screenshots and App Review: the three questions a reviewer asks

Source: https://flexdger.com/blog/crypto-wallet-app-store-screenshots
Updated: 2026-11-01
Published: 2026-09-16
Topic: App Store screenshots (https://flexdger.com/blog/app-store)

> How App Review reads crypto wallet screenshots: guidelines 5.2.1, 4.1(c), 2.3.3 and 2.3.1(a), common rejections, and filling a listing with no users yet.

A reviewer looking at a wallet listing runs through three questions: whose product is this, is this the app, and what does it promise? Each has a guideline behind it. Here is how they apply to wallet images, and what to put in a listing that has no users yet.

**Short answer:** Screenshots that echo another company’s interface, icon or product name run into App Review guidelines 5.2.1 and 4.1(c), whatever tool made them. A wallet screen built from common conventions (balance on top, token rows, tabs) under your own name and mark is a different matter.

## Three questions, three guidelines

Wallet listings do not fail on pixels. They fail on the reviewer's reading of what the pictures claim, and that reading tends to follow three questions.

1. **Whose product does this look like?** Guidelines 5.2.1 and 4.1(c).
2. **Is this the app?** Guideline 2.3.3 and guideline 2.3.1(a).
3. **What does it promise?** The caption and the numbers, covered in the wallet-specific section below.

## Question one: whose product is this?

Take the branding off any wallet and what remains is a layout, not a firm. The total sits first at display size, the day's change sits beneath it, the assets are rows with an icon, a name, an amount and a value, and navigation lives in tabs. Nobody owns that arrangement, and [the anatomy of a crypto wallet screen](https://flexdger.com/guides/crypto-wallet-ui-anatomy) records its geometry. What does have an owner is the wordmark, the icon, a palette used as an identity, and the product name.

Apple's App Review Guidelines draw the boundary. Guideline **5.2.1** warns against using protected third-party material, trademarks included, without permission, and against “misleading, false, or copycat representations, names, or metadata”. Guideline **4.1(c)** is tighter: another developer's icon, brand or product name may not show up in your app without their approval. The reviewer asks whom the screenshots seem to depict. If the honest answer is anyone but you, the submission has a problem, whether the image came from a capture, a design file or any other tool.

| What the screenshot contains | How review reads it |
|---|---|
| Your own name, icon and palette on a layout made of shared conventions | Fine |
| Another wallet's logo, wordmark or icon, or a copy of its interface | Guidelines 5.2.1 and 4.1(c) |
| Token logos that show which chains the app supports | Ordinary, provided the listing does not look endorsed |
| A splash screen or login form as the only images | Guideline 2.3.3 |

Naming a product in order to discuss it is routine, as in a review or a news item. Wearing the name to catch the traffic that belongs to it is not, and neither is shipping an interface a person could take for the original. In metadata, describe the category. “Crypto wallet” is a category; a named wallet is somebody's trademark.

## Question two: is this the app?

Guideline **2.3.3** asks screenshots to show the app in use, not only title art, a login page or a splash screen. A marketing poster with a phone drawn on it fails that test. Guideline **2.3.1(a)** addresses marketing an app misleadingly, for example by promoting content or services it does not really provide, and a screenshot of a feature missing from the submitted binary lands squarely inside it.

Two more mistakes belong here, and they are the dullest and the most common:

- **A third-party mark hiding in the frame.** A logo, wordmark or product name somewhere on the screen, often in a token row, the place people forget to check.
- **File faults.** An alpha channel, a device frame baked into the picture, or dimensions that match no declared display class. They are easy to avoid; see [why App Store screenshots get rejected](https://flexdger.com/blog/why-app-screenshots-get-rejected).

## Question three: what does it promise?

**A picture that implies a return.** A portfolio showing growth, with a caption suggesting the app produced it, shifts the listing from software into financial promotion. The screenshot alone is rarely at fault; the screenshot plus its caption usually is.

**A balance dressed as typical.** Populated screens are normal. Put “average user portfolio” under one and you have made a claim, which has to be true and supportable.

**Logos you do not own.** Token logos belong to their projects. Showing them to say a chain is supported is ordinary. Showing them so the listing reads as backed by that project is not.

## A listing with no users yet

Every wallet launches before it has users, and an empty portfolio is a poor first image. The usual answer is a composed, populated screen: Apple asks that images represent the app accurately, not that the figures belong to a real person. A general piece on this is [making screenshots before you have users](https://flexdger.com/guides/screenshots-before-you-have-users). Until the build can display one, use [a populated wallet screen for the deck and the concept test](https://flexdger.com/for/crypto-wallet-builders); the store listing itself should show your build.

The recipe, then: draw your own screen from the shared conventions, put your own name and mark on it, and fill it with invented data. The result can be submitted, defended and reused, and you can make twenty variants, which a device capture of an empty app cannot offer.

## Order of work

Compose the screens first, at native resolution, with values you can defend. Write the captions second, and read each as a sentence someone will hold you to, because in this category they will. Check the sizes last, since that is the only step with a definite right answer. Those numbers live elsewhere on the site and are not wallet-specific: [the current sizes](https://flexdger.com/guides/app-store-screenshot-sizes), [which sets Apple scales for you](https://flexdger.com/guides/app-store-screenshot-sizes#scaling), and [what to do when the dimensions are rejected](https://flexdger.com/blog/screenshot-dimensions-are-wrong).

If the image is bound for a deck and not a listing, different limits apply; [showing a crypto portfolio in a pitch deck](https://flexdger.com/blog/crypto-portfolio-pitch-deck) picks it up from there.

The plain statement of the rule this page keeps circling: a mockup is honest when the viewer knows what they are looking at, and it is a prop, never proof. Presenting one as evidence of holdings is not a review matter at all. It is another problem ([where fake data in a demo is normal and where it becomes fraud](https://flexdger.com/blog/is-larp-wallet-legal)).

Not affiliated with Apple: its guidelines are quoted here as published.

## Sources

- [Apple, App Review Guidelines (2.3.1, 2.3.3, 4.1(c), 5.2.1)](https://developer.apple.com/app-store/review/guidelines/), read November 1, 2026

## Questions

### Is a wallet listing measured differently on image size?

No. Dimensions are identical across categories. What changes is how closely the claims in the images get read.

### Is it a problem to show a big number in the portfolio?

A filled-in screen is normal, and an empty one persuades no one. Trouble starts when the image or caption suggests that the app is what produced the number.

### What most often triggers review problems in this category?

Money-related apps get their claims examined along with their design. Images that promise performance, and text that sounds like financial advice, are the two repeat causes.

### May a screenshot imitate a famous wallet?

Not if it carries that company’s interface, icon or product name: guidelines 5.2.1 and 4.1(c) apply however the image was produced. A screen using shared wallet conventions under your own brand is a separate thing.