ASO for Indie Apps: What It Is and How to Set It Up

You search the App Store for something your app does. Your app is not on the first screen. Somebody else’s is, and theirs looks worse than yours.

That is what ASO is supposed to solve. It stands for App Store Optimization, and it is two jobs: getting found, and getting the people who find you to install.

It usually gets explained as “SEO, but for app stores.” That comparison is useful for about one sentence. After that it starts doing damage, because the two stores publish very little about how their search works, and most ASO advice fills the silence with numbers nobody can trace.

Which brings me to the mistake, and I have made it. You read a confident number, build a plan on it, and the number has no source. Title is the strongest signal. Subtitle is second. Video lifts conversion. I have repeated at least one of those in a client deck.

So this one is written the boring way. What Apple and Google actually say, in their own documentation. What my own tests actually measured. And where the honest answer is that no source exists.

What you get: the two numbers Apple publishes and the zero Google publishes. The four field limits you can rely on. The Google Play crash cut-off almost nobody writes about. And four of my own product-page tests, every frame change described.

Why it matters, with the only numbers the stores publish

Apple puts two figures on its own advertising page: 70% of App Store visitors use search to discover apps, and almost 65% of downloads happen directly after a search. The footnote scopes both to the App Store, worldwide, 2022.

Google publishes no equivalent figure for Google Play.

So the honest version of “most downloads come from search” is narrower than the one you usually read. Apple says it, about Apple’s store, using 2022 data, on a page that sells search ads. Directional, not a law, and still the best number in the room.

The two halves

Visibility is whether you appear when somebody searches, and that is the job of the text fields. Conversion is whether the people who land on your page install, and that is the job of the screenshots, the icon and the first line of the description.

Ranking first for a term you do not convert on is a slow way to feed your competitors. Conversion is also the half I can measure, so it is the half of this article that can prove anything.

What the stores say they use

Apple’s page on App Store search says results are based on two things:

“text relevance (matches for your app’s title, subtitle, keywords, and primary category)” and “user behavior (downloads, ratings and reviews, and more).”

It adds that ratings and reviews “can influence how your app ranks in App Store search.”

Google’s Play Console help says Play search “takes multiple factors into account, such as app titles, developer names, and app descriptions”, and that apps are “ranked based on a combination of ratings, reviews, downloads, and other factors”. It then says plainly that the weights are proprietary.

Notice what is missing from both. Neither company publishes an order of importance.

If you have read that the title is the strongest ranking signal and the subtitle is second, so have I. In about a hundred blog posts. Not one of us has a source for it.

I still write titles as if it were true, because the field is short, specific, and the first thing a human reads. That is my working assumption, not a ranking factor.

The fields, and what they actually allow

These are the published limits, not opinions. They are the part of ASO you can be certain about.

Two rules in that table are Apple’s own words rather than folklore, and both are worth having. Apple tells you not to duplicate your app name or company name inside the keyword field. And Apple tells you: “Don’t add unnecessary keywords to your description in an attempt to improve search results.”

The one real difference between the two stores

Google names app descriptions among the things Play search takes into account. Apple does not. Its list is title, subtitle, keywords and primary category, and Apple separately tells you not to stuff the description.

Practically: write the App Store description for a human being. Write the Play description for a human being who is also being read by a machine.

What does not follow is a keyword density target. You will see 2–3% quoted everywhere. I have quoted it myself, in an earlier version of this article.

It appears in no Google document I can find, and Google’s own store listing guidance points the other way. Give an overview “using everyday language, not a list of keywords”. It names repetitive keyword blocks as a content policy problem, not a tactic.

Put your terms in because they belong in the sentence. Do not write to a percentage.

Technical quality is a published ranking factor on Google Play

This is the one off-metadata factor that comes with real numbers attached, and almost nobody writing about ASO mentions it.

Google publishes bad-behaviour thresholds in Android vitals. An app crosses the overall threshold when at least 1.09% of daily active users hit a user-perceived crash, or at least 0.47% hit a user-perceived ANR (Application Not Responding). There is a per-device threshold too, at 8% of daily active users on a single device model.

Cross the overall cut-off and Google says your app “is likely to be less discoverable on all devices”. Cross it on particular devices and it is less discoverable on those, with a warning shown on your store listing.

Apple publishes no equivalent public threshold. If you ship on Android, this is the ASO task that lives in your bug tracker rather than in App Store Connect.

Setting it up

Knowing what ASO is does not tell you what to do on Monday. This is the sequence I run for a launch, spread over about three weeks so it fits around building the app. The timings are mine, not a store’s.

Week 1, find the words

Start with 20 to 30 seed terms, then read reviews. Daphne Tideman, in How to Make an App People Will Pay For, recommends mining them, competitors’ included.

