App Store Optimization for Startups: How to Get Your App Found and Chosen on the App Store and Google Play

  1. Blog
  2. Demand & Channels

By Saroj Jha · October 24, 2026 · 24 min read

App Store Optimization (ASO) is two jobs: get your app shown for the right searches, then get the people who see it to download. This page rests on Apple’s and Google’s own documentation, so every limit and rule below can be checked against the page I cite.

Key figures

  • 100 bytes Apple’s keyword field, and it is searched[1]
  • 3 a year most times a user is shown Apple’s review prompt in 365 days[2]
  • 90 days the longest an Apple product page test can run[3]

This guide is for founders and marketers at seed to Series B startups who ship an iPhone or Android app, whether it is the product or a companion to a web product. You will get how each store’s search works as far as the platforms document it, every text field with its current limit, a keyword method based on data you can see, how to test screenshots and read the result, when to ask for ratings, what to measure, and the metadata rules each store publishes.

I give no industry “average conversion rate” or keyword volume figures. Each step shows you how to find your own number from the store’s own reports.

Running case: Example Co. Fictional

Example Co. is a seed-stage EdTech startup with an exam-prep app for nursing students: daily practice questions, flashcards and a study plan that adapts to weak topics. It is free to download with a monthly subscription, ships on iOS and Android, and gets most installs from organic search. The team has one marketer and wants more downloads without more ad spend. All names and numbers in this case are invented.

Step 1: Understand how each store decides what to show

Both the App Store and Google Play say the same broad thing: your text tells the store what the app is about, and user behavior tells it whether people want it.

App Store. Apple says “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)”[4]. Your categories “are indexed by our search algorithm”, but “promotional text doesn’t affect your app’s search ranking so it should not be used to display keywords”[4]. Your app is also searchable by its company name[1]. Browse (the Today, Games and Apps sections) is counted separately in Apple’s analytics[5]. This guide covers search and the product page, the parts the cited pages give rules for.

Google Play. Google says “Apps are ranked based on a combination of ratings, reviews, downloads, and other factors”, that the weights are “a proprietary part of the Google search algorithm”, and that “The text in your store listing helps users discover your app”[6]. Your “app title, icon, and developer name are particularly helpful for users to find and learn about your app”[7]. There is no keyword field: the title and descriptions are the text Google reads.

One detail matters for measurement. Play Console counts a visit as “Google Play search” only when someone searched for “your app’s name or closely associated brand”. A category search such as “racing game”, or a tap on an autocomplete suggestion, counts as “Google Play explore”[8]. So on Android, searches for a category rather than your app’s name or brand appear under explore.

Figure 1 Two jobs on each store: get shown, then get chosen. The two consoles count them differently

App Store Impressions, then product page views, then downloads

  1. Shown Name, subtitle, keywords and category decide the searches you appear in; ratings and downloads count too
  2. Chosen What the searcher sees before tapping: the icon, the first screenshots (Apple shows the first one to three in search results), any preview video and the rating
  3. Measured as Conversion rate: downloads and pre-orders divided by unique device impressions

Google Play Store listing visitors, then install clicks

  1. Shown The title and the short and full descriptions are the text Google reads; ratings, reviews and downloads count too
  2. Chosen What the visitor sees before tapping Install, Open or Pre-register: the icon, screenshots, video and feature graphic
  3. Measured as Click-through rate: clicks on Install, Open or Pre-register divided by listing visitors

Apple search and product page guidance[4],[9]; Apple metric definitions[10]; Google listing guidance[6],[7]; Play Console metric definitions[8]. Apple divides by impressions and Google by listing visitors, so do not compare the two rates.

Example Co., step 1 Fictional

The team had put exam-topic keywords in the iOS promotional text. Apple says that field does not affect ranking[4], so the words move to the keyword field and the promotional text carries a seasonal message instead.

Do this

For each store, list the fields the platform says it reads. Put your search terms only there.

Step 2: Fill every metadata field to its documented limit

Each store gives you a fixed set of text fields with hard limits. These are the limits on Apple’s and Google’s help pages as I checked them on October 24, 2026.

