App Store Optimization for First-Time Founders

The app is live. Review cleared, the listing is up, the icon looks right on a phone. Nine days later the install counter has barely moved, and the only advice anyone gives you is a phrase you had not heard before you shipped.

App store optimization is the work of making a listing match what people type and giving each store the signals it says it reads. Four listing fields and your app’s ratings are inputs this guide can act on. None of it outranks a crash: Google Play publishes a 1.09% user-perceived crash rate as the point where it may reduce a title’s visibility.

Start with the part the guides skip. Your listing fields are a build artifact. They ship with the app, they are typed once into a console in the last ten minutes before you hit submit, and after that most founders never look at them again. Getting the app published in the first place is a separate job with its own sequence, and this page starts where that one ends.

This page was written from Apple’s and Google’s developer documentation, all of it read 16 August 2026; every load-bearing sentence links to the page it came from. No console was opened and no app was submitted to write it.

What app store optimization actually is, in plain English

App store optimization, usually shortened to ASO, has two jobs and no more. Job one is being findable when somebody searches the store. Job two is being picked once they land on your product page. Everything sold under the name is a way of doing one of those two things.

The findable half runs on what the stores index: your text, your category, and how people have behaved toward your app so far. The picked half runs on what a stranger sees in the two seconds before they scroll: your icon, your first screenshots, your star rating. Both stores describe these inputs openly. Neither one publishes how they are weighted against each other, and as of 16 August 2026 that has not changed. Anyone who tells you a category is worth more than a subtitle is guessing at a number Apple and Google have not printed.

That matters more than it sounds, because it sets the honest ceiling on ASO strategy. You can do everything the documentation says and still not know why you rank where you rank. What you can know is which inputs exist, and which of them you are able to touch. The priority order below is this guide’s editorial sequence for a first pass, not a weighting published by either store.

App store ranking factors, in Apple’s and Google’s own words

Both stores publish their ranking inputs in plain sentences. Apple names text relevance and user behavior. Google names ratings, reviews and downloads. Sort those inputs by who can change them and the list splits cleanly in two: the ones you type into a console, and the ones that need somebody to change the app.

Apple’s search page is direct about the text half: “Search results are based on a number of factors, including text relevance (matches for your app’s title, subtitle, keywords, and primary category), as well as user behavior (downloads, ratings and reviews, and more).” (Apple on App Store search, read 2026-08-16.) The same page adds that “Your primary category and optional secondary category are indexed by our search algorithm”, which makes the category choice a search field rather than a filing decision.

Google says less, and is blunter about the limits of what it will tell you. Its discovery help page says “Apps are ranked based on a combination of ratings, reviews, downloads, and other factors”, and that “the details of these weights and values are a proprietary part of the Google search algorithm”. It also says “Google Play search factors in the overall experience of your app based on user behavior and feedback” (Get discovered on Google Play search, read 2026-08-16). Ranking in the app store, on either platform, comes down to a behavior score wrapped around a text match.

Here is what that means for who does the work:

The four rows you control by typing are the rows every ASO guide is about. They are easy to change, but neither store publishes their relative weight against ratings, downloads, behavior, or reliability. What to actually write in each of those fields, and how much room each one gives you, is its own job and a different page. The same goes for images: the sizes and formats each store demands are a separate checklist, and getting them wrong stops a submission rather than a ranking.

One warning on the keyword field belongs here and nowhere else, because it is the only ranking decision that can get an app thrown out. Apple writes: “Improper use of keywords is a common reason for App Store rejections.” The four things it tells you not to include are unauthorized use of trademarked terms and celebrity names, terms that are not relevant to the app, competing app names, and inappropriate or objectionable terms. Padding the field with a competitor’s name is an ASO tactic in some blog posts and a reason your app comes back rejected in Apple’s own documentation. Apple also notes that promotional text “doesn’t affect your app’s search ranking so it should not be used to display keywords” (Apple on the product page, read 2026-08-16).

The app store review popup is code, and both stores police it

The app store review popup is a call your app’s code makes at a moment the code decides. No console setting turns it on. Apple caps it at three appearances per user per 365 days, Google enforces a quota it refuses to publish, and both stores have written rules for when it may fire.

Start with the cap, because it is the number that reframes the whole thing. Apple’s StoreKit documentation says: “Be aware that the system displays the review prompt to a user a maximum of three times within a 365-day period.” That is three prompts for a whole year, across every version you ship. Apple’s ratings page states the same limit from the other side: “You can prompt for ratings up to three times in a 365-day period” (Apple on ratings and reviews, read 2026-08-16).

