App Store optimisation checklist for indie apps

This checklist is for the product page and for the way you ask for reviews. The mechanics of uploading a build and answering App Review belong in the launch process guide. Character limits, metadata fields and experiment features change; confirm the current figures in App Store Connect and in Apple’s product page documentation rather than treating any number below as permanent.

ASO is the product page doing its job

A person finds your app in three honest ways: they searched for a word you covered, they were browsing a category or a feature story, or someone sent them the link. In every case they land on a page that has a few seconds to explain itself. The name, the subtitle, the first two screenshots and the first line of the description do most of that work. Ratings and recency of reviews do some of the rest.

What the product page cannot do is rescue an app that is hard to understand in use, or one that is not useful. If the MVP is still vague, finish that conversation first. ASO is packaging, and packaging a half-finished product only helps you disappoint people faster. A small, focused Apple app with a clear job is easier to name, screenshot and explain than a suite that does a bit of everything.

I also will not tell you that a particular keyword “guarantees” a chart position, or that you should change the name every fortnight. Pick words people actually type, show the app honestly, and measure what you can see in App Store Connect’s analytics rather than in a third-party dashboard you cannot verify.

Name, subtitle and the keyword field

These three fields work together, and they should not repeat each other blindly.

The name is the brand, plus a short clarifier if the brand alone is meaningless. “Metric Time — Decimal Clock” tells you more than “Metric Time” on its own, and more than a slogan. Apple has long limited the name to a modest character count; confirm the current limit in App Store Connect as you type. Don’t pack the name with a list of keywords. It looks desperate, it can be rejected, and it is harder to say out loud.

The subtitle is the one-line explanation under the name. It should finish the sentence “this app is for…”. If the name already contains the category, the subtitle can talk about the job: “A writing timer for drafts,” not a second copy of the name. Again, confirm the current character limit in the form; it is short, and that is useful discipline.

The keyword field is not shown on the product page. It is a comma-separated list of terms, with its own character budget (Apple has documented this field for a long time; check the live limit before you try to be clever with spacing). A few habits help:

• Don’t repeat words that are already in the name or subtitle. Those already count.
• Don’t repeat the same word in singular and plural if the store already treats them as close, and don’t waste characters on “app,” “iPhone,” or the category name you already selected.
• Use commas, not spaces, as the separator, and skip spaces after commas if you need the characters — but only if you have confirmed that still matches current guidance.
• Write for the locales you actually localise, not for every language you can paste into a translator. Junk keywords in a locale you do not support will attract people you then disappoint.
• Avoid competitors’ trademarks. Don’t put another app’s name in the keyword field or the subtitle.

If you want a rough length check while you draft, the Word Counter will count characters; it is not a substitute for the live field in App Store Connect, which is the only count that matters. The URL Slug Generator is occasionally useful when you are also naming a marketing page, so the public URL and the product name do not drift.

Description, what’s new and the first line

The description is shown on the product page, and only the opening is visible before a “more” control. Put the useful sentence first: what the app does, who it is for, and the one thing that makes it worth opening. Features can follow, as a short list, in language a person would use. Don’t start with an award you invented, a paragraph of brand poetry, or a list of the technologies you used.

The description is not a dumping ground for keywords. Write it so a careful reader, or an assistant summarising the page, could lift the first paragraph and not be misled. That is the same standard I use on this site’s articles, and the Title & Meta Bulk Auditor is a reminder of how quickly titles and descriptions drift when you maintain many pages; the App Store fields are fewer, and should be tighter.

What’s New is the release note on the current version. It is read by people who already have the app, and it is visible to people who are considering it. Write what actually changed, in plain language. “Bug fixes and performance improvements” is acceptable when that is all you shipped; it is lazy when you also added a feature. Date the note by the version, and don’t leave a year-old “What’s New” sitting on a page after a later release has gone out.

The first line of What’s New is the one that shows in some contexts without expansion. Lead with the change a user will notice.

Screenshots, preview video and the first frame

Screenshots are a separate, longer job, and I have given them their own guide: How to make App Store screenshots and previews. The ASO-relevant points are few, and they are the ones that affect the first glance:

• The first screenshot does most of the work. It should still make sense at a small size, in the search results and at the top of the product page, and it should show the product, not a vague lifestyle photograph.
• The order is a story, not a tour of every settings screen. Show the job, then the important variations, then any proof (a widget, a Watch view, a result) if you have it.
• A preview video is optional. If you use one, the first frame and the first seconds have to work with the sound off. Don’t auto-play a logo stinger that hides the app.
• Localise captions if you localise the app, and don’t write tiny text that vanishes on a phone.