Figure 2 Every text field, its limit, and whether the store says it reads it for search
  • Store Field Limit Read for search? Example Co. (fictional)
  • Apple Name 2 to 30 characters Yes Example Co: Nursing Exam Prep (29)
  • Apple Subtitle 30 characters Yes Daily quizzes & study plans (27)
  • Apple Keywords 100 bytes, comma-separated, each over two characters Yes nurse,pharmacology,flashcards,med surg,pediatric,lpn,practice test,question bank (80 bytes)
  • Apple Promotional text 170 characters; update at any time No A seasonal message, no keywords
  • Apple Description 4,000 characters, plain text Not listed for store search; used for web search results First sentence says what the app does
  • Apple What’s New 4,000 characters; not on a first version Not listed Fixes reviewers asked for
  • Google Title 30 characters Listing text Example Co: Nursing Exam Prep (29)
  • Google Short description 80 characters Listing text Nursing exam practice questions, flashcards and a study plan that adapts to you (79)
  • Google Full description 4,000 characters Listing text First lines name the exam topics people search for

Limits: Apple App Store Connect Help[1],[11] and Google Play Console Help[7]. Search use: Apple[1],[4] and Google[6]. Example Co. values are fictional.

Three rules shape how you fill them. Apple says not to repeat words already in your name, subtitle or category in the keyword field, and that plurals count as duplicates[4]. Apple says “The first sentence of your description is the most important”, because users can read it without tapping to read more[9]. Google says “Avoid excessive length, detail, improper formatting, and repetition of words”[7], which is also a policy line (Step 8).

Apple’s help reference gives the keyword limit in bytes [1], while its search guidance says characters[4]. The two pages differ, so I follow the help reference and count bytes.

Example Co., step 2 Fictional

App Store name: “Example Co: Nursing Exam Prep” (29 characters). Subtitle: “Daily quizzes & study plans” (27). Keywords: nurse,pharmacology,flashcards,med surg,pediatric,lpn,practice test,question bank (80 bytes). “rn” came out because Apple requires keywords longer than two characters[1]. Google Play short description: “Nursing exam practice questions, flashcards and a study plan that adapts to you” (79 characters).

Do this

Keep every field in a sheet with a live character count (and a byte count for Apple keywords). Leave some of the keyword field free for the next round of testing.

Step 3: Research keywords with search data you can observe

Keyword research combines your customers’ own words with the two demand signals the platforms do show.

  1. Collect terms from customers. Use the words in reviews, support tickets and interviews: Apple’s advice is to choose “words you think people may use to find an app like yours”[4].
  2. Check popularity on Apple. Apple Ads shows search popularity “based on App Store searches”, from 1 to 5, “with 5 being the most popular”[12],[13], plus recommended keywords “being used in App Store searches for apps like yours”[14]. Apple Ads reporting defines search terms as “the words and phrases that people have used to search for the particular type of app they’re looking for”[12].
  3. Check what drives visitors on Google Play. Play Console’s store listing reports have a “Search term” dimension: “The term that the user searched for before navigating to your Store Listing”[8].
  4. Judge competition. Search each term on a phone and see who ranks. Apple’s trade-off: popular terms “may drive a lot of traffic, but are highly competitive – especially if you are a newer or smaller app”, while less common terms are less competitive[4].
  5. Assign and track. Put the best terms in the name and subtitle, the rest in the keyword field (Apple) or naturally in the title and descriptions (Google). App Store Connect’s analytics have no search-term dimension[15], so on iOS track search impressions and downloads by source type[5] and use Apple Ads for per-term data.

Apple also lists what wastes keyword space: plurals, generic terms like “app”, filler words like “the”, and special characters[4].

For each term, ask whether a searcher who typed it would want your app, and drop the terms where the answer is no, whatever their popularity. Downloads are one of the signals both stores name, so I keep a term only when the searcher would want the app[4],[6].

Example Co., step 3 Fictional

The team pulls candidate terms from reviews and support emails. In Apple Ads, “nursing exam” shows popularity 4; “medical app” shows 5 but a nursing student typing it wants a different kind of app, so it is dropped. Play’s search-term report shows “pharmacology quiz” bringing visitors, so “pharmacology” moves into the first line of the full description.

Do this

Keep a sheet of term, source, relevance, Apple popularity and the field used, and review it monthly.

Step 4: Design the icon, screenshots and preview video to convert

Your visual assets are what a searcher sees before choosing your app, and on the App Store the first screenshots appear in search results, not only on the product page.

