What we put on an App Store page and what we leave off

Every App Store page we publish gets the same edit pass before it goes live: cut anything that doesn't help a stranger decide in ten seconds whether to tap Get. That sounds simple until you're staring at a blank subtitle field and a description box that technically allows four thousand characters.

What belongs in the first three screenshots?

The first three screenshots carry almost all the weight, because most shoppers scroll past the rest without reading a caption. We put the core screen — the one a user sees ninety percent of the time they open the app — in slot one, no overlay text, no arrows pointing at features that don't exist yet. Slot two shows the single strongest feature in action, with a short caption under six words. Slot three handles the second-most-asked question, usually something about privacy, offline use, or price. Everything past slot three is optional, and we treat it that way: a settings screen, a dark mode variant, maybe a before/after. If we can't justify a screenshot's presence in one sentence, it gets removed rather than added.

How long should the description actually be?

Shorter than the character limit allows. We write the first two lines assuming that's all anyone reads, since that's the portion visible before "more" gets tapped on both iOS and Android listings. Those two lines state what the app does and for whom, not what it stands for. The rest of the description exists for the minority who tap through — a short list of features, one line each, no adjectives doing the work a verb should be doing. We avoid stacking synonyms for the same claim across three sentences; if "fast" is true once, it doesn't need reinforcing four paragraphs later.

Which keywords go in the subtitle versus the hidden keyword field?

Apple gives developers a subtitle that's visible to shoppers and a separate hidden keyword field that isn't. We put category-defining terms in both, but we keep the subtitle readable as a phrase a human would say out loud, since it also functions as ad copy. The hidden field is where we spend effort on singular versus plural forms, common misspellings, and close synonyms — Apple's own indexing treats these as separate tokens, so listing both forms of a word is worth more than repeating one form twice. This is the same logic behind why stylized Unicode characters break Instagram search: search systems match against plain, predictable tokens, not stylistic variants, so anything meant to be findable gets written in the form the index actually expects.

Why do we leave ratings and awards claims off the page?

A star rating changes weekly and an award expires the year after it's granted, but App Store description text doesn't get revisited on that schedule unless someone remembers to. We've seen listings still bragging about a five-star average that dropped months earlier, or citing a "top app" mention from a roundup nobody can find anymore. Once a claim like that goes stale, it reads as dishonest even if it was true when written. Apple's own rating stars already display automatically next to the listing, so restating that number in the description is redundant on top of being a maintenance risk. We leave that category of claim out entirely and let the automatic rating display do the work.

When do we update screenshots after a redesign?

We update the page the same week a visible redesign ships, not on the next scheduled marketing pass. A screenshot showing an old navigation bar or a removed feature is a bigger drop-off risk than a slightly outdated caption, because the first thing a new user does after installing is compare what they see to what they were promised thirty seconds earlier. That mismatch is also why developer and support contact fields matter more than people assume — when ownership or team structure changes, as it did during the public back-and-forth over who runs Coinbase's Base app, an out-of-date support line or developer name on a store page turns a small internal shuffle into a visible trust problem for anyone searching who's actually behind the product. We treat the developer name, support URL, and privacy-policy link as living fields, checked against reality every time something upstream changes, not just when the screenshots do.

What we leave off, in the end, outnumbers what we put on. No stacked buzzwords, no expiring claims, no screenshot that needs a caption to make sense. A store page is a receipt for what the app actually does today, and it should read that way to anyone who lands on it cold.