App Store Optimization in 2026: what actually moves installs

ASO and SEO share a name and almost nothing else

The comparison is made so often that it has become a source of bad decisions. Both disciplines involve text and rankings, so people assume the same playbook transfers. It does not, and the differences are structural.

Search engines crawl an open web of pages you own and can extend indefinitely. You can publish a hundred pages, earn links between them, and build authority over years. App stores index a closed system: a fixed set of submitted fields, no crawling, no links to earn, and one listing per app per store. Your entire ranking surface on the App Store is essentially four fields. There is no equivalent of a content strategy, because there is nowhere to put the content.

The second difference matters more. In app stores, behaviour carries far more weight relative to text than it does in web search. Apple states that App Store search results are based on text relevance in the app name, subtitle, keywords and primary category, alongside user behaviour including downloads, ratings and reviews. Google Play goes further and enforces a technical quality floor that can suppress your visibility outright regardless of your metadata.

The practical consequence is that ASO rewards conversion work more than SEO does. Raising the share of people who install after seeing your listing pays twice: more installs from the same impressions, and better behavioural signals feeding back into ranking. Teams who treat ASO purely as keyword research are working on the smaller half of the problem.

There is a third difference worth naming, because it changes how you plan. Metadata changes ship with releases, which means ASO has release-cycle latency baked in, and it also means the feedback loop is unusually fast once live. You can be wrong quickly and cheaply, which is a better position than it sounds.

How the App Store and Google Play rank differently

If you take one thing from this article, take this: the two stores index different amounts of text, and the same listing strategy cannot be correct on both.

	App Store	Google Play
Indexed text	App name, subtitle, keyword field, primary category	Title, short description, full description — a genuine full-text index
Hidden metadata	Yes, the 100-character keyword field	No
Descriptions indexed	Not part of the stated ranking basis	Yes
Stated behavioural signals	Downloads, ratings and reviews, engagement	Installs, engagement, plus enforced technical quality thresholds
Technical quality as a ranking lever	Indirect, through ratings	Direct and enforced through Android vitals
Listing variants	Up to 70 custom product pages	Up to 50 custom store listings
Native A/B testing	Product page optimization, up to 3 treatments	Store listing experiments, up to 2 variants

The asymmetry in the second and third rows is the whole game. On Apple, you have a private field to place terms you would never write in visible copy. On Google, everything indexed is also read by a human, so ranking terms and persuasive copy have to be the same words. That single constraint explains most of the difference between a good iOS listing and a good Android one.

Apple metadata: the name, the subtitle and the hidden keyword field

Apple gives you very little room, and the limits are firm: 30 characters for the app name, 30 for the subtitle, 100 for the comma-separated keyword field, and 170 for promotional text. Promotional text can be changed without a new release, and Apple states plainly that it does not affect search ranking — so filling it with keywords wastes one of your few editable conversion assets.

How to use each field:

App name (30). Your brand plus, if there is room, the single strongest descriptive term. This is the highest-weighted text you control and the thing people read first. Resist the urge to append three terms separated by dashes; it looks like spam to a buyer even when it works.

Subtitle (30). One clear statement of what the app does, using the words your users would use. This carries ranking weight and is read by humans, so it has to do both jobs at once. It is the hardest 30 characters in mobile marketing and worth several drafts.

Keyword field (100). The part most teams get wrong. Practical rules that follow from Apple’s own guidance:

1. Separate terms with commas and no spaces — spaces cost characters and buy nothing.
2. Never repeat a word that already appears in your app name or subtitle. Apple combines them; duplication is wasted space.
3. Do not include plurals of terms you already have, category names, or trademarked terms you do not own. Apple names improper keyword use as a common cause of rejection.
4. Terms are combined into phrases automatically, so include the components rather than the phrases.
5. Include misspellings only where they are genuinely common; most are not worth the characters.

Description. Not part of Apple’s stated ranking basis, so write it for the person deciding. The first lines are what appears before anyone taps to expand, which makes them the only part most readers see.

Google Play: a full-text index, and what to do with it

Google Play indexes your title, short description and full description. That is far more text, and the instinct is to fill it with terms. Google’s own listing guidance closes that door directly: avoid unnecessary keywords added to improve search results, because it will not affect ranking and produces a bad experience. The short description is capped at 80 characters, and it is the line that appears before anyone expands the listing.

So the Play strategy is different in kind, not just in degree. Write a genuinely good description that naturally contains the terms people search for, with your primary term appearing early and a small number of related terms used where they belong in real sentences. Then stop. There is no additional field to game.

Two Play-specific levers are worth more attention than they usually get:

Custom store listings. You can create up to 50 listings targeted by country or region, by install state (churned users, lapsed users, non-buyers, repeat buyers), by the search keywords people used to find you, by pre-registration status, by custom audiences, or by arrival from a Google Ads campaign. You can vary the app name, icon, descriptions and graphics. This is closer to landing page strategy than to keyword optimisation, and it is the single most under-used feature in Play Console. One caveat that trips teams up: custom store listings are not automatically translated, so a region-targeted listing still needs its own translation work.