Then the rules about firing it. Apple’s best-practice list rules out the thing a founder’s instinct suggests. “Avoid requesting a review as the result of a user action.” “Avoid showing a request for a review immediately when a user launches your app, even if it isn’t the first time it launches.” And the line that closes the argument: “Also, remember that people can disable requests for reviews from ever appearing on their device.” (Requesting App Store reviews, read 2026-08-16.) You can write the code perfectly and still show nothing, to a user who turned it off months ago in Settings.

The current API on Apple’s side is RequestReviewAction, reached through the requestReview environment value, available from iOS, iPadOS and Mac Catalyst 16.0 and macOS 13.0. Apple’s sample reads it in one line:

@Environment(\.requestReview) private var requestReview

If your app was built a while ago it may still call SKStoreReviewController, which Apple marks deprecated as of iOS 18.0 and points at RequestReviewAction instead (SKStoreReviewController, read 2026-08-16). Apple also documents a route for a real button: its sample code “uses a deep link to the App Store page for the app with the query parameter action=write-review appended to the URL”.

Google’s In-App Review API works the same way and is stricter about presentation. Play “enforces a time-bound quota on how often a user can be shown the review dialog”, so calling launchReviewFlow more than once in a short period “might not always display a dialog”. Google then removes any temptation to reverse-engineer that number: “The specific value of the quota is an implementation detail, and it can be changed by Google Play without any notice.” On design, Google says “you should not have a call-to-action option (such as a button) to trigger the API”, that your app “shouldn’t ask the user any questions before or while presenting the rating button or card”, and that you must “Surface the card as-is, without tampering or modifying the existing design in any way, including size, opacity, shape, or other properties” (Google Play In-App Review API, last updated 2026-01-30, read 2026-08-16).

None of that is listing work. If somebody else wrote your app, asking for more reviews is a request to whoever maintains the code, and a wrong implementation of it breaks a published rule on both stores. Most of the ratings half of ASO has that shape.

App Store star ratings, and the reset most founders miss

Star ratings feed ranking on both stores, and Apple gives you one lever on them that almost nobody uses. You can reset your summary rating when you ship a new version, across all countries and regions at once, without deleting the reviews people wrote. Apple recommends using it sparingly, and the reason is arithmetic rather than policy.

Apple’s search page is explicit that this is a ranking input: “Ratings and reviews appear on your product page and in search results, and can influence how your app ranks in App Store search.” Google’s discovery page names ratings among the factors its search combines. Whatever else you do to a listing, the number under the icon is being read by both algorithms and by every human who lands on the page.

The displayed rating is specific to each territory. The reset is not: Apple says one reset applies to all countries and regions. Apple’s own caution is that it recommends “using this feature sparingly”, because a page with very few ratings can put people off as effectively as a low average. And the part founders assume wrongly: “If you choose to reset your summary rating, past reviews will continue to display on the product page.” The average clears. The one-star write-up about the crash on launch day does not.

One more line on the same page describes something worth doing on a Tuesday afternoon: “When you respond, the reviewer is notified and has the option to update their review.” A reply is the only mechanism either store gives you for turning an existing bad rating into a better one.

So a rough launch leaves a rating you can still move. The reset only earns its keep once the thing people rated badly has actually been fixed, which is the whole subject of the next section.

App store optimization cannot fix an app that crashes

Google publishes numeric thresholds for bad app behavior and says exceeding them may cost you store visibility. The overall user-perceived crash rate threshold is 1.09%. Cross it and your keyword work stops being the thing holding downloads back, because Play may already be showing your listing to fewer people.

Google’s vitals documentation states it plainly. “Your app’s core vitals affect your app’s visibility on Google Play.” And: “If your app or game exceeds a bad behavior threshold, Play may reduce the visibility of your title. Play may also show users a warning on your store listing.” (Android vitals, last updated 2026-05-19, read 2026-08-16.) These are the published numbers on that page today:

Google publishes a separate per-watch-model column alongside these for Wear apps. ANR stands for Application Not Responding: the app is still running and has stopped answering, which users report as freezing rather than crashing.

Now put those numbers next to the ranking inputs from earlier and follow one bug through the system.

One crash costs you the install, then the one-star review, then the average rating that feeds ranking, then the store’s own decision to show your listing less. Three penalties and a demotion, from a single bug.

That loop is why this guide puts crash diagnosis before listing edits. Ratings are a published ranking input on both stores, and Google says bad core vitals may independently reduce visibility. A founder working on a crash rate above Google’s 1.09% threshold is addressing a documented app-health risk before an input whose relative weight is unpublished.