App Store. Up to 10 screenshots; “the first one to three images will appear in search results when no app preview is available”[9]. Screenshots “should show the app in use, and not merely the title art, login page, or splash screen”[16]. Previews run 15 to 30 seconds, up to three per device size and language[17], may use only screen captures of the app[16], and “autoplay with muted audio”, so make the first seconds count[9]. If your interface is consistent across device sizes and localizations, you can upload screenshots at the highest required resolution and App Store Connect scales them down for smaller devices[18].

Google Play. Icon 512 × 512 px; feature graphic 1,024 × 500 px; at least two screenshots across device types to publish, and up to eight per device type[19]. To be eligible for recommendations in formats that use screenshots, apps must provide “at least four screenshots with minimum 1080px resolution”[19]. The video is a public or unlisted YouTube link with ads off, and “only the first 30 seconds autoplays”[19]. Google advises minimizing text in the feature graphic and giving each screenshot unique alt text[6],[7].

Because Apple shows the first one to three screenshots in search results, lead with the outcome, then one benefit per screen, with captions in your customers’ words.

Example Co., step 4 Fictional

The old first screenshot was the login screen. The new set leads with “Know which topics you’ll fail, before the exam” over the weak-topic dashboard, then one screen each for questions, flashcards and the study plan.

Do this

View your first three screenshots at search-result size on a phone. If a stranger cannot tell what the app does, fix them before testing anything.

Step 5: Test product page changes and read the result properly

Both stores let you A/B test store assets on live traffic, each with its own rules.

Apple Product Page Optimization. One test at a time, up to three treatments of the icon, screenshots and previews, “for up to 90 days”[3]. You choose the share of traffic shown a treatment; in Apple’s example it is split evenly across treatments, and your original page gets the rest[3]. New metadata needs App Review, and alternate icons must be in your app binary[3]. Apple reads results with “Bayesian techniques”, labels a treatment “Performing Better” or “Performing Worse” at 90% confidence, and says “Don’t end tests early”[20]. If a test is “Likely to be Inconclusive”, Apple suggests “a more dramatic change” or rerunning when traffic is higher[20].

Google Play store listing experiments. Test the icon, feature graphic, screenshots and, in localized experiments, descriptions, with up to two variants[21]. You pick the target metric (unique user install, open or pre-registration clicks) and can adjust the confidence level and minimum detectable effect[21]. Experiments “stop automatically after running for 6 months”[21]. The title is not among the testable assets[21].

Figure 3 Store tests: same idea, different rules
  • Apple: Product Page Optimization Google Play: store listing experiments
  • What you can test Icon, screenshots and app previews Icon, feature graphic and screenshots; descriptions in localized experiments. The title is not among the testable assets
  • Variants Up to three treatments against your original page, one test at a time Up to two variants
  • How long Up to 90 days Stops automatically after 6 months
  • How the result is read Bayesian method; a treatment is labeled Performing Better or Performing Worse at 90% confidence You choose the target metric (unique user installs, open or pre-registration clicks) and can adjust the confidence level and minimum detectable effect
  • Apple requirement New metadata goes through App Review; an alternate icon must already be in your app binary

Apple Product Page Optimization[3],[20]; Google store listing experiments[21].

Size the test first. With a standard two-proportion test at 95% confidence and 80% power, the method behind the AAJ A/B Test Significance Calculator:

  • Baseline conversion 3.5%; smallest lift worth finding 20% relative (to 4.2%).
  • Required: about 11,900 unique impressions per arm.
  • At 50,000 impressions a month with 50% of traffic allocated to one treatment, the treatment and the original page each get 25,000 a month: about 14 days.

The stores’ own methods differ from this, so use the calculation to plan and the store’s label to decide. Change one element per test, since Apple advises against “testing overlapping elements simultaneously”[20]. The full method is in A/B Testing: The Complete Guide for Startups.

Free tool

Size your store test before you run it

The free A/B Test Significance Calculator shows how many impressions a test needs for the lift you care about.

Open the calculator
Figure 4 At 25,000 impressions a month, a 20% lift is readable in two weeks and a 5% lift is not readable in 90 days

Unique impressions needed per arm, 3.5% baseline

  • 5% relative lift3.50% to 3.68%; about 215 days at 25,000 impressions a month 177,300 Over Apple’s 90 days
  • 10% relative lift3.50% to 3.85%; about 55 days 45,400
  • 20% relative lift3.50% to 4.20%; about 14 days 11,900
  • 30% relative lift3.50% to 4.55%; about 7 days 5,500