App Links. Verified Android App Links tie your domain to your app through a Digital Asset Links file, so links to your website open directly in the app without the disambiguation dialog. This is not a ranking factor, but it is a large part of how web traffic becomes app engagement, and app engagement is a behavioural signal. If you run a website and an app and have not verified your links, do that before your next round of keyword work.

Creatives: the icon, the first frames, and the scroll that decides

Metadata gets you seen. Creatives get you installed, and this is where most of the recoverable value sits.

The icon is the only asset that appears everywhere — search results, charts, the home screen afterwards. It has to be legible at very small sizes and distinct from every competitor in your category on a crowded results page. Test it against the category, not in isolation, and resist the temptation to include words in it.

Screenshots. Apple accepts one to ten per localisation, in JPEG or PNG with no alpha channel or transparency, at defined dimensions per device class. The first frames do nearly all the work, because they are what a browsing user evaluates before deciding whether to scroll. Treat the sequence as a short argument rather than a feature tour:

1. What the app does, stated in the frame itself, not implied by a screenshot of your empty dashboard.
2. The reason to choose it over the obvious alternative.
3. What using it actually feels like — the one moment that makes the product worth having.
4. Proof, if you have any that is real: a rating, an award, a well-known integration.
5. Everything else, in descending order of interest.

App previews and videos. Worth the effort when the product is visual or its value is hard to explain in a still. Assume they are watched without sound, and that the first seconds decide whether they are watched at all.

The most common creative failure is not ugliness. It is ten near-identical screens of interface with feature captions nobody reads, produced because someone had to fill ten slots. Three excellent frames beat ten mediocre ones, and the only honest way to settle it is a test. If you need the design capability for that, it sits between interface design and graphic design rather than in either alone.

Conversion experiments: what each store actually lets you test

Both stores now provide native testing, and their designs differ in ways that affect what you can learn.

Apple’s product page optimization lets you run up to three alternate treatments against your original page, one test at a time. You can test app icons, screenshots and app previews, localised across all languages or a selection. Tests run for up to 90 days or until you stop them, you control the percentage of traffic allocated to the test, and Apple reports results at a confidence level of at least 90%. New metadata in a treatment must clear App Review before the test can publish.

Google Play’s store listing experiments allow up to two variants against your current listing, with traffic split equally across variants and the total proportion under your control. Default graphics experiments cover the icon, feature graphic and screenshots; localised experiments can also cover descriptions. You can run one default graphics experiment or up to five localised experiments at a time, and an experiment auto-completes after six months. Google’s own advice is to test one asset type at a time, so you can tell what caused a change.

Three rules that make the difference between testing and theatre:

• Change one thing. A test of a new icon and new screenshots tells you the pair is better, not which one, and you will make the wrong follow-up decision.
• Let it finish. Stopping early on a promising result is how teams accumulate a portfolio of changes that never reproduce. If a test reports insufficient data, that is a real answer.
• Test the biggest thing first. The icon and first screenshot move more than the fifth screenshot ever will.

Apple’s custom product pages are a separate tool, sometimes confused with testing: up to 70 additional versions of your page, each with its own URL, varying screenshots, promotional text, previews, keywords and deep links. These are not experiments, they are destinations — one per campaign, audience or feature — measured in the Acquisition section of App Analytics. Use them to make paid and social traffic land on a page that matches the promise that brought people there.

Post-install signals: retention, ratings, and the crash rate the store polices

This is the part of ASO that no amount of metadata work can substitute for, and the part most often left out of an ASO proposal because it belongs to engineering rather than marketing.

Google Play is explicit. Android vitals defines bad-behaviour thresholds and acts on them: a user-perceived crash rate of at least 1.09% of daily users across all device models, or 8% on a single device model, and a user-perceived ANR rate of at least 0.47% overall or 8% per device model. Exceed them and your app is likely to be less discoverable on Google Play, and a warning may appear on your store listing. Play generally assesses the last 28 days, though it can act sooner on a spike.

Read that again as a marketer, because it is unusual: a crash rate above a published threshold is a distribution problem, not just a quality problem. It means the highest-return ASO work for a struggling app is sometimes a stability sprint, and that the ASO owner needs standing access to the vitals dashboard rather than a quarterly summary.

Ratings work differently but point the same way. Apple lists ratings and reviews among the factors behind search results, and on both stores the star rating is the most prominent single element on your listing after the icon. Retention is not published as a ranking factor by either store, but it drives everything that is: people who stay rate more generously, uninstall less, and produce the engagement both stores measure.

The uncomfortable implication is that ASO cannot rescue a product people do not like. It can get more of the right people to try it, which makes the underlying quality problem arrive faster.

Asking for ratings without annoying people, or getting expelled

Both stores provide an official prompt and both police its use, so the rules matter.

On Google Play, the In-App Review API enforces a time-bound quota — calling it repeatedly over a short period may simply not show the dialog. Google’s documented prohibitions are specific: do not ask users any question before or while showing the card, including “do you like the app?” or “would you rate us five stars?”; do not modify the card’s size, opacity or shape or place overlays on it; and do not build a “Rate now” button that triggers the flow, because a user who has hit their quota sees nothing and concludes your app is broken. Send them to the Play Store listing instead.

