App Store Algorithm: What We Know About How Apps Rank

Apple does not publish a formula for App Store ranking. It does publish the kinds of evidence search considers: text relevance, category, and customer behaviour. The useful work is understanding those signals without inventing a precise weighting.

The phrase “App Store algorithm” suggests a hidden equation waiting to be decoded. That is the wrong mental model. Apple changes its discovery experience, does not publish fixed weights, and personalises some results. There is no responsible way to claim that a subtitle is worth a certain number of installs or that a rating increase guarantees a specific rank. What developers can do is work from Apple’s public guidance, observe live result pages, run controlled listing changes, and distinguish a documented signal from an attractive story.

What Apple says publicly

Apple’s App Store search guidance says search results are based on several factors, including text relevance—matches for an app’s title, subtitle, keywords, and primary category—and user behaviour, including downloads, ratings, reviews, and more. Apple also says it is constantly evolving search to provide better results. That is the foundation. Search must first understand whether an app is relevant to the query; then it has reasons to prefer results customers are likely to value.

That wording matters because it rules out two common myths. Metadata alone is not the whole algorithm: a perfectly phrased title cannot indefinitely compensate for a product people avoid. But downloads alone are not the whole algorithm either: a famous app is not automatically the best textual answer to every specialised query. Ranking is a matching problem and a customer-outcome problem at the same time. The exact balance changes by query, storefront, and time.

Text relevance: the part you can edit directly

The clearest editable signals are the app name, subtitle, keyword field, and primary category. Apple limits the name and subtitle to 30 characters each and the keyword field to 100 characters. Those constraints are useful because they force a product team to decide what the app should be found for. Start with accuracy. A query should lead to an app that can perform the task implied by the query, not merely an app that can borrow the words. Misleading metadata can produce a click, but it damages conversion and trust.

Apple advises developers to choose keywords that match the words people use to find an app like theirs, to be specific about features and functionality, and not to repeat terms already used in name, subtitle, or category. It also advises avoiding broad generic words, filler words, and redundant plurals. These are not clever hacks. They are information-design rules. A small metadata budget should describe more genuine concepts, not repeat one concept in different punctuation.

Primary category is part of that relevance story. It helps users browse and filter, and Apple says the primary and optional secondary categories are indexed. Choose the category that best describes the product rather than the one that feels least competitive. A category mismatch creates the same problem as a keyword mismatch: it brings the wrong expectation to the page. It may also create review and policy risk.

Customer behaviour: evidence that the result helped

Apple specifically names downloads, ratings, and reviews as customer-behaviour factors. The sensible interpretation is not that every download has equal value or that a team should chase ratings at any cost. It is that the store has feedback about whether people who see an app choose it and whether they are satisfied enough to recommend it. An app that is relevant in text but consistently disappointing in use is a less useful search result than one that keeps its promise.

This is why conversion rate belongs in an ASO dashboard. Search visibility is only the first step. If a metadata change raises impressions but product-page conversion falls, the new wording may be broadening the audience beyond the people your app helps. If conversion rises but ratings fall after install, screenshots or onboarding may be making a promise the product does not fulfil. The listing and the product should be treated as one system, with the most useful metrics read together rather than in isolation.

Why position moves without a listing change

A rank is a relative result. Your app can move because a competitor changes its metadata, launches a campaign, receives reviews, updates its product, enters a new country, or gains visibility from an event or editorial surface. Search itself can change as Apple experiments with layouts and relevance. Results can vary by storefront and context. So a change in position is not automatically proof that your last edit worked—or that it failed. It is an observation that needs a timeline.

This is the reason to keep dated snapshots. Record the query, storefront, result page, your position, nearby competitors, rating counts where visible, and your own listing version. Record internal changes alongside it: metadata release, screenshots, paywall, onboarding, acquisition campaign, or app update. Over several checks, patterns become more useful. A one-day move may be noise. A repeated improvement after a focused subtitle change, while similar terms also improve, is a stronger hypothesis.

Relevance has more than one surface

App Store search is no longer only a row of app icons. Apple notes that search results can include developer cards, in-app purchases, in-app events, custom product pages, categories, editorial content, and Apple Ads. Ratings and up to three screenshots or app previews may display depending on platform and orientation. App tags can also help customers understand an app’s qualities. A team that only edits a keyword field is ignoring the surfaces that determine whether a search impression becomes a visit and an install.

Custom product pages are particularly useful when an app serves more than one legitimate audience or job. Apple allows developers to assign keywords to individual custom product pages so that a searcher can reach a more relevant variant. The standard is still relevance. A page associated with “invoice scanner” should demonstrate scanning and invoicing in its first asset, not route customers into a generic productivity tour. Matching the landing experience to query intent can improve conversion without making one public subtitle attempt to say everything.

What the algorithm does not reward

There is no durable advantage in keyword stuffing, duplicating terms, using competitors’ brands, inserting irrelevant superlatives, or promising features the app does not have. At best, these tactics waste character space and lower clarity. At worst, they violate App Review rules or bring customers who immediately leave. Apple’s guidance explicitly says not to use other app names, company names, or trademarked terms without authorisation, and it warns against misleading metadata. A rank gained through confusion is not a growth strategy.

There is also no reliable public “search volume” number for App Store queries. Tools may provide estimates or proxies, which can be useful for comparing ideas if labelled honestly, but they are not measurements from Apple’s search logs. Treat an impressive number as a hypothesis to investigate. Inspect the live results, verify product fit, watch your own impressions after publishing, and avoid treating a modelled figure as a guarantee of demand.

How to make better ranking decisions

Use a three-part decision rule. First: relevance. Can the app genuinely satisfy the query, and can a user see that in the first screenshot and first session? Second: competition. Who currently ranks, what language do they use, and are they strong matches or merely adjacent products? Third: evidence. Can you measure a listing change against a baseline in the relevant storefront? A query that passes all three tests is worth investing in. A query that fails relevance should be removed even if it appears easy.

Then choose a field deliberately. Put essential brand-and-category language in the name. Put the strongest customer-facing differentiator in the subtitle. Use the keyword field for supporting concepts that do not need to be visible. Use screenshots to prove the promise. Use custom product pages when one app has distinct, real use cases that deserve distinct landing experiences. Finally, do not ship every hypothesis in one release. A controlled change gives you a chance to learn; a full rewrite gives you only a new starting point.

An evidence-first ranking workflow

The practical conclusion

The App Store algorithm is not a secret lever to pull. It is a system that tries to connect a customer’s query with a relevant, satisfying result. Your leverage comes from making the product easy to understand, using the documented metadata inputs precisely, choosing the correct category, creating a credible product page, and measuring the customer response after every meaningful change. That approach is slower than chasing folklore, but it produces a record you can trust and improve on.

Check a keyword free

Blog · Case studies · Free ASO tools · Products · Privacy and terms · AsoTheory