How do I make my app show up in search results?

Getting an app to show up in search results is one of those problems that looks simple until you are inside it. The search box exists, users type into it, results appear, and yet a perfectly functional product sits on page three while a weaker competitor holds the top spot. The reason is almost never the product itself. It is the decisions made before a single user ever opened the app: the category chosen, the keywords selected, the screenshots ordered, the copy written.

Over 60% of downloads come from search, making ASO the highest-leverage acquisition channel that consistently attracts too little investment.

App store search is the primary way people find apps. According to AppTweak, over 60% of global app store downloads come from search, making it the highest-leverage acquisition channel available to a product without a major paid budget. And yet the work required to earn those downloads, App Store Optimisation, or ASO, is consistently underinvested in, misunderstood, or treated as a launch-day task rather than an ongoing practice.

This article works through the structural decisions that determine whether your app is discoverable: how the algorithm works, why category choice matters, what your listing has to do before anyone opens the app, and where the strategy breaks down. Some of it is counterintuitive. Some of it requires doing less, not more. All of it applies before you write a word of onboarding copy.

How app stores actually decide what to surface

App stores are search engines with their own ranking logic, and that logic weighs a specific set of signals. On the Apple App Store, the fields that are indexed for search are the app name, subtitle, and keyword field, not the description. The description allows up to 4,000 characters, but according to Foresight Mobile, none of it is indexed. Writing a beautifully keyword-rich description changes nothing about your search rank.

Beyond metadata, the algorithm weighs engagement signals: how often the app is downloaded after appearing in search, how many active users it retains, and what ratings it holds. An app that surfaces but rarely converts is deprioritised over time. An app that converts well and holds a strong rating gets pushed further up. This means discoverability and product quality are linked from the first day of launch.

Category placement adds a third variable. Each category has its own competitive landscape, and ranking first in a quieter category produces more impressions than ranking fifteenth in a crowded one. The algorithm does not reward ambition, it rewards relevance and momentum.

Why your category choice matters more than developers typically realise

Category selection is one of the earliest structural decisions in an app launch, and one of the most consequential. A product that could reasonably sit in two categories faces a real strategic choice, not a cosmetic one. The instinct is usually to go straight for the primary category, the one that best describes the product and carries the most search volume. That instinct is often wrong at launch.

Our view, based on working with products that span multiple lifestyle categories, is to treat launch category as a staging decision. Start in the less competitive category where the product can achieve higher rankings from a standing start. Higher rankings generate more organic impressions, which drive more downloads, which build the usage data and rating volume the algorithm needs to start ranking the product more broadly. Once that traction exists, moving into the primary, more competitive category becomes viable in a way it simply is not from day one.

A search for a keyword like "Running" on the App Store returns a competitiveness index of 94% and over 11,000 results, according to AppFigures. A new fitness app entering that search space cold will not appear in the first pages regardless of how good its metadata is. A new app entering a quieter wellness category and building momentum there first is in a considerably stronger position when it does eventually compete for the bigger terms.

What your App Store listing has to do before anyone opens the app

The listing is not a formality that follows the product. For most users, it is the product's first impression, and it does work the onboarding cannot, because it happens before the download decision is made. The icon, the screenshots, the subtitle, and the first few lines of copy all answer a single question the user is asking: is this for me?

We worked on a gifting and wishlist platform where the client was reluctant to invest time in the App Store listing, trusting that word-of-mouth referral from the product's social mechanics would carry acquisition. Our position was that ASO is not optional even for inherently social products. The listing needs to allow users to self-select in or out before downloading, because a user who downloads and then realises the product does not match their expectations is a churned user before they have even given the product a real chance.

A user who downloads and then realises the product does not match expectations is churned before they have given it a real chance.

Screenshots are the highest-attention element after the icon. They are read before the description by most users, and they carry both functional and emotional freight: what the app does, and whether it feels like something worth trusting. The order matters. The first screenshot should answer the "what is this?" question, not showcase a feature the user has no context for yet.

