App Store keyword research without a paid tool

Google Play Console shows you the search terms that brought people to your listing. Apple shows you nothing of the kind: App Store Connect has no keyword dimension and never has had one. Most keyword guides have this backwards, because they assume Apple is the more generous platform.

That asymmetry decides the whole method. On Play you read what happened. On the App Store you guess well, ship, and infer.

Where the data actually is

	App Store	Google Play
Search terms that found you	Not available	Yes, in acquisition reporting
Traffic source split	Yes, by Source Type	Yes, by Traffic source
Organic vs paid search separated	No, one combined Source Type	Yes
Keyword popularity figure	Apple Ads, scale of 1 to 5	Not published
Conversion rate by source	Yes	Yes, plus 1-day retention in experiments

Play's acquisition report breaks visits down by search term, country, language, store listing version and install state. Apple's dimensions list covers download date, version, device, platform, product page, region, territory, source type and campaign. No search term, no keyword.

The workaround everyone reaches for is Apple Ads. It does publish a popularity figure, and the campaign builder suggests related keywords from your app and genre. Two things to know before you rely on it.

The scale is 1 to 5. Apple's own glossary: "Search popularity is displayed as numbers from 1 to 5, with 5 being the most popular." The 5-to-100 index you see quoted everywhere comes from third-party tools reading Apple's API, not from anything Apple publishes. If a guide attributes 5-to-100 to Apple, it did not check.

It is gated on activity. Apple says one reason you may see no recommendations is that "there may not be enough campaign activity". You can build a campaign before adding a payment method, and it starts running once you add one. Treat browsing popularity without spending as an undocumented side effect, not a feature.

Spending 100 bytes

Apple's own guidance, quoted because it is more specific than most advice written about it:

"Keywords are limited to 100 characters total, with terms separated by commas and no spaces. You can use spaces to separate words within keyword phrases."

And what to leave out: plurals of words you already included, because Apple counts them as duplicates. Generic terms like "app" or "game". Filler words like "the" and "to". Special characters unless they are part of your brand.

Then the instruction people skip: do not repeat words from your app name, subtitle, or category. Apple indexes all three. Your primary and secondary categories are indexed too, which makes category selection a search decision rather than an admin one.

Note it is 100 bytes, while name and subtitle are counted in characters. In English these are the same. In Czech, Russian or Japanese they are not, because accented and non-Latin characters cost two or three bytes each.

Google Play has no keyword field. Your terms live in the title, the 80 character short description and the 4,000 character full description, and Google's published advice is thin on purpose: use SEO best practices in the description, keep the title unique and focused, and avoid deliberate misspellings because people correct them.

Three things everyone repeats

"Apple combines your name, subtitle and keywords into phrases for you." Apple has never said this. It said not to repeat words, and that plurals count as duplicates. The combination theory is an inference from those two instructions. It is probably right. It is not citable, and a guide that states it as Apple's algorithm is guessing with confidence.

"The popularity score runs 5 to 100." Apple documents 1 to 5. See above.

"App Analytics shows your keywords." It does not. Play does.

What will get you rejected

Apple names this directly: improper keyword use is a common rejection cause. Specifically banned are unauthorised trademarked terms, celebrity names, terms not relevant to the app, and competing app names.

Guideline 2.3.7 goes further and says Apple "may modify inappropriate keywords at any time". So the downside is not only rejection. You can also lose the field you spent an afternoon on, without being told.

Google's metadata policy bars repetitive or unrelated keywords, brands and celebrity names used without permission, and misleading references to competing apps.

Testing, where it is possible

Neither store lets you A/B test your keywords. Both let you test creative.

Apple Product Page Optimization runs up to three alternate treatments against your original page, for up to 90 days, on a share of traffic you choose. You can test the icon, screenshots and app previews. Text is not testable. Results use Bayesian confidence with a 90% threshold, and tests only appear once at least five first-time downloads are attributed. Testing alternate icons requires a new app version, because every icon variant has to be in the shipped binary. Everything else can be submitted independently.

Google Play Store Listing Experiments allow two variants, run up to six months, and can test text, which Apple's cannot. Google advises testing for at least a week to cover weekday and weekend traffic, and changing one asset at a time.

The measurement trap

On the App Store, organic search results and Apple Ads share a single Source Type. Apple says so plainly: filter by App Store search and "keep in mind that your Apple Ads performance shows up here as well."

So if you are running ads while you change your keyword field, you cannot read the effect of the change. Either pause the ads for the measurement window or accept that the number is contaminated. This is the most common reason a developer concludes a metadata change "did nothing".

What you can read: unique impressions, product page views, conversion rate, and the one that matters most, conversion rate by source type. That is the number worth watching after a metadata change, not raw downloads.

Two newer places your keywords go

Custom product pages can carry their own keywords, assigned from your latest approved version, and Apple can serve that page instead of your default one for those searches. You can assign them at any time without review, though the page itself must be approved and visible. Apple allows up to 70. Google allows up to 50 custom store listings, and those can be keyword-targeted too.

App Tags are generated by a large language model from the metadata you already wrote, then curated. They appear in search results and as tappable entities on your product page. You can deselect ones that do not fit, and Apple warns that deselecting all of them may affect discoverability. They are United States only.

The practical consequence: your keyword field and description are no longer just matched against queries. They are also the input to something that generates a browsable surface you do not directly control.

A method that works with what you can actually see

1. Read your Play search terms. That is real query data and it is free. Most of it applies to your App Store listing too, because people describe the same job the same way.
2. Read your own reviews for the words users use. They rarely match the words you chose.
3. Search your main terms in both stores and write down the top five apps' names and subtitles. Those are indexed fields you can read for free.
4. List every word already in your name, subtitle and category. Those are spent.
5. Fill the 100 bytes with words not on that list. Comma separated, no spaces, singular.
6. On Play, work the terms into the title, short description and full description, without stuffing.
7. Ship it, note the date and exactly what you changed, and pause any Apple Ads you want to measure around.
8. Four weeks later, look at conversion rate by source type, not downloads.

What Uprate does with it

The listing agent drafts your title, subtitle, keywords and description from the build you actually ship, and comes back when they drift. The submission agent catches the metadata problems that get a version rejected before you send it.

Nothing goes live until you approve it.