App Store listing: what actually moves installs

The four things seen before anyone reads a word, and the character limits that decide what fits in them.

Published: 27 August 2026

What is actually on screen

A search result is not a product page. In the results list a user sees an icon, a truncated name, a subtitle and the leading screenshots — and the number of screenshots that fit depends on the device width and their orientation, so the only safe assumption is that the first two are seen and the third might be.

Everything else — the description, the feature list, the carefully written third paragraph — is below a fold that most people never reach. It is not worthless. It is simply read by a different, smaller and already-interested audience, and it should be written for them rather than for a stranger.

The fields, and their limits

These are console limits, and they are the actual constraint on what you can say. Writing to them is faster than writing long and cutting.

Field	App Store	Google Play
App name / title	30 characters	30 characters
Subtitle / short description	30 characters	80 characters
Promotional text	170 characters	—
Description	4 000 characters	4 000 characters
Keyword field	100 characters	—
Phone screenshots	Up to 10	Up to 8
Preview video	Up to 3, 15–30 s each	One YouTube link
Feature graphic	—	1024 × 500 px
App icon	1024 × 1024 px	512 × 512 px, 32-bit PNG

Two of these are more useful than they look. Promotional text can be changed without submitting a build, which makes it the right home for anything time-bound. And Google's short description gets 80 characters against Apple's 30 — the same positioning statement has to exist in both lengths, and the 30-character version is the harder write by a distance.

The first screenshot does the work

If one asset deserves disproportionate effort, it is the first screenshot. It is the only thing in the listing that shows the product, it appears in search results, and it is judged in about the time it takes to flick a thumb.

What works in the first frame

• One idea. Not a tour. The single most convincing thing the app does.
• A caption that stands alone. Assume the UI inside the frame is unreadable at thumbnail size, because it is.
• Text large enough to survive downscaling. Anything below roughly 28 px in a 1179 px-wide source turns to mush once the store scales it into smaller device slots.
• A populated screen. An empty state answers "nothing yet", which is not the answer you want.

What does not work

• A device frame you drew yourself — Apple draws its own, and a baked-in bezel is one of the more common rejections.
• Five screenshots that are five variations of the same list view.
• Award badges and press logos in the first frame, before the product.
• An alpha channel in the PNG. Transparency is refused even when nothing looks transparent.

If your app has no data yet, that first screenshot still has to be populated. The routes are seeding a real account, building the screen in a design tool, or rendering it — My Larp Wallet exists for the third one on crypto wallet screens specifically, and the general comparison is in shipping screenshots before you have users.

The icon is the only asset that appears everywhere

Search results, the product page, the home screen, the app switcher, the settings list. It is submitted once at 1024 × 1024 px, without an alpha channel and without rounded corners — the platform applies its own mask, and an icon shipped with corners pre-rounded ends up with a visible double curve. Design it so it survives at the smallest size it will ever be drawn: one shape, one focal element, and no wordmark, because type at that scale is texture rather than text.

The keyword field is a data structure, not a sentence

Apple's 100-character keyword field is comma-separated and invisible to users. Three habits recover a surprising amount of it:

• No spaces after commas — each one costs a character you could spend.
• No plurals where the singular is already there, and no repetition of words already in the app name or subtitle.
• Single words rather than phrases, since terms are combined for you.

Google Play has no keyword field; it reads the title, short description and description instead. That is a real difference in how the two listings should be written, and copying one into the other wastes both.

Test instead of arguing

Both stores have native experimentation, which settles listing debates faster than opinion does:

• Product Page Optimization on the App Store runs up to three treatments against the original, on icon, screenshots or preview video.
• Custom Product Pages give you up to 35 alternate pages, each with its own URL — one per campaign or audience.
• Store listing experiments on Google Play do the equivalent for the Play listing.

One caution on reading results: install rate moves with seasonality, price changes and whatever your paid channels did that week. Run a test long enough to outlast a weekend, and change one asset at a time.

What genuinely does not move installs

• Adjectives. "Powerful", "seamless", "revolutionary" — all of them convert like whitespace.
• A feature list before a reason. The first line has to say what the app is for, not what it contains.
• Keyword stuffing in the visible name, which now reads as spam to users as well as to review.
• A long description written for search on the App Store, where it is not indexed for it.

The claims that get a listing pulled

Both stores treat the listing as a representation of the product. Screenshots that show features the app does not have, invented ratings, fabricated press quotes and demo figures presented as real user results are all removal territory, and in finance categories the tolerance is lower than average.

The workable position is straightforward: demo data in a demo context is normal and everyone reads it that way. Demo data presented as someone's actual balance, returns or track record is a different thing entirely, and the store is not the only party that will treat it as such.