How to Make Your App Rank on the App Store

Getting an app to rank is not one task.

Apple first needs to understand which searches are relevant to your app. Then the person searching needs to choose your result. After the download, the app still has to deliver what the listing promised.

Those are three different problems:

1. Discovery: Does the app appear for relevant searches?
2. Conversion: Do the right people download it after seeing the listing?
3. Product quality: Do those users reach value, stay, and pay?

ASO mainly works on the first two. It can help the third by setting the right expectation, but it cannot fix a weak product.

This distinction matters. If your app gets impressions but few downloads, adding more keywords may not help. If it gets downloads but users leave during onboarding, new screenshots may only send more people into the same problem.

The process below is the one I would use to find the real constraint before changing anything.

Start with a baseline

Do not begin by rewriting the subtitle.

First, save the current state. You need something to compare against after the next release.

For one app, storefront, and date range, record:

Use the same storefront and comparable periods. A global total can hide a good change in one market and a bad change in another.

Also save the actual listing:

• app name and subtitle
• keyword field, if you have access to it
• first three screenshots
• icon
• promotional text and description
• rating and recurring review themes
• version and release date
• Apple Ads campaigns running during the period

App Store Connect separates acquisition metrics and sources, but attribution has limits. Treat the numbers as evidence, not as a complete explanation. Apple explains the available acquisition data here.

Step 1: Pick one user and one problem

Most weak listings start too broad.

“Productivity for everyone” does not tell you which keywords matter, what the first screenshot should say, or which competitors are relevant.

A better starting point is:

This app helps [specific user] do [specific job] when [situation], without [main alternative or frustration].

Here is a hypothetical example:

This app helps students start a 25-minute study session when they are avoiding a difficult task, without configuring a complicated productivity system.

That sentence is not App Store copy. It is a filter for later decisions.

It suggests search language around focus timers, study timers, Pomodoro sessions, and procrastination. It also suggests that the first screenshots should show a fast start and a simple session—not a dashboard full of advanced controls.

If you cannot write this sentence yet, talk to users before doing keyword research. Search data can show that a phrase exists. It cannot decide which person you want to serve.

Step 2: Build a small keyword cluster

Start with the job the user wants done. Do not begin with a list of high-volume words from a tool.

Create four groups:

1. Category terms describe what the product is: focus timer, habit tracker, meal planner.
2. Problem terms describe what the user wants to fix: stop procrastinating, remember medication, plan cheap meals.
3. Outcome terms describe the desired result: study better, sleep earlier, save on groceries.
4. Feature terms describe a capability people may seek: widgets, shared lists, interval timer.

Now remove anything the app does not genuinely satisfy. A keyword is not useful simply because it is popular.

For each remaining term, ask:

• Would I be comfortable showing this user the current product page?
• Does the app solve the intent behind the query, not only contain the word?
• Which apps already appear, and are they realistic competitors?
• Can the listing make a more specific promise than those results?
• Is this term important enough to occupy limited metadata space?

Use tools to compare popularity and competition, but keep those scores in context. They are inputs, not a verdict. A relevant smaller query can be more useful than a broad query that attracts people looking for another kind of app.

The detailed field-by-field process belongs in the App Store keyword research guide. For this first pass, choose one coherent cluster rather than trying to cover the whole market.

Before mapping metadata: choose competitors that matter

The category chart is not your competitor list.

A useful competitor is an app the same user might choose for the same job. A large category leader can show established design conventions, but it may target another audience, rely on a much larger brand, or buy traffic you cannot see from the listing alone.

Start with three types:

• one app with a similar product and audience
• one established option a user already knows
• one app that solves the same problem in a different way

Then compare more than keywords:

• the promise in the app name and subtitle
• the user addressed by the first screenshots
• recurring positive and negative review themes
• pricing and trial expectations
• custom product pages and paid-search variations you can observe
• localization depth
• how often the product and listing change

The goal is not to copy the winner. It is to find the convention users expect, the gaps competitors leave open, and the claims you can support better.

This is also where trend context matters. A competitor with a polished listing but declining traction may be a weaker model than a smaller app whose audience and reviews are moving in the right direction. Third-party download and revenue estimates can help form a hypothesis, but label them as estimates and confirm important decisions with your own data.

Use the competitor-analysis framework to turn observations into tests instead of a screenshot mood board.

Step 3: Map the cluster to the listing

Apple currently describes App Store search as a mix of text relevance and user behavior. Text relevance includes the app name, subtitle, keywords, and primary category. Behavior includes downloads, ratings, reviews, and other signals. Apple does not publish the weight of each factor, so treat this as a map of surfaces to improve—not a ranking formula. Apple's current search overview is the source for that public description.

The app name, subtitle, private keyword field, categories, and newer App Tags have different jobs.

The name and subtitle are visible. They need to help both discovery and the person scanning the search result. The private keyword field is not public, so it can cover relevant terms without turning the visible copy into a list.

I would check the fields in this order:

App name

Can a new user understand the category or purpose without already knowing the brand?