Write your App Store subtitle as a plain-language description of what the app does, not a tagline. Users scan subtitles to orient themselves, and a clever phrase tells them nothing useful.

When an app isn't the right answer for discoverability

There are situations where the honest strategic answer is that a native app creates more friction than it resolves, and discoverability through the App Store is the wrong goal entirely. We encountered this directly when working on a surveying tool for performance coaches. The original proposal required audience members to download a native app to submit survey responses during or after a presentation. We pushed back on that.

The download step was too high a barrier for what was, at its core, a simple touchpoint. Instead, we proposed a QR code approach: the coach creates a survey in the native app, a QR code appears on screen, and audience members scan it to reach a fully branded, mobile-responsive web page. No app store. No download. No friction between the prompt and the response. Survey completion rates were significantly higher as a result.

The relevant question for any product is not "should we have an app?" but "what does the user need to do, and what is the lowest-friction path to that action?" Sometimes the answer is a native app with full ASO investment behind it. Sometimes it is a web experience that removes the discovery problem entirely by living inside the channels people are already in.

Before committing to native app development, map the user journey from first awareness to first completed action. If an App Store download sits in the middle of a high-frequency, low-complexity interaction, a responsive web experience will almost always perform better.

What registration walls cost you in organic reach

A registration wall before any value is delivered does two things: it increases drop-off, and it shifts the entire burden of communicating the product's value onto the listing. When a user cannot explore the app before committing to an account, the App Store listing becomes the only place the product can make its case. Every argument for downloading has to be front-loaded into screenshots, copy, and ratings, because nothing inside the app can do that work.

We built an anonymous messaging app that required upfront registration by design, because anonymity with accountability was core to the product mechanic. The consequence was unavoidable: we had to invest considerably more in the out-of-app presence. The App Store screenshots, listing copy, and supporting materials had to communicate everything that would ordinarily unfold through use. The drip-feed of value that a good onboarding provides, showing the user progressively what the product does, was not available to us, so everything had to land before the download.

This is not a reason to avoid registration walls in every case. Some products need them. But teams that require registration upfront without recognising the cost to their listing's persuasive load are underestimating the work that listing has to do, and most are not doing that work.

How your listing copy and screenshots do the job your onboarding cannot

The first three seconds of a user's time inside an app are spent on orientation, working out where they are, what the product does, and what they should do next. If the visual hierarchy does not answer those questions quickly, anxiety builds and users leave. But that orientation challenge is compounded when the listing has not done its pre-work. A user who arrives in an app already understanding what it is, and having chosen to download it on that basis, enters in a fundamentally different psychological state than one who downloaded on vague curiosity.

This is why listing accuracy matters as much as listing quality. Screenshots that show the most visually impressive screens rather than the most representative ones attract downloads from users who then feel misled. Copy that oversells the product's breadth creates expectations the app cannot meet in the first session. Both drive early abandonment, and early abandonment signals to the algorithm that the app is converting poorly, which depresses its ranking.

The listing and the onboarding are one continuous experience. The question the listing answers is "should I download this?" The question onboarding answers is "did I make the right call?" When the listing is accurate, the onboarding has a much easier job. When it is not, no onboarding design recovers the situation.

Test your screenshots with people who have never seen the product. Ask them to describe what the app does after looking at the first three screenshots for five seconds each. If their description does not match yours, the screenshots are not doing their job.

Why referral alone won't carry a product nobody can find

Referral mechanics are a legitimate growth lever for consumer apps, particularly ones built around social behaviour. But referral is amplification, not acquisition. It compounds existing momentum, it does not create it. A product that no one can find through search has no base of users to generate referrals in the first place, and a referral from a friend still leads back to the App Store listing, which still has to convert.