On Apple, the constraints come from the review guidelines. Guideline 3.2.2 states that attempting to manipulate reviews, or inflating chart rankings with paid, incentivised, filtered or fake feedback — including through third parties — may result in expulsion from the Apple Developer Program. The same section prohibits forcing users to rate or review an app in order to access functionality or content. There is no ambiguity in either rule, and the agencies that offer to “boost your ratings” are selling you a risk you do not want.

What works, within the rules, is timing and repair. Trigger the prompt after a moment of demonstrated success — a completed task, a saved result, a returned visit — never on first launch and never mid-task. And reply to negative reviews properly, because a user can revise a review after a reply, and a repaired one-star review changes your average twice over. Reply for the person reading your responses before installing, too; that reader is evaluating whether you are the kind of company that answers.

Localisation: the highest-return work most teams skip

Apple supports 49 languages and locales for App Store metadata. Google Play offers translation into over 100 languages, provides free machine translation for a set of them, and will show an automated translation of your listing to users requesting a language you have not supplied — with a handful of exceptions.

That last point is why localisation gets skipped: something appears, so it looks handled. It is not. An automated translation of your listing is not localised keyword research, and the terms people search for in a market are frequently not the terms a translation engine produces. Two things are worth doing properly, in this order:

1. Localise the ranking fields for your top markets. On Apple that means the name, subtitle and keyword field, researched in-language rather than translated from English. Keyword sets rarely map one to one, and this is where the ranking gain is.
2. Localise the first screenshots. Text in an image is not machine-translated by anyone, and a screenshot in the wrong language is a visible signal that the app is not for this market.

Remember that on Google Play, adding localised graphics for a language excludes those users from your default graphics experiments — so plan localisation and testing together rather than discovering the interaction mid-test.

Localisation is also the clearest case where you can do this without an agency. If you have a native speaker in the market who understands the product, they will produce better keyword research than a translation vendor and a lot of consultancies.

Measuring ASO without fooling yourself

Both stores define their metrics precisely, and the definitions matter more than they look.

Apple counts an impression as your app being viewed on the Today, Games, Apps or Search tabs for more than one second, including product page views. Conversion rate is total downloads and pre-orders divided by unique device impressions. Note what that means: your conversion rate can fall while your business improves, because a successful campaign that generates many impressions from a broad audience will dilute the denominator. Judge campaign traffic and organic search traffic separately, or you will draw the wrong conclusion from a healthy quarter.

Practical measurement discipline:

• Separate the funnel stages. Impressions, product page views, and downloads answer different questions. Falling impressions is a ranking or category problem; falling page-view-to-download is a creative problem.
• Annotate every change. Every release, metadata edit, price change, feature placement and paid campaign start. Without a timeline you will attribute a store-side algorithm change to your subtitle rewrite.
• Treat third-party keyword volume estimates as directional. Neither store publishes search volume. Every tool’s numbers are modelled, and the models disagree with each other, which is itself informative.
• Do not read week-on-week ranking noise as signal. Position for a single term fluctuates for reasons you cannot see and cannot influence.

An ASO work plan, in the order that actually works

Sequence matters more than speed here, because several of these steps depend on the previous one having shipped. Durations depend on your traffic — Apple estimates test length from impression volume, and Play experiments can return “more data needed” — so treat this as an order of operations rather than a calendar.

First, establish the baseline. Export impressions, product page views, downloads and conversion rate for both stores. Check Android vitals against the published thresholds. Read the last hundred reviews on each store and tally the recurring complaints; this is the cheapest product research available to anyone.

Second, fix anything that is suppressing you. If crash or ANR rates are near the thresholds, that work outranks everything in this article. Verify your App Links. Confirm your category is the right one.

Third, rewrite the ranking fields. Apple’s name, subtitle and keyword field; Play’s title and short description. Research terms in the store’s own search suggestions before opening any tool, and write the description for humans in both stores. Ship with your next release.

Fourth, rebuild the first three screenshots. Not all ten. Establish the argument, then test it.

Fifth, start one experiment. Icon first if it is weak, first screenshot otherwise. One variable. Let it run to a result.

Sixth, localise your top two markets properly. Ranking fields researched in-language, screenshots redrawn.

Seventh, put the rating prompt in the right place — after a success moment, within the rules above — and set up a rota for replying to reviews.

Then repeat from step three. ASO is not a project with an end. Competitors change their listings, the stores change their surfaces, and your app changes what it is for.

Much of this is genuinely doable in-house, and if you have a designer, a native speaker in each priority market and someone who reads the vitals dashboard, you should do it in-house. Where outside help earns its place is in the parts that need volume and judgement at once: keyword research across many markets, running a disciplined test programme without stopping tests early, and sitting between marketing and engineering when the answer to a growth problem turns out to be a crash rate. That is what our app store optimization work involves, and it sits alongside mobile app development and digital marketing rather than replacing either. If you are still choosing a technical direction for the app itself, the framework comparison covers the store-level constraints that decision carries, and the pre-launch checklist covers what to have in place before any of this matters.