Her reason is that users describe their situation and the outcome they wanted in their own words. Those words beat the ones you invented at your desk.

Sort the candidates on volume, difficulty and relevance, and take the long tail. “Budget tracker for couples” is winnable. “Budget app” is not.

Week 2, write the metadata

Title: primary term plus your brand, inside 30 characters. Subtitle (iOS): a second term or the value proposition, and no words repeated from the title. Keyword field (iOS): fill it, comma-separated, no spaces, no duplicates of anything already in the name.

Description: the first sentence is the only one visible before somebody taps “more,” so put the problem and the answer in it. 4,000 characters is the ceiling, not the target.

Week 3, the visual half

Screenshots are where indie apps underinvest, and they are the half of ASO I can put numbers on. Five to eight frames, the first three carrying the story, and real UI populated with real-looking data, which Apple’s guideline 2.3.3 requires rather than suggests. One set for both stores to start with. The full version of this, with six before-and-after sets, is its own article.

The icon has to survive being small. That means simple and distinctive, and it usually means no text.

App previews autoplay on your product page and in search results, which is the reason to make one.

But I have not measured what a preview does to installs, and I have not found anybody who has. So treat “video lifts conversion” as a hypothesis worth testing, not a fact worth budgeting against.

The half of this I can actually prove

Everything above about ranking is other people’s documentation. The conversion half is mine: App Store Connect product page optimisation tests, where the old set and the new set go out to live traffic side by side and the store decides.

I have run those on six client sets, and the whole teardown, frame by frame, is on its own page: App Store screenshots, what to show. The short version is that the same two things changed every time. Captions went from naming a feature to naming an outcome, and the first frame stopped being a phone.

It is the half of ASO with the least folklore attached to it, because you can test it and watch the store decide.

In-app events and promotional content

Both stores have a surface most indie apps never touch: a card promoting something happening inside the app, a content drop, a challenge, a seasonal feature, a major update.

On the App Store, Apple says in-app events turn up in three places. Your product page. Search results, where

“the event card appears along with your app for users who have downloaded your app, while screenshots show for those who haven’t”.

And in editorially curated selections and personalised recommendations on the Today, Games and Apps tabs.

Apple also says users can search for events directly, which is the basis for treating event copy as searchable text. It is not the same as Apple saying event text is indexed into your app’s own keyword pool, and I would not claim that it is.

The published App Store specs:

• Seven badge types: Premiere, Challenge, Competition, Live Event, Special Event, New Season, Major Update
• Event name 30 characters, short description 50, long description 120
• Maximum duration 31 days, promotable up to 14 days before the start date
• Event card image 16:9, minimum 1920×1080px, maximum 3840×2160px. Apple’s guidance is to “avoid using text or logos in your media” where possible, guidance, not a rejection rule
• Since October 2025 you can submit events for review separately, even with an app version already under review

Google Play’s equivalent is Promotional Content, covering offers, time-limited events and major updates. It appears on your store listing and may appear elsewhere on Play, including the homepage and search.

The rules: four weeks maximum, previewable on Play for up to 14 days before it starts, submittable from 60 days out, and approval takes up to four days.

On results, Google claims that submitting promotional content and requesting featuring can produce “over twice as many explore acquisitions during a featuring window”.

The footnote matters more than the headline. That analysis looked at roughly 6,000 events from over 2,000 titles between November 2023 and January 2024, counting only events that showed a statistically significant uplift. So the losers were left out of the average.

Just over half of the events qualified. So it is the median of the winners, not the median of everyone who tried.

What nobody publishes

A short list, because the gaps are as useful as the facts:

How long changes take to move rankings. I have seen “one to two weeks” asserted everywhere, including in an earlier version of this article. Neither store publishes it. Change one thing, wait, and read your own console.

How much a rating threshold is worth. “Apps above 4.5 stars convert significantly better” is repeated constantly with no traceable source. Ratings are a confirmed ranking and trust factor in both stores’ own words. The conversion number attached to a specific star threshold is not.

Whether retention feeds store ranking. Apple says “user behavior (downloads, ratings and reviews, and more)” and leaves “and more” undefined. On Google Play, technical stability is documented, with the thresholds above. Retention as a ranking input is an inference, not a published factor.

And one thing worth hearing before you spend three weeks on any of this. Tideman’s list of metrics to ignore before product-market fit includes total downloads, total signups and App Store ranking. If people are not coming back on their own yet, better ASO buys you a larger audience for a problem you have not solved. Fix the coming-back part first.

Tools

Prices and plan limits change; these were checked in September 2026.

The two free ones are the two that matter. The consoles hold your own data, which is the only data about your app that is definitely true.