An app store optimization checklist covers six things on each listing: metadata (name, subtitle or short description, keywords), the icon, screenshots, preview video, ratings and reviews, and a plan for testing changes.
Check each item against Apple's and Google's current rules, fix the clear problems first, then use the stores' built-in A/B tests for anything you're unsure about.
Every rule below was checked against Apple and Google documentation in November 2026. Where we point to tests, they come from our own database of subscription-app experiments.
We don't have store listing tests with published numbers yet, so we use in-app tests to show the same ideas at work, and we say so each time.
For the bigger picture, see our ASO guide.
Metadata: name, subtitle, keywords and description
Metadata drives search visibility. The fields and limits differ by store, so check each listing on its own.
App Store
- App name, 30 characters or fewer. Put your brand and your main keyword here. Apple's product page guide sets the limit.
- Subtitle, 30 characters or fewer. One clear benefit, written for people. It appears under your name in search results.
- Keyword field, 100 characters. Separate terms with commas and no spaces. Don't repeat words already in the name or subtitle.
- Promotional text, 170 characters. You can change it at any time without a new app version, so use it for current offers or new features.
- No prices, competitor names or trademarked terms. Guideline 2.3.7 of the App Review Guidelines bans packing metadata with "trademarked terms, popular app names, pricing information, or other irrelevant phrases."
Google Play
- App name, 30 characters. Short description, 80 characters. Full description, up to 4,000 characters, per Google's text limits.
- No hidden keyword field. Play reads your visible text, so your main terms need to appear naturally in the title, short description and full description.
- No keyword stuffing. Google warns that repetitive or irrelevant keywords can get an app suspended.
- Follow the metadata policy. The Play metadata policy bans emojis, ALL CAPS (unless it's your brand), ranking claims like "#1" or "Best of Play," and price promotions like "10% off" in titles, icons and developer names. It also bans unattributed or anonymous user testimonials in descriptions.
Both stores
- Localize the metadata for each market you sell in, and do keyword research per language rather than translating your English list.
- Check that the words match what the screenshots promise. A mismatch costs installs from people who did find you.
Localizing pays off in-app too. Photoroom saw +50% upsell screen conversion from localized upsell paywalls in an A/B test.
Daily Horoscope reported +183% trial start rate after localizing paywalls by country, though that was a bundled change with other edits.
Both are vendor-reported case studies on Superwall and RevenueCat, and both are paywall tests, not store tests.
For keyword research tools, see our ASO tools roundup.
Icon
The icon shows up in search, charts and on the home screen, often next to competitors.
It is one of the few assets people see before they open your page.
- Readable at small sizes. One simple shape, no small text.
- Stands out next to the icons around it in search results for your main keywords. Search those terms and look at the results page.
- Google Play spec: 512 x 512 px, 32-bit PNG, up to 1024 KB, per Google's preview asset rules.
- No ranking or price badges on Play. The metadata policy covers icons too.
- Testable on both stores. On iOS, every alternate icon in a test must ship in your app binary, per Apple's product page optimization page.
Our app icon guide covers design patterns.
Screenshots
Screenshots work as an ad, not a gallery.
On the App Store, the first one to three images appear in search results when there's no app preview, according to Apple. Most people decide from those.
- Count: up to 10 on the App Store. Google Play needs at least two, and recommends at least four high-resolution ones (1080 px minimum) to be eligible for more promotion.
- Show the app in use. Guideline 2.3.3 says screenshots "should show the app in use, and not merely the title art, login page, or splash screen." Text overlays are allowed.
- Lead with the outcome, not the feature. "Fall asleep faster" beats "Sleep sounds library."
- One message per frame, with a caption short enough to read in search results.
- Put proof early. A rating, a review quote or a results stat in frame one or two. On Play, any testimonial must be attributed.
- Correct sizes for every device you support. See our screenshot guide for current pixel specs and examples.
- Localize the captions, not just the text fields.
The proof-early idea has some in-app support. On a food app, Vahe Baghdasaryan's short paywall with a review and a results stat lifted install-to-trial by 72%.
It was bundled with a shorter layout, so the review alone didn't cause all of it.
It's a paywall, not a screenshot set, but both are a single screen trying to convince someone to commit.
Video
A preview video is optional on both stores.
Add one only if motion shows something static screenshots can't.
- App Store: up to three app previews, up to 30 seconds each. They autoplay muted, so the first few seconds must work without sound. Apple's guideline 2.3.4 says previews "may only use video screen captures of the app itself."
- Google Play: one YouTube URL, public or unlisted, embeddable, with ads and monetization turned off, and not age-restricted, per Google. Keep it short.
- Add captions for the muted autoplay.
- Check what replaces your first screenshot. On iOS, a preview takes the first slot in search results, so it has to beat your best screenshot.
Video has a good record on paywalls in our database.
FitnessAI saw about +80% revenue after adding video to its paywall, in a before-and-after comparison.
Stardust measured +67% paywall conversion and +12.5% proceeds per user with a video background in a multivariate test.
Both are vendor-reported. They suggest video is worth testing, not that a store preview will lift installs. See our preview video guide.
Ratings and reviews
Your star rating shows next to your icon in search, so it affects conversion before anyone opens the page.
- Use the native prompts only. On iOS, SKStoreReviewController can show the prompt up to three times in a 365-day period, per Apple's ratings guide. Apple's guidelines also bar forcing people to rate or review to use the app.
- Ask after a success, such as a finished task or level, and never mid-task.
- On Android, use the In-App Review API properly. Google says not to ask "Do you like the app?" or similar questions before the card, not to change the card, and not to put the prompt behind a button, because a quota limits how often it shows, per the Android docs.
- Reply to reviews, starting with the lowest ratings and bug reports. Apple notifies reviewers when you respond, and they can update their review. When you ship a fix, mention it in the reply.
- Reset the iOS rating only with care. You can reset the summary rating when you release a new version. It applies to all countries, can't be undone, and written reviews stay visible. Apple advises using it sparingly, because a page with few ratings can also put people off.
Testing plan
Both stores have built-in A/B testing for listing graphics.
Use it for anything on this checklist that is a judgment call rather than a rule.
| Item | App Store: product page optimization | Google Play: store listing experiments |
|---|---|---|
| Variants | Up to 3 treatments vs the original | Up to 2 variants vs the current listing |
| What you can test | Icon, screenshots, app previews | Icon, feature graphic, screenshots; localized tests can add descriptions |
| Running at once | One test per app | One default graphics test or up to five localized tests |
| Max length | 90 days | 6 months |
| Review needed | Yes, App Review approves new assets | Follows Play policies |
Sources: Apple PPO and Google Play experiments. Apple suggests waiting for at least 90% confidence before acting on a result.
Google recommends changing one asset at a time.
A simple order to work in
- Fix rule breaks first. Banned metadata, wrong sizes and missing localizations don't need a test.
- Test the first screenshot or the icon. They're seen by the most people, so they reach a result fastest.
- Test one idea per variant, such as outcome headline vs feature headline. Mixed changes are hard to learn from.
- Check what happens after the install. A listing that promises more can bring in installs that don't convert in the app. Compare trial starts and revenue by cohort around the test dates.
- Use custom product pages for different audiences instead of one listing for everyone. Apple says developers see "a 2.5 percentage point increase on average" when sending people to a custom product page, against a 1.6% average on default pages. That's Apple's figure with no method published. Compare your own numbers with our app store conversion rate benchmarks.
Step 4 matters because a lift at the top of the funnel can fade or flip further down.
Stardust's trial timeline design raised conversion by 13.6%, but trial-to-paid didn't change.
Zumba's web checkout button cut immediate conversions by 25% but raised LTV by 17%.
Neither is a store test, but both show why install rate alone can mislead.
Expect losers too. Stardust's yearly-only paywall lost on both conversion and proceeds per user.
Logging losing tests keeps you from running the same idea twice.
For setup steps, read our product page optimization guide.
To see store listing experiments as we add them, browse store listing tests.
If you'd rather hand the work off, our list of ASO agencies can help you find one.