On the gifting and wishlist platform, the client's belief was that because the product was inherently social, designed to be shared between friends and groups, organic word of mouth would handle growth. Our position was that this conflated product mechanic with acquisition strategy. The social mechanic works once users are inside the product and using it. Getting users inside the product in the first place requires the listing to do its job, which means the icon, the category, the keywords, and the screenshots all need to be clear enough that users who encounter the listing through any route, search, referral link, or editorial feature, can immediately understand what they are looking at.

Referral and ASO are not alternatives. The strongest acquisition strategies use both: ASO builds the organic floor, referral builds on top of it. Treating referral as a substitute for search visibility is a structural error that tends to surface six months after launch, when growth plateaus and the team discovers that word of mouth travels further when there is a well-optimised destination to travel to.

How ratings and reviews feed the algorithm, and how you get them honestly

Ratings are both a ranking signal and a conversion signal. The algorithm uses rating volume and recency as indicators of active engagement. Users scanning listings use star averages as a trust proxy before reading a single word of copy. A product with 4.7 stars and 200 reviews has already answered a question most users do not consciously ask: are other people finding this worthwhile?

Getting reviews honestly is partly a timing problem and partly a framing problem. Asking for a review immediately after download, or mid-task, is the wrong moment, the user has not experienced anything worth rating yet, and the interruption creates friction. The right moment is immediately after a completed action that felt successful: a purchase confirmed, a workout logged, a recipe saved. The user is in a positive emotional state and the ask feels proportionate.

Framing changes the response rate considerably. On a travel app we worked on, the original prompt asked users to rate a holiday experience, which users read as doing something for the company. We reframed the copy to ask what they would tell other travellers about the experience. Psychologically, users felt they were helping other people rather than feeding a corporate rating system, and engagement with the prompt increased accordingly. The algorithm does not distinguish between ratings earned through good framing and ratings earned through good product, but your users do, and the honest version produces better quality reviews that carry more weight in search results.

The structural decisions that determine discoverability before a line is written

Most of the decisions that determine whether an app is discoverable are made before the App Store listing is written. They are made in the product brief: what the app is called, what it does, who it is for, and how it is structured. A product name that has no searchable keywords in it starts from a disadvantage that metadata optimisation can only partially address. A product that tries to serve three distinct user types has a category and keyword problem by design.

The structural decisions that most consistently affect discoverability are these:

• App name and subtitle, which carry the most indexing weight of any field
• Primary and secondary category selection, which determines the competitive landscape the app enters
• Whether the product requires native app installation or a responsive web experience is sufficient
• Whether registration is required before value is experienced, which determines how much work the listing must do
• The specificity of the target user, which determines whether keywords can be precise or must remain broad

These are product decisions, made at the same time as every other product decision. A team that makes them without thinking about discoverability will optimise a listing for an app that was structurally difficult to find from the start. A team that folds discoverability into the product conversation from the beginning arrives at launch with most of the hard work already done.

Building a consumer app is a long-term investment. Expecting organic search traction within weeks of launch, on a product that entered a competitive category without a ratings base, is applying the wrong mental model. The compounding logic of ASO, more downloads building more ratings building more ranking building more downloads, takes months to develop, and the structural decisions made before launch determine whether that compounding is working for the product or against it.

Conclusion

Discoverability in the App Store is a chain of decisions, each one affecting the next: the category chosen at launch, the keywords placed in indexed fields, the screenshots that carry the first impression, the rating prompts timed to moments of genuine success, and the structural choice of whether a native app is the right vehicle at all.

What connects all of it is the relationship between the listing and the user's expectations. When the listing accurately represents what the app does and who it is for, the users who download it are already informed. They open the app knowing what they are getting into, and early abandonment drops as a result. When the listing overpromises, or the metadata is optimised for volume rather than fit, the downloads arrive but the engagement does not, and the algorithm responds by ranking the product lower.

The work is specific, iterative, and front-loaded. It happens before the launch, not after it. And it is more intertwined with product decisions than developers expect when they first ask the question: how do I make my app show up in search results?

If you are working through these decisions on a product in development or preparing a launch, let's talk about your app's discoverability strategy.

Frequently Asked Questions