A known brand can rely more heavily on recognition. A new app usually cannot. That does not mean stuffing several synonyms after the brand. It means using the remaining space to add one useful piece of context.

Subtitle

Does it add a user, outcome, or differentiator that the name does not already contain?

“Focus timer for studying” adds more information than repeating “focus and productivity timer.” Repetition consumes space and makes the result harder to read.

Keyword field

Does it cover the remaining relevant terms without obvious waste?

The private field cannot be retrieved from a normal public App Store lookup. If an audit claims to know it without developer input or authorized App Store Connect access, ask where the data came from.

After mapping the fields, read the visible result as a sentence. If it sounds like a keyword list, it probably needs another pass.

Primary and secondary categories

Choose the categories that most accurately describe the app.

Apple currently says both the primary and optional secondary category are indexed by search. The primary category also affects browsing, filters, and where the app appears across the store. Do not choose an inaccurate category because it looks less competitive. It can confuse users and is grounds for App Review rejection.

App Tags in the United States

App Tags are another discovery surface to inspect in the U.S. storefront.

Apple generates tags from the metadata in App Store Connect using large language models and human curation. Selected tags can appear in search results and on the product page, and users can open a tag to see related apps. Account holders and users with the relevant App Store Connect role can review the selected tags and deselect ones that do not fit.

Tags do not replace the keyword field. Use them as a check on whether the metadata describes the product clearly. If the selected tags misunderstand the app, first inspect the name, subtitle, description, keywords, and category that informed them. Do not keep an irrelevant tag merely because it may create more exposure. Apple currently limits App Tags to the United States and documents how to review them here.

Promotional text

Use promotional text for timely information and conversion, not keyword coverage. Apple states that promotional text does not affect App Store search ranking.

Step 4: Make the first screenshots continue the promise

Ranking for the right query is only useful if the result earns a qualified download.

Look at the first three screenshots at the size a person actually sees on the App Store. Do not zoom into the design file yet.

Give each screenshot one job:

1. Recognition: “This is for my problem.”
2. Mechanism: “I understand how it helps.”
3. Reason to believe: “This looks useful and credible enough to try.”

Return to the hypothetical study timer.

A weak sequence might say:

• Boost your productivity
• Powerful focus tools
• See your statistics

The words are not false, but almost any productivity app could use them.

A clearer sequence might say:

• Start a 25-minute study session
• Block one task until the timer ends
• See which days you actually focused

This version is narrower. That is the point. It gives the intended user something concrete to recognize.

The interface should support the caption. If the screenshot says “start in one tap” but shows a complex setup screen, the image weakens the claim.

Before running a live test, show the first three frames to someone unfamiliar with the app for a few seconds. Ask what the app does and who it is for. Do not explain the answer. Their confusion is useful evidence.

Do not turn the screenshots into keyword containers. Appfigures has reported that Apple may read screenshot captions as a search signal, but Apple does not currently include screenshot text in its public list of text-relevance factors. Use relevant words because they help the intended user understand the page. If you test a possible ranking effect, keep a baseline and treat the result as app-specific evidence rather than a rule.

The App Store screenshot guide turns that evidence into captions, a storyboard, and one testable revision.

Step 5: Check the rest of the buying decision

Screenshots do not work alone.

Review the elements that can create doubt:

• Does the icon look credible next to direct alternatives?
• Is the rating strong enough to support the promise?
• Do recent reviews mention a problem the listing ignores?
• Is the subscription or price expectation clear?
• Does the description explain the product before listing every feature?
• Do the screenshots match the current app?
• Are privacy-sensitive features explained plainly?

Reviews are especially useful because they contain the language of real expectations. Group recurring comments into four buckets:

1. why people chose the app
2. what they value after using it
3. what they expected but could not find
4. what made them stop trusting or using it

Do not paste review phrases into metadata merely to add keywords. Use them to understand the gap between the promise and the product.

Step 6: Localize the intent, not only the words

Do not expand to ten countries because a localization tool makes it easy.

Pick the next market using evidence:

• existing downloads or revenue
• user requests
• a strong category opportunity
• language support in the product
• support and pricing readiness
• enough traffic to learn from the change

Then repeat the positioning work for that storefront.

A direct translation may be grammatically correct and still miss the search language people use. Competitors can also be different. So can price sensitivity, screenshot conventions, and trust concerns.

The App Store localization guide covers the full workflow. The important rule here is simple: keep markets separate in your baseline. Otherwise you will not know where the change helped.

Step 7: Use Apple Ads to test intent

Apple Ads—previously known as Apple Search Ads—can provide faster feedback than waiting for organic positions to move.

Start small. The first campaign should make the learning understandable, not try to scale immediately.

For a first search-results campaign:

1. choose one country or a small group of genuinely similar markets
2. define the monthly amount you are prepared to spend on learning
3. choose whether you want Apple's Maximize Conversions strategy or manual control with Manage Bids
4. start with a short list of highly relevant terms
5. inspect the actual search terms
6. add irrelevant or poorly performing terms as negatives when appropriate
7. move useful discovery terms into a controlled keyword group
8. compare installs with activation and revenue, not only taps