Show the numbers as a table
Lift (target) Impressions per arm Days needed
5% (3.68%) About 177,300 About 215
10% (3.85%) About 45,400 About 55
20% (4.20%) About 11,900 About 14
30% (4.55%) About 5,500 About 7

AAJ’s arithmetic: pooled two-proportion test, 95% confidence, 80% power, 3.5% baseline conversion; days at 25,000 impressions per arm per month. The stores use their own methods, so use this to plan and the store’s label to decide. Example Co. figures are fictional.

Example Co., step 5 Fictional

Example Co. tests the new screenshots against the old on iOS with 50% of traffic. After 16 days the treatment is “Performing Better” at 90% confidence, and the team applies it. On Android it runs a screenshots-only experiment on unique user install clicks.

Do this

Before each test, write the element, hypothesis, impressions needed and end date, and log every result, including losers.

Step 6: Use custom pages to match each audience

Custom pages show a different version of your listing to a specific ad, audience or search, which lets each one match what that visitor came for.

Apple lets you publish “up to 70 additional versions of your product page”, varying “the screenshots, promotional text, and/or app previews”, each with its own URL and optional deep link[22]. You can assign keywords so a custom page appears “in search results for those selected keywords, rather than your default product page”[22]. Metadata is reviewed without a new app version, and App Analytics reports each page’s conversion[22].

Google allows up to 50 custom store listings with their own “name, icon, descriptions and graphic assets”, targeted by country, pre-registration, lapsed or churned users, ads traffic, a URL parameter, or “Users who discover your app on Play using specific search terms”[23]. A country can be targeted by only one custom listing at a time[23].

Figure 5 Custom pages: the same idea on both stores, with different limits
  • Apple: custom product pages Google Play: custom store listings
  • How many Up to 70 additional versions of your product page Up to 50 custom store listings
  • What can differ Screenshots, promotional text and app previews Name, icon, descriptions and graphic assets
  • Who sees it Each page has its own URL and an optional deep link; you can assign keywords so it shows in search for them instead of your default page Target by country, pre-registration, lapsed or churned users, ads traffic, a URL parameter, or users who discover your app with specific search terms
  • Limits and reporting Metadata is reviewed without a new app version; App Analytics reports each page’s conversion A country can be targeted by only one custom listing at a time

Apple custom product pages[22]; Google custom store listings[23].

Example Co., step 6 Fictional

The paid social ads promote the pharmacology module, so they point to an Apple custom page whose screenshots lead with it, assigned the keywords “pharmacology flashcards”. On Play, a custom listing targets searches containing “pharmacology”.

Do this

Give each paid campaign its own custom page so you can compare conversion by campaign.

Step 7: Ask for ratings at the right moment, and reply to reviews

Ratings and reviews are a ranking signal on both stores[4],[6] and appear in search results[24], and both platforms limit how often you can ask.

iOS. Apple’s review prompt, requested through RequestReviewAction in current StoreKit documentation[2] (the older SKStoreReviewController class is listed as available only up to iOS 18.0[25]), appears “a maximum of three times within a 365-day period”, and users can turn it off[2]. You must “Use the provided API”; Apple “will disallow custom review prompts”[16]. Ask “at the end of a sequence of events that they successfully complete”, not at launch and not “as the result of a user action”[2]. For a “Rate us” link, open the App Store page with action=write-review [2].

Android. The In-App Review API has a “time-bound quota” whose value Google calls “an implementation detail” that “can be changed by Google Play without any notice”; calling it more than once in a short period (“for example, less than a month”) “might not always display a dialog”[26]. Don’t ask “Do you like the app?” first, don’t alter the card, and don’t trigger it from a button[26]. Google prohibits “incentivizing feedback, using forced pop-ups, or paying for fake reviews”[27].

Replying. On Apple, “the reviewer is notified and has the option to update their review”[24]. Apple suggests prioritizing low ratings and technical issues, and saying in release notes when you fix a reported problem[24]. Google asks you to stay on the issue and “don’t ask for a higher rating”[27].

Prompt only at the end of a sequence the user has completed successfully: not at launch, not from a button and not as the result of a user action.

Figure 6 Ask after a success: not at launch, not from a button, not as the result of a user action
3 most times Apple shows its review prompt to a user in 365 days Not stated Google’s quota is an implementation detail it can change without notice
  1. App launch Do not ask. Apple says not at launch
  2. A sequence the user completes successfully Ask here, with Apple’s review API or Google’s In-App Review API. Example Co.: the user beats their previous best quiz score
  3. A button or a user action Never. Apple says not as the result of a user action, and Google says not from a button

