Skip to main content
Both stores are live and equally supported. What differs is which fields each store indexes for search, and one of Apple’s indexed fields cannot be read from the public listing at all. On the App Store, asobeast tracks listings available on iPhone or iPad, because it reads iPhone and iPad search. A listing sold only on the Mac App Store, Apple Watch or Apple Vision Pro is refused on import.

​
What does each store index?

Google Play search therefore reads three surfaces: the title, the 80 character short description and the 4000 character long description. There is no subtitle and no keyword field on Google Play, so those two stay Apple only concepts everywhere in asobeast, including the types, the metadata lints and the audit rubric.

​
Why is the iOS keyword field private?

The 100 character iOS keyword field never appears on the public store page, so no amount of collection can read it. It exists only in App Store Connect. asobeast handles this by asking you for it. Paste the field in the metadata workbench and asobeast stores those keywords with the source KEYWORD_FIELD, which lets coverage checks, the audit rubric and the Action Center reason about a surface they cannot otherwise see. Leaving it empty is not neutral. Coverage will report the field as uncovered because asobeast has no evidence that it contains anything.

​
How do you read and write the keyword field?

The field is one endpoint pair on the app, and both answer the same KeywordFieldResult shape. Six things the schema cannot tell you.
  • The value is the tracked set, not your string. asobeast normalizes each phrase, drops the empties and removes the duplicates before it tracks anything, so Focus Timer, POMODORO ,pomodoro reads back as focus timer,pomodoro. Spacing and casing can differ from what you submitted, a repeated phrase stays where it first appeared, and the character count is the count of the normalized set. The phrases keep the order of the latest submission.
  • A save is held to the 100 character limit. The limit is measured on the normalized set, the same count charactersUsed reports, so spacing and duplicates in the submitted text do not count against it. A save whose normalized set runs past 100 characters answers 400 and changes nothing.
  • It is home market only. The read takes no country and scopes itself to app.country, because the keyword field belongs to the app rather than to a storefront. See Countries and markets.
  • duplicatesRemoved is 0 on a read. It reports what the last submission discarded, and a read submits nothing.
  • A save never untracks a keyword something else tracks. A phrase already tracked from the title, the subtitle, the short description or a manual add joins the field without losing that source, and the API reports it as KEYWORD_FIELD while it is in the field. A later save that leaves it out only takes it out of the field, so it stays tracked under its own source. A phrase that only the field tracks is deactivated when a save leaves it out. Adding such a phrase manually or reactivating it makes it a manual keyword, and a snapshot that finds it in the title, subtitle or short description gives it that source.
  • The last save wins. Saves to one app are written one at a time, so two saves that overlap never merge: the field holds the phrases of whichever save was written last. Each save answers with the field as it was stored when that save finished, so a save that overlapped another may be answered with the other save’s phrases.
An app that has never had a keyword field reads as an empty result with 0 characters used rather than a 404, because an empty field is a normal state. A Google Play app refuses both operations with 400.

​
Why is the Google Play short description its indexed surface?

The 80 character short description, called summary in the store payload, is Google Play’s equivalent of the surfaces Apple splits across a subtitle and a keyword field. asobeast treats it accordingly.
  • Its keywords are tracked automatically with the source DESCRIPTION.
  • The metadata workbench lints it against the 80 character limit.
  • Keyword coverage counts it as an indexed field.
The store page escapes some characters in the short description, so Math & Music arrives as Math & Music. asobeast stores the short description as the plain text a user reads, keeps the payload exactly as received in raw, and counts characters the way Google Play does. An upgrade decodes short descriptions already stored and pauses the auto tracked keywords an escape produced, such as amp music, keeping their history.

​
What stays Apple only?

The subtitle and the keyword field. On a Google Play app they carry audit weight 0 and are hidden in the web app rather than shown empty, and the Action Center skips rules that would recommend an impossible edit.

​
Are scores comparable across stores?

No. Traffic and difficulty are derived from different public evidence on each store, so an Apple difficulty of 60 and a Google Play difficulty of 60 do not mean the same thing. Compare a keyword against other keywords in the same store. See Traffic, difficulty and opportunity.

​
Where else do the stores differ?

​
What happens when a store changes its response?

A parser breaks, for every installation at once. Only the provider layer parses store responses, so the break is one module, failed jobs stay contained, and no history is lost. See Recover from a broken store parser.

​
Why does a Google Play job cost more?

Because one logical job fans out to many requests. A Google Play score job makes roughly 15 to 18 sequential requests: one search, up to seven prefix probe suggests and ten detail enrichments. An Apple score job makes roughly two. A depth 200 Google Play position check takes roughly eight requests against one for Apple. That is why SCRAPE_GPLAY_RPM spaces job starts rather than individual requests, and why its default of 10 is lower than the Apple default of 15. See The daily pipeline and rate limits.
Last modified on September 15, 2026