Requirement 4.4.4 asks for one thing and forbids two:

Images should primarily show your app's actual user interface and features. Screenshots must not include desktop backgrounds or browser windows.

Feature images and screenshots that solely contain your app logo are not permitted.

Read quickly, that sounds like an instruction to press the screenshot key. Read properly, it is not. It asks that the image show your app's actual interface. It does not ask that the image be a capture of a screen, and the difference is where all the craft is.

Why a raw capture is rarely the right file

Four problems, and a screen capture has most of them at once.

The shape is wrong. Your admin screen is whatever size your browser window was. The slot is 1600 × 900. Something gets stretched, letterboxed or cropped through the middle of a control.

The density is wrong. An interface designed to be read at arm's length has small type, and small type shrunk into a gallery card is unreadable. The capture is honest and useless.

The data is wrong. Development stores are full of Test Product 3, lorem ipsum, and an order from a customer called asdf. It is real data, and it says the app has never been used.

The chrome is forbidden. The tab strip, the address bar and the desktop behind the window are exactly what the requirement names.

What redrawing means, and what it does not

Redrawing is laying out the app's own interface at the size of the slot: the same components, the same labels, the same states, set at a density a person can read in a gallery. It is a photograph taken with the right lens rather than a painting of a place you have never been.

The line is simple to state and worth stating plainly. You may change how the interface is framed. You may not change what it does.

Allowed: cropping to the part that matters, enlarging the type, filling the store with plausible products, choosing the state that shows the feature working, removing a browser window, putting one label beside a control to name it.

Not allowed: a screen that does not exist, a button the app does not have, a setting that is on the roadmap, a result the app cannot produce, a metric standing in for a feature. That is not a screenshot with better framing, it is a claim - and a merchant who installs on the strength of it uninstalls the same day and writes a review saying so.

The test that keeps you honest

For every image, ask: could a merchant who installs the app today reach this exact state? Not something like it. This.

If the answer is yes, the image is a screenshot however it was produced. If the answer is no, it is a mock-up of a product you have not shipped, and no amount of visual polish changes what it is.

Annotation is allowed, and it is usually the whole job

An interface photographed clean is often silent: the reader sees a table and does not know which column is the point. A short label, an arrow, a highlighted row - these say what the feature is without pretending the app does something else.

Keep the annotation to one idea per image and keep it in the app's own words. Two callouts and a legend is a diagram, and a merchant scrolling a gallery does not read diagrams.

What this looks like when it is done

A finished set does not look like six captures and it does not look like six adverts. It looks like the app, laid out by somebody who knew which part mattered, at a size that can be read on a phone.

That is what the requirement is asking for. It is stricter than a marketing slide and looser than a screen capture, and the space between those two is where a good listing image lives.