Apple[2]; Google[26]. Example Co. is fictional.

Example Co., step 7 Fictional

The prompt fires after a user finishes a practice quiz and beats their previous best score. The founder replies to low-rated reviews first.

Do this

Pick one success moment for the prompt and set aside regular time each week for replies. For a wider program, see Customer Advocacy, Reviews and NPS.

Step 8: Stay inside each store’s metadata rules

Both stores publish rules on what listing metadata may say. These are the rules that bear most directly on a listing, in the platforms’ own words.

Apple (App Review Guidelines, last updated October 16, 2026)[16]:

  • Don’t “pack any of your metadata with trademarked terms, popular app names, pricing information, or other irrelevant phrases just to game the system” (2.3.7).
  • Subtitles should not “reference other apps, or make unverifiable product claims” (2.3.7).
  • No other mobile platforms or app marketplaces in metadata (2.3.10).
  • No promoting “content or services that it does not actually offer” (2.3.1).
  • Keyword field: no “Competing app names” or unauthorized trademarked terms[4]; “Names of other apps or companies aren’t allowed”[1].

Google Play (Metadata policy)[28]:

  • No “misleading, improperly formatted, non-descriptive, irrelevant, excessive, or inappropriate metadata”.
  • No “Unattributed or anonymous user testimonials” and no repetitive or unrelated keywords.
  • No text or images showing ranking (“’App of the year,’ ‘#1,’”), price or promotions (“’10% off’”), or Play programs (“Editor’s choice”).
  • No emojis or repeated special characters in the title, icon or developer name.

Apple’s subtitle rule warns against “unverifiable product claims” (2.3.7), and I hold screenshot captions to the same standard: every claim should be one you can prove from your own data; the AAJ Claims & Proof Checker helps.

Example Co., step 8 Fictional

Students search for the licensing exam by its official name, which is a registered trademark. The team keeps that name out of the title and keyword field and asks a lawyer how it may describe the app’s relationship to the exam. A caption reading “#1 nursing app” is cut: Google bans ranking claims[28] and Apple’s subtitle rule warns against unverifiable ones[16].

This is general information, not legal, financial or medical advice. Check with a qualified professional.

Do this

Check every field and caption against these lists before each submission.

Step 9: Localize for the markets you actually serve

Apple does not copy a localization’s description or keywords from your primary language, so each language needs its own search research, not only translated screenshots.

On the App Store, a localization shows to users whose language setting matches, and people “can search for your app using localized keywords in all countries or regions where the App Store supports” that language[29]. Description and keywords are not copied from your primary language[29], so each language needs its own research. On Google Play, Google machine-translates listings you have not translated, and says professional translation can improve discoverability[6].

Choose markets where product, support and pricing are ready, then localize the fields the stores read for search (Step 2) and the first screenshots, which Apple shows in search results. For choosing markets, see International Expansion for SaaS Startups.

Do this

Redo Step 3 with a native speaker for each language, instead of translating your keyword list.

Step 10: Measure the store funnel every month

You can only improve the path from being shown to being installed if you measure it, and the two consoles define it differently.

  • App Store Connect: impressions are views on the Today, Games, Apps and Search tabs “for more than one second”; product page views are views of your page; conversion rate is “Total downloads and pre-orders divided by unique device impressions”[10]. Source type splits search, browse, app referrer and web referrer[5].
  • Play Console: store listing visitors are users “who didn’t already have your app installed”; click-through rate (CTR) is “The percentage of store listing visitors who clicked on a button (Install, Open, or Pre-register)”, which “replaces the legacy ‘Conversion Rate’ metric” from June 2026[8]. Play also shows your CTR against peer median and quartiles where data allows[8]: a benchmark that comes from the store itself.

Apple divides by impressions; Google divides by listing visitors. Don’t compare the two; track each store against itself.

Example Co., step 10 Fictional

September: iOS has 50,000 unique impressions and 1,750 downloads, a 3.5% conversion rate, 60% from search. Play has 8,000 listing visitors and 2,000 install clicks, a 25% CTR, near the peer median. The quarter’s goal: lift iOS conversion (Steps 4–5) and Play explore traffic (Step 3).

Do this

Track impressions, product page views and conversion (Apple) and visitors, install clicks and CTR (Google) monthly by source, and connect installs to activation in your analytics; see Tracking Setup for Startups and the Analytics & Attribution Playbook (B2C edition).

Step 11: Keep a monthly rhythm

ASO is not a launch task. Both stores let you change some of a listing without shipping a new app build, so the work can run as a monthly cycle. On Apple, promotional text can be updated “at any time”[1],[9], new metadata for a Product Page Optimization test goes through App Review and any alternate icon must already be in your app binary[3], and custom product pages are reviewed without a new app version[22]. The app name is the exception: once submitted, it can change only when you create a new version or the version’s status permits editing[11]. Release notes (What’s New) take up to 4,000 characters and do not appear on a first version[1]; Apple suggests saying in them when you have fixed a problem a reviewer reported[24].

Apple lists text relevance and user behavior, with downloads and ratings and reviews as examples and “more” besides[4], and Google lists ratings, reviews and downloads “and other factors”[6]. Neither list is complete, so I use updates to ship fixes and refresh the page, and plan the store work around a calendar I can keep.

A monthly cycle:

  1. Read the funnel (Step 10) and note what moved.
  2. Review keywords and search terms (Step 3): drop terms that bring views and no installs, add terms from new reviews.
  3. Read the reviews and reply to the backlog (Step 7); turn repeated complaints into fixes and repeated phrases into captions.
  4. Pick one test (Step 5), write down the element, the hypothesis and the impressions it needs, and start it.
  5. Log the result, including losers, and update the sheets from Steps 2 and 3.
Figure 7 Your first round: audit, rebuild, test, read
  1. Audit
    • Audit. Fill every field to its limit and move keywords out of Apple’s promotional text (Step 2)
    • Pull candidate terms and check each for relevance (Step 3)
    • Write down this month’s baseline conversion (Step 10)
  2. Rebuild
    • Rebuild. New first three screenshots at search-result size (Step 4)
    • One custom page for the paid campaign (Step 6)
    • Put the review prompt behind one success moment (Step 7)
  3. Test and read
    • Test and read. Start one test per store: Apple screenshots, a Play experiment on install clicks (Step 5)
    • Reply to low-rated reviews first (Step 7)
    • Read both results when the store declares them and log them, including losers (Steps 5 and 10)
  4. Then monthly The monthly cycle. Read the funnel, review terms, read reviews, pick one test, log the result (Step 11)

Sequence built from Steps 2 to 10. How long the test phase takes comes from Step 5’s sizing arithmetic on your own traffic.

Example Co., step 11 Fictional

The marketer blocks the first Monday of each month for the cycle. The audit gives a baseline of 3.5% on iOS, the new screenshots and the custom page go live next, and the two tests start after that. At 25,000 impressions a month per arm, Step 5’s arithmetic says the iOS result is readable about 14 days after the test starts.

Do this

Put the first round of work (audit, rebuild, test, read) in your calendar with one named owner, and block time each month for the cycle.

How is ASO different for a B2B or SaaS companion app?

For a B2B or SaaS companion app, ASO comes down to three jobs: being found by brand, being clear who the app is for, and passing review.

  • Win brand search. Apple indexes your company name[1]; on Google, brand searches show as “Google Play search”[8].
  • Say an account is required in the first sentence of the description[9], so people without an account know before they install.
  • Pass review. Apple requires “demo account info (and turn on your back-end service!)” for apps with a login (2.1(a)); apps without “significant account-based features” should work without a login, and account creation requires in-app account deletion (5.1.1(v)); and apps need more than “a repackaged website” (4.2)[16].
  • Know the purchase rule. Apps “only sold directly by you to organizations or groups” may let those users access purchased subscriptions; “Consumer, single user, or family sales must use in-app purchase” (3.1.3(c))[16].
  • Drive installs from your product, through your web app, emails and help center; these show as web or app referrers[5].

For a consumer app, Steps 2 to 4 and 7 apply in full. The B2C Product Launch Playbook covers App Store pre-orders and Google Play pre-registration (Step 5) and store readiness (Step 6).

What changes by stage?

Pre-launch and pre-seed. Fill every field, do one round of keyword research, and make the first three screenshots show the outcome. Use pre-orders or pre-registration to build demand. Run Step 5’s arithmetic: if your impressions cannot finish a test within Apple’s 90 days, talk to users instead.

Seed. Review keywords monthly, turn on review prompts and reply to low ratings. Start testing once Step 5’s arithmetic says a test can finish within 90 days on Apple.

Series A–B. Test continuously, one element at a time; give each campaign a custom page; localize for markets you sell in. Use Apple Ads and Google App campaigns, which build ads from your assets and store listing across Google Search, Play and YouTube[30], for keyword discovery as well as installs. For budgets, see How Early-Stage Startups Should Use Digital Ads.

What mistakes should I avoid?

  • Keywords in Apple’s promotional text. It does not affect ranking[4].
  • Repeating words across Apple’s name, subtitle and keywords. It wastes space[4].
  • Competitor or trademarked names in metadata. Apple prohibits it[1],[4],[16].
  • “#1”, “Best” or “10% off” in screenshots. Google’s policy bans them[28].
  • A login or splash screen first. Apple wants the app in use[16].
  • Rating prompts from a button, or at any point other than after a success. Apple asks for the prompt after a successful sequence and not as the result of a user action, and Google says not to trigger it from a button[2],[26].
  • Stopping a test early. “Don’t end tests early”[20].
  • Comparing Apple conversion with Google CTR. Different denominators[8],[10].

Related on AAJ

Articles

Playbooks

Templates and tools

References

The superscript numbers in the article match this list.

Every Apple and Google page was opened on October 24, 2026. This guide describes how the platforms document ASO; it is general information, not legal advice.

  1. ”Platform version information.” App Store Connect Help, Apple. Undated. developer.apple.com
  2. ”Requesting App Store reviews.” StoreKit documentation, Apple. Undated (iOS 17+). developer.apple.com
  3. ”Product page optimization.” Apple Developer. Undated. developer.apple.com
  4. ”App Store search.” Apple Developer. Undated (page copyright 2026). developer.apple.com
  5. ”Acquisition.” App Store Connect Analytics Help, Apple. Undated. developer.apple.com
  6. ”Get discovered on Google Play search.” Play Console Help, Google. Undated. support.google.com
  7. ”Best practice for your store listing.” Play Console Help, Google. Undated. support.google.com
  8. ”Understand and grow your app’s user base.” Play Console Help, Google. Undated (refers to June and July 2026 changes). support.google.com
  9. ”Creating your product page.” Apple Developer. Undated. developer.apple.com
  10. ”App metrics.” App Store Connect Help, Apple. Undated. developer.apple.com
  11. ”App information.” App Store Connect Help, Apple. Undated. developer.apple.com
  12. ”Reporting options and definitions.” Apple Ads Help. Undated. ads.apple.com
  13. ”Recommendations” (best practices). Apple Ads. Undated. ads.apple.com
  14. ”Keywords” (best practices). Apple Ads. Undated. ads.apple.com
  15. ”App Analytics filters and dimensions.” App Store Connect Help, Apple. Undated. developer.apple.com
  16. ”App Review Guidelines.” Apple Developer. Last updated October 16, 2026. developer.apple.com
  17. ”App preview specifications.” App Store Connect Help, Apple. Undated. developer.apple.com
  18. ”Screenshot specifications.” App Store Connect Help, Apple. Undated. developer.apple.com
  19. ”Add preview assets to showcase your app.” Play Console Help, Google. Undated. support.google.com
  20. ”Product page optimization” (results). App Store Connect Analytics Help, Apple. Undated. developer.apple.com
  21. ”Run A/B tests on your store listing” (store listing experiments). Play Console Help, Google. Undated. support.google.com
  22. ”Custom product pages on the App Store.” Apple Developer. Undated. developer.apple.com
  23. ”Create custom store listings to target specific user segments.” Play Console Help, Google. Undated. support.google.com
  24. ”Ratings, reviews, and responses.” Apple Developer. Undated. developer.apple.com
  25. ”SKStoreReviewController.” StoreKit documentation, Apple. Undated (availability iOS 10.3–18.0). developer.apple.com
  26. ”Google Play In-App Reviews API.” Android Developers, Google. Undated. developer.android.com
  27. ”User Ratings, Reviews, and Installs.” Play Console Help, Google. Undated. support.google.com
  28. ”Metadata” policy. Play Console Help, Google. Undated. support.google.com
  29. ”Localize app information.” App Store Connect Help, Apple. Undated. developer.apple.com
  30. ”About assets and ads in App campaigns.” Google Ads Help, Google. Undated. support.google.com

More in Content, Copy & SEO

Part of the Content, Copy & SEO hub - see all 18 resources on this topic.

Also useful in Paid Media.