Apple’s required sizes change when new displays appear. Confirm the current screenshot specifications in App Store Connect before you export a set, and don’t treat a pixel size you remember from last year as permanent.

The Meta & Social Previewer will not preview an App Store page, but it is useful for the marketing URL you will share alongside it: the Open Graph title and image should agree with the name and the first screenshot, not tell a second story.

Categories, age rating and localisation

Pick a primary category that a browsing person would actually look in, and a secondary one only if it is also true. A utility that you file under Games because Games is busier is a way to disappoint everyone who opens the page. Categories also affect the charts you might appear on; that is not a reason to lie.

The age rating and the content questions should match the app. If you later add a feature that changes the answers, update the questionnaire before you ship, not after a rejection. This is a truth-telling exercise, like the privacy declarations and the accessibility labels: the store is asking what the app does, and the answer should be checkable.

Localisation is more than clicking “add locale.” For each language you claim, you should have:

• a name, subtitle, keywords, description and What’s New that a native speaker would stand behind
• screenshots whose captions, and preferably whose UI, match the locale
• an app that actually runs in that language

A machine-translated description with English screenshots is usually worse than a smaller set of locales done properly. If you only have time for one extra locale, pick the one where you can also answer support mail.

Ratings, reviews and when to ask

Ratings influence whether a cautious person will try a small app at all. You cannot buy a genuine rating, and you should not prompt people only when they are likely to be happy in a way that hides everyone else. Apple provides a system API, SKStoreReviewController and the related StoreKit request, so you can ask the system to show a review dialogue. Use that, not a custom “please leave five stars” screen that links out, and never offer an incentive for a review.

When to ask is a product decision:

• Ask after a clear success, not at first launch, not after a crash, and not in the middle of a task. A person who has just exported a file, finished a workout, or completed a first useful result is in a position to judge.
• Cap how often you ask. The system already limits how often the official prompt can appear; don’t add your own nag on top of it every session.
• Don’t route unhappy people into a review and happy people into a prompt. A “how are we doing?” screen that only opens the App Store if the score is high is a pattern reviewers have seen, and it is not an honest rating.
• Reply to written reviews when you can, briefly, and without arguing in public. If a review reports a bug you have since fixed, say so and name the version.

A low rating that describes a real problem is information. A dozen five-star reviews that say “Nice” and nothing else will not help you, and they will not help a reader.

Custom product pages and a light experiment

Apple lets you create additional product pages with their own screenshots and some of their own metadata, and to run product-page experiments on the default page, within the current rules of App Store Connect. For a small app these are optional, and they are easy to overuse.

A light approach:

• Use a custom product page when you have a genuine second audience and a URL you can send them to (for example, a Watch-first page, or a page aimed at a campaign). Don’t create six pages you then never mention.
• Run one experiment at a time, with a single clear question: “Does this first screenshot do better than that one?” not “What if we change the name, the icon, the screenshots and the subtitle at once?”
• Give the experiment enough time and traffic to mean something. A weekend of a few dozen views is not a result. If you cannot tell, keep the clearer page.
• Stop experiments that lose. Don’t leave a worse first screenshot in place because the test “hasn’t finished.”

You do not need a specialist ASO vendor to do this. You need a hypothesis, a screenshot, and the humility to revert.

A checklist you can rerun after each release

Walk this list when you ship a version, and when you change the marketing URL:

• The name and subtitle still describe the app in the current version, and they do not duplicate each other.
• The keyword field has been reviewed against the current character limit, without trademark stuffing or repeated terms.
• The first line of the description still tells the truth, and What’s New matches this release.
• The first two screenshots and the preview’s first frame still show the current UI.
• Categories, age rating and privacy disclosures still match the app.
• Each claimed locale has real metadata and matching screenshots.
• The review prompt still fires after a success, not at launch, and you have read recent written reviews.
• Any custom product page or experiment is still intentional, and the default page is one you would be happy to be judged on.
• The marketing site, if you have one, uses the same name and a preview that agrees with the store page.

Then look at the numbers App Store Connect actually shows you — impressions, product-page views, conversion to download — and treat a small sample as a small sample. If a change did nothing, revert the cleverness and spend the time on the app.

Key takeaways

• ASO for a small app is a clear name, subtitle, keywords, screenshots and a truthful description, not a bag of ranking tricks.
• Confirm current character limits and product-page features in App Store Connect; don’t treat a remembered number as permanent.
• Put the useful sentence first in the description and in What’s New, and keep the first screenshot honest at a small size.
• Ask for a review after a success, through the official prompt, and reply to written reviews without games.
• Experiment one change at a time, and rerun a short checklist after every release.

If you want a second pair of eyes on a product page, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.