Apple publishes no equivalent numeric threshold. As of 16 August 2026 there is no Apple page stating a crash rate at which App Store visibility is reduced, and that absence should be read as an absence rather than as permission. Apple’s ranking inputs include ratings and reviews, and a crashing app collects both.

Finding out whether you have this problem is a different skill from listing work, and reading a real crash report beats guessing at it from review text. If the wider question is whether the app holds up at all once strangers use it, the readiness gates cover whether the app is actually ready for people who are not you, and the release-versus-preview split behind a lot of these reports is the same one that makes an app work on your machine and fail everywhere else.

What about app store optimization tools?

App store optimization tools do keyword research, rank tracking and competitor listing analysis, priced for teams running a portfolio of apps. For one app with almost no download history, they measure signals you do not have yet. None of them can change your app, which is where most of your ranking problem lives.

The category is real and the products work. Tools like apptweak.com, appradar.com and sensortower.com estimate search volumes on store queries, track where a listing sits over time, and show what other apps put in their fields. None of them is linked here, because this page names the category to answer the question and stops there rather than sending you shopping. Nothing any of them reports is itself a ranking factor. They estimate the inputs and watch the outputs, which is genuinely useful once you have enough downloads for the outputs to move. In the first weeks, with barely any installs, a rank tracker mostly confirms that you are not ranking.

An app store optimization checklist, in the order that matters

The order below is this guide’s risk-control sequence: address a documented visibility threshold first, then work through the remaining published inputs. It is not a platform-published weighting.

1. 01 Check whether real users are crashing. Open Android vitals for your app in Play Console and compare your user-perceived crash rate and ANR rate against the 1.09% and 0.47% thresholds Google publishes. On iOS, check the crash data in App Store Connect.
2. 02 Fix what is crashing, before touching a single listing field. Everything below is worth less while a store is reducing your visibility for it.
3. 03 Get the review prompt implemented to the rules both stores publish: no button, no leading question, no firing on launch, and a genuine moment of success as the trigger. This is a change inside the app, so it goes to whoever maintains the code.
4. 04 Set your primary category deliberately. Apple states outright that it is indexed by the search algorithm, and it is the one field that takes ten seconds and is almost never revisited.
5. 05 Write the four text fields for what people actually type, not for how you describe the product internally. Keep competitor names and irrelevant terms out of the keyword field.
6. 06 Replace the first three screenshots. Apple shows the first one to three in search results when there is no app preview, so they are doing search work as well as product-page work.
7. 07 Reply to every review, especially the bad ones. Apple notifies the reviewer and lets them update their review, which is the only route either store gives you from a one-star to a better one.

For an app that launched last week, steps one and two come first here because Google documents visibility consequences for bad core vitals. Steps four through six are the listing work called ASO, and they remain worth doing even though neither store publishes their relative impact. The whole launch sequence, including what to do in the week before you submit, is a longer calendar than this page covers.

Common questions about app store optimization

What is app store optimization in simple terms?

App store optimization is making your app easier to find in a store’s search and easier to choose once found. In practice it means the text fields the store indexes, your category, your screenshots, and your ratings. Both Apple and Google publish which of these they read.

How long does app store optimization take to show results?

Neither store publishes a timeframe, so treat any specific number you read as an estimate rather than a documented fact. One piece is documented: Apple says promotional text can be updated at any time without having to submit a new version, so that field changes the moment you save it. Ratings and downloads, which both stores name as inputs, only move as fast as your users do.

Can I change my app name after launch?

The part that belongs here is that your app name is a ranking input, since Apple counts the title as text relevance, so changing it changes what you match on and gives up whatever recognition the old name had earned. What each store allows you to change, when the change takes effect, and how long the field can be all belong on the listing page rather than here.

Is app store optimization the same as SEO?

No. Both are search work, but a store search runs on a fixed set of fields you submit plus your app’s behavior data, with no links, no page authority, and no crawler. There is also no equivalent of a website you can publish a hundred pages on. You get one listing.

How many times can the app store review popup appear?

On iOS, at most three times per user in a 365-day period, and only if that person has not disabled review requests on their device. On Android, Google enforces a time-bound quota it deliberately does not publish, and says the value can change without notice.

Do age ratings affect app store ranking?

Age ratings and star ratings are two different things that share a word. Age or content ratings come from the questionnaire you fill in at submission and control who can see and download the app. Star ratings are what users leave, and those are the ones both stores name as a ranking input.

Does AxonBuild do ASO?

No. AxonBuild works on the code: fixing something that is broken, finishing something that is stuck, or making one risky part of a working app safe. The listing, the keywords and the screenshots stay with you, and most of what this page recommends first is code work rather than marketing work anyway.