Apple currently defines the monthly budget ceiling from the daily budget multiplied by 30.4. Spend can exceed the daily amount on individual days, so set the number with the full month in mind. Apple documents the current setup and budget behavior here.

Do not apply a blanket rule to Search Match. It is required for Maximize Conversions, and it can be useful for discovery. If you use it, separate discovery from controlled keywords so you can see what it found and prevent the same exact terms from being mixed across groups. Apple's campaign-structure guide shows one way to do this.

Paid data can improve the organic plan. A query that produces relevant, activated users deserves more attention in the listing. A popular query that produces poor users may be the wrong intent, even if the cost per install looks attractive.

Use the Apple Ads starter guide for the current campaign setup, match-type decisions, negatives, and first review.

Step 8: Match different intents with custom product pages

One default page cannot always speak clearly to every valid use case.

Apple currently allows up to 70 custom product pages per app. A page can use different screenshots, previews, promotional text, and assigned keywords. It can also have its own URL and localization. Apple's current custom product page documentation is the source of truth for the limits and setup.

That does not mean you need 70 pages.

Create one when all three conditions are true:

1. the audience or use case is meaningfully different
2. the page can make a more specific promise
3. you have enough traffic or distribution to evaluate it

For the study timer, one custom page might focus on exam preparation while another focuses on ADHD-friendly task starts. The screenshots and copy should change because the user's context changes—not because a different background color looked interesting.

Custom product pages can be assigned to keyword sets in organic search and used as Apple Ads variations. They also have unique URLs for external campaigns. Measure downstream behavior where possible. A page with a higher download rate can still be worse if it attracts people who never complete the first useful action.

The custom product pages guide covers the intent map, App Store Connect setup, keyword assignment, ad variation, deep link, and page scorecard.

Step 9: Find the earliest weak stage

After the change has enough time and traffic to evaluate, do not ask only, “Did rankings go up?”

Use the earliest weak stage to decide what to investigate next:

This is where ASO work becomes useful. You are no longer collecting tactics. You are locating the next constraint.

If the weak stage is still unclear, use the ASO diagnosis guide and stop at the first branch supported by evidence.

Step 10: Run one clear learning loop

For each material change, write down:

• the problem you observed
• the evidence behind it
• the change you plan to make
• the metric expected to move
• the metric that must not get materially worse
• the storefront and audience affected
• the date and app version
• what result would prove the idea wrong

Then change the smallest coherent set of elements that can test the idea.

Sometimes that is one screenshot treatment. Sometimes the name, subtitle, and first screenshot need to change together because they express one new position. “Change one thing” should mean one hypothesis, not necessarily one text field.

Apple's Product Page Optimization lets you test the icon, screenshots, and previews against the default product page. Apple currently allows up to three treatments, and a test runs for up to 90 days unless it is stopped earlier. More treatments split the traffic and can take longer to produce a useful result. Apple explains the current test setup here.

The Product Page Optimization guide explains how to choose treatments, read confidence and credible intervals, and avoid calling an early estimate a winner.

Do not declare a winner because the graph moved in the first few days. Also check whether app releases, paid campaigns, featuring, seasonality, or market changes affected the period.

A practical four-week cycle

You do not need to rebuild the whole listing every month.

Week 1: Diagnose

• update the baseline
• choose one storefront
• inspect the earliest weak stage
• write one hypothesis

Week 2: Prepare

• research the relevant query or audience
• create the metadata or creative revision
• record the current listing
• define the decision rule

Week 3: Release or test

• ship the approved change
• confirm that analytics and campaigns still work
• avoid unrelated listing changes
• record external events that may affect the result

Week 4: Read the evidence

• compare the right market and source
• inspect both store conversion and user quality
• keep, revert, or revise the hypothesis
• add the learning to the next baseline

The schedule may need to be longer for low-traffic apps. Waiting is better than pretending that a small number of observations proves something.

What ASO cannot do

ASO can improve relevance, clarity, and conversion. It can help a good app reach people who are already looking for something similar.

It cannot guarantee a rank, download count, revenue increase, or timeline. It cannot create demand for a product nobody wants. It cannot compensate for poor onboarding or retention indefinitely.

Paul Graham makes a related point in How to Earn a Billion Dollars: durable growth comes from making something people genuinely want and recommend. The scale is not the point here. The constraint is. Distribution works better when the product earns the next recommendation.

If the listing is clear but users still leave before reaching value, stop polishing metadata for a moment. Inspect the ASO-to-activation funnel and the onboarding drop-off playbook.

What to do next

Open App Store Connect and choose one app, one storefront, and one comparable date range.

Record impressions, product-page views, first-time downloads, conversion, and the first useful in-app action. Then identify the earliest stage that looks weak.

Do not change anything until you can write this sentence:

I believe [specific problem] is limiting [specific stage] for [specific audience or storefront] because [evidence]. I will test [change] and judge it using [metric and decision rule].

That sentence is a better starting point than another list of ASO tips.

If the app is approaching release rather than already operating, use the 30-day iPhone app launch plan to put the same sequence on a calendar.