You have one product and two listings, and a reasonable assumption that the work carries over. Most of it does not. The fields have different names and different caps, and — the part that changes what you actually write — a different documented relationship to search.
Google Trends, on a twelve-month worldwide window seeded with “app store optimization”, puts “android app store optimization” among the top related queries at a relative interest value of 61 and makes it the fastest riser at +120%; “app store optimization google play” is in both lists at 55 and +40%. Those are relative-interest figures, not volumes — Trends publishes none, and neither store does. A lot of people are working out which half of their ASO transfers.
The short answer, with the rest of this post as its sourcing: Apple gives you a keyword field no user sees and does not name your description among its search inputs. Google gives you no keyword field at all and names the description as metadata it uses to match your app to a query. Each store says this about itself.
One disclosure before the field list. Appstro is an iOS tool: everything the site measures, checks and ranks runs against the App Store. The Google Play half of this post is documentation read at Google's own pages — nothing here analyses a Play listing, or claims it could.
What Apple documents
Three Apple pages carry it, all fetched for this post rather than recalled. That matters more than usual with Apple: developer.apple.com/help returns HTTP 200 for paths that do not exist, so the check is a page's <title>, not its status. A bogus help path returned 83,352 bytes titled “Page Not Found”, against 376,354 for the real reference page.
The caps come from App Store Connect Help. The app information reference gives the name as “at least two characters and no more than 30 characters” and the subtitle as no longer than 30. The platform version information reference gives the keyword field — “up to 100 bytes of content” — plus description at 4,000 characters and promotional text at 170.
Bytes, not characters — and Apple's own two pages disagree on the word: the App Store search page says 100 characters, while the reference page for the field says bytes. In English they are identical. In Japanese, Greek or Arabic they are not, and your real budget is smaller than the one you think you have.
That same App Store search page is the only place Apple names its search inputs:
“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).”
Four text inputs: title, subtitle, keywords, primary category. Apple confirms the last of those separately — the primary and secondary category are “indexed by our search algorithm”. The description is not in the list. It does appear on the same page, but under advice on building a product page that converts, alongside screenshots and the icon.
Apple also documents one clean negative, rarer than it sounds: promotional text “doesn't affect your app's search ranking”, so it should not be used to display keywords. A field explicitly ruled out.
What Google documents
Google's equivalent is App Discovery and Ranking in Play Console Help, more forthcoming about mechanism than Apple's:
“Once we establish intent, metadata (for example, title, description, category) and other signals are used to determine which apps best address the user's query.”
Description, named, as an input to matching. The same page says Play may identify “other words, such as synonyms” when working out intent, and that search results are “heavily influenced by relevance to the user's query” where Top Charts run on popularity.
Play Console Help's Get discovered on Google Play search goes further, telling you to use “SEO best practices” in your description, subject to the content policies. It states that ranking combines “ratings, reviews, downloads, and other factors”, while calling the weights “a proprietary part of the Google search algorithm”.
The caps come from Best practices for your store listing: the title “must be 30 characters or less”, the short description conveys the message “in 80 characters or less”, and the full description “allows for 4,000 characters”. The 30-character title cap is repeated in the Metadata policy, which makes it a policy line, not only a form limit.
There is no keyword field, and the cleanest proof is Google's own API. The Play Developer API Listing resource has exactly five fields: language, title, fullDescription, shortDescription, video. Apple's App Store Connect API, by contrast, models search keywords as a resource linked to an app store version localization. The asymmetry is in the data models, not only the help pages.
The fields, side by side
| App Store | Google Play | |
|---|---|---|
| Name field | Name, 30 characters | Title, 30 characters |
| Second short field | Subtitle, 30 characters | No subtitle field exists |
| Hidden keyword field | 100 bytes | Does not exist |
| Long text | Description, 4,000 characters | Full description, 4,000 characters |
| Long text as search input | Not named by Apple | Named as metadata used |
| Short marketing line | Promotional text, 170 characters | Short description, 80 characters |
| That line in search | Documented: no effect on rank | Not named separately |
| Category | Documented as indexed | Named as metadata used |
| Behaviour signals | Downloads, ratings and reviews | Ratings, reviews, downloads |
| Weighting | Not published | Not published, stated proprietary |
The two 4,000-character fields are the same size and do a different job. That single row is most of the work.
One list of words: a field on one store, a violation on the other
Apple's search page tells you to separate keyword terms with commas and no spaces, and gives its own example in that form: Property,House,Real Estate. It is the required shape of the field.
Google's Best practices page prints a nearly identical construction as something not to do — a description reading “Car racing, car driving, race cars, car races, race track…” — and instructs you to give an overview “using everyday language, not a list of keywords”. The Metadata policy adds “Avoid using repetitive or unrelated keywords or references”, and Play Console Help tells you not to repeat your short description inside your full description.
So the identical artefact — a comma-separated run of query terms — is the required contents of one Apple field and a named policy violation in the Google field sitting in roughly the same place in your workflow. Carry an App Store keyword string across into a Play description and you have not adapted your ASO; you have written a policy example.
Where the received wisdom overshoots
Three claims circulate constantly here. Each is close to something true, and each states more than either store does.
“Apple does not index the description.” Apple does not say this. It lists four text inputs and the description is not among them, which is a different claim — not named against documented as having no effect. Apple makes the second kind of statement exactly once, about promotional text, which shows it will say so when it means it. Treat the description as unproven for search and load-bearing for conversion, rather than upgrading an omission into a denial.
“On Play, the title, short description and long description are all indexed.” Google names “title, description, category”, and nowhere distinguishes the short description from the full one. The short description is documented as appearing in search results, which is a placement, not a ranking claim. Write both fields well; do not attach Google's name to the claim that it indexes each separately.
“Keyword density” rules for either store. Neither Apple nor Google publishes one. Google's guidance runs the opposite way — repetition is what its policy pages warn against.
What this post cannot tell you
- Not how many people search a term, on either store. No public source has this — not Apple, not Google, not any tool that sells it. The Trends figures above are relative interest in web search, not App Store or Play search volume.
- Not the weights. Apple names factors without an order; Google names factors and calls the weighting proprietary. Anyone ranking these fields by importance is reporting practice, not documentation.
- Not what a competitor put in their Apple keyword field. It is published nowhere. Verified against the live iTunes API on both the
lookupandsearchendpoints: every result object carries 43 or 44 keys, andsubtitle,keywordsandpromotionalTextare not among them — absent, not empty. It is why Appstro's listing kit starts those three fields blank behind a “not available from the public API” badge rather than guessing them from the description. - Not whether an edit will move your rank on either store. Neither vendor publishes the function, so a rank change after an edit is an observation, not an attribution.
- Nothing measured about Play. Every Play statement here is quoted from Google's documentation. This site runs no Play measurements, and a post implying otherwise would be the exact failure it argues against.
The work
Start both listings from the same understanding of your product and the same candidate terms, then split them by what each store documents. On the App Store, spend 100 bytes on terms not already in the name or subtitle, and let the description convince a reader who has already found you. On Play, write prose a person would read, because the field carrying your terms is the field a user is looking at.
For the App Store half, the listing kit puts every App Store Connect field on one sheet with the caps enforced, and keyword research draws candidate terms from Apple's own autocomplete rather than a volume figure that does not exist. For the Play half, the pages linked above are Google's, and only they speak for it.