iOS keyword research: which terms are worth your 100 bytes
Keyword research for iOS is a budgeting problem. The keyword field is 100 bytes of UTF-8, hidden from users, comma-separated, and ranked third after your name and subtitle. Every term you add costs bytes that another term could use, so the job isn't 'find good keywords', it's 'find the highest-relevance terms that fit the budget.' The catch: Apple publishes no search volume, so you're ranking candidates by a relative popularity index, not a real demand number. That single constraint shapes the entire workflow. You cannot optimize toward 'the keyword with 40,000 searches a month' because no such published number exists for the App Store; you can only compare terms against each other using Apple's relative Search Popularity index and your own judgment about relevance and competition. The hidden nature of the field also changes the rules from the name and subtitle: nothing here needs to read well, so it is pure ranking machinery, which means every byte should go to a distinct, indexable, winnable term and nothing should be spent on phrasing, spaces, or words already carried by your higher-weight fields. Master the byte counting and the pruning discipline and you fit more winnable searches into the same 100 bytes than a competitor padding theirs with filler.
Where do candidate terms come from?
Start from how users describe your app in their own words: the problem it solves, the feature they'd search for, the category-adjacent terms competitors rank for. Mine your own reviews and support messages for the language people actually use, because users rarely search with the vocabulary your marketing team chose. Pull terms from comparable apps' visible name and subtitle, and use sanctioned sources, the iTunes Search and Lookup endpoints, rather than scraping store HTML, which violates Apple's terms. Apple's own search autosuggest is a legitimate signal for what real users begin typing. Build candidates in clusters around each core concept, for a meditation app that means the 'sleep' cluster (sleep, insomnia, bedtime, naps), the 'relaxation' cluster (calm, relax, unwind, stress), and the 'sound' cluster (white noise, ambient, soundscape). The output of this stage is a long, messy candidate list, often a hundred or more terms. You'll cut most of it; the goal here is coverage, not the final set, because you cannot prune toward the best 100 bytes from a list that was too short to begin with.
How do you judge a term: relevance, competition, popularity?
Three lenses. Relevance: would a user typing this term be happy to find your app? Irrelevant high-traffic terms convert badly, depress your conversion-fed ranking, and can mislead the store about what you are. Competition (difficulty): how entrenched are the apps already ranking? A niche term you can realistically win beats a giant term where you sit on page five and are effectively invisible. Popularity: Apple Search Ads Search Popularity, a relative, storefront-scoped index, read roughly 0 to 100 and exponential, so SP 90 is vastly more searched than SP 30, not three times more. Never convert it into 'searches per month'; Apple doesn't publish that figure, and any tool claiming it is estimating or fabricating. Note that Apple's Search Popularity backend grew noisy and floor-pinned in late 2025, so treat single readings cautiously: smooth values over a window, drop floor-level readings, and ignore terms returning 'insufficient data'. Favor relevant terms with winnable competition and meaningful relative popularity over vanity head terms you cannot rank for. The sweet spot is the mid-tail: specific enough to win, popular enough to matter.
How do you spend the 100-byte budget?
Count UTF-8 bytes, not characters: in JavaScript that's Buffer.byteLength(value,'utf8'), not value.length. ASCII letters are 1 byte, accented Latin characters are 2 bytes, and CJK and emoji are 3 to 4 bytes, so a Japanese or Chinese keyword set overflows long before a 100-character count would warn you. A naive .length check will silently let you submit an over-budget Japanese field that Apple truncates. Use single commas, no spaces: 'fitness,workout,running' not 'fitness, workout, running', because each space is a wasted byte that buys no ranking. Each term should be longer than two characters; very short terms are not indexed. Don't write multi-word phrases you can build from single words, since Apple auto-combines terms across the name, subtitle, and keyword field, so listing 'sleep' and 'sounds' separately lets it match 'sleep sounds' for free. Within the budget, prefer more distinct mid-tail terms over a few crowded head terms; coverage of many winnable searches usually beats betting all 100 bytes on one popular word you cannot rank for. Every byte recovered from a space, a plural, or a duplicate is a byte for a new term.
What do you prune before you ship?
Drop anything already in your app name or subtitle, those are indexed separately and higher weighted, so repeating them here is pure waste of bytes you could spend on new coverage. Drop plurals of words you already have; Apple handles the singular/plural variation, so 'run' covers 'runs' and often 'running' stems. Drop category names ('games', 'productivity'), filler ('app', 'best', 'free'), and your own brand, none of which earns rank, since Apple already associates your brand and category with you. Drop floor-pinned, noisy Search Popularity terms and long-tail words showing 'insufficient data' rather than guessing at their value. Drop terms that are wildly irrelevant even if popular, because mismatched traffic converts poorly and can trip review. What survives is a comma-separated set of distinct, relevant, winnable terms that fits inside 100 bytes with no wasted spaces or repeats. appusula validates the byte length live and flags duplicates, plurals, cross-field repeats, and over-budget input as you build the set, so you can see exactly which bytes are working and which are decoration before you submit.
Why byte length, not character length, breaks everything
The single most common metadata bug on iOS is treating the keyword field as 100 characters. It is 100 bytes of UTF-8, and the difference only bites you in non-Latin storefronts, which is exactly where many developers do not test. An ASCII keyword set of 100 characters fits in 100 bytes, so an English-only developer may never notice the distinction. But in the Japanese storefront, where each kana or kanji costs 3 bytes, '100 characters' of keywords is roughly 300 bytes and Apple silently truncates at the byte boundary, often cutting a term in half so it indexes nothing. Accented Latin terms in French or Spanish ('café', 'niño') cost 2 bytes per accented character and quietly shrink your usable count too. The fix is to validate with Buffer.byteLength(value,'utf8') in JavaScript, or the equivalent UTF-8 byte count in any language, and to run that validation per localization rather than once. Build the byte counter as a configurable constant, because Apple has changed field limits before and treating 100 as hard-coded magic invites a silent breakage when it shifts. A live byte meter that turns red at 100 prevents the entire class of bug.
Localization multiplies the keyword budget
Each App Store localization carries its own separate 100-byte keyword field, and Apple indexes certain locale pairs together within a single storefront. In the US store, both English (US) and English (UK) are indexed, so filling the English (UK) keyword field with 100 bytes of entirely different, non-overlapping terms effectively doubles your keyword space at zero translation cost. The same trick works for Spanish (Mexico) plus Spanish (Spain) and other indexed pairs. The discipline is the same as within a single field: no repeats across the paired localizations, because a word indexed in English (US) gains nothing from being repeated in English (UK). So the second localization is where your overflow terms go, the strong candidates that did not fit the first 100 bytes. Before adding fresh translations, confirm which localizations your target storefront actually indexes, then treat each indexed localization as another full keyword budget. Many solo developers leave this entirely unused, shipping a single English field while a second indexed English locale sits empty; populating it is one of the highest-return, lowest-effort moves in iOS keyword research.
Treat the keyword set as a living, measured asset
Keyword research is not a one-time submission. Search Popularity shifts, competitors change their metadata, and your own conversion data reveals which terms actually bring users who install. Because the keyword field is hidden, you can iterate it aggressively across releases without worrying about readability or confusing browsing users. After each release, review which terms are still relevant, which have dropped to floor-level or 'insufficient data' on the popularity index, and which new terms have emerged from fresh reviews or category trends. Swap out the weakest performers for new candidates and re-validate the byte count. Keep a record of the previous keyword set so you can correlate metadata changes with ranking movements, since you are working without published volume and your own before-and-after data is the most reliable signal you have. Source everything from sanctioned rails: the iTunes Search and Lookup endpoints and your own App Store Connect data, never scraped HTML. Over several release cycles this measured, iterative loop compounds, and your 100 bytes end up carrying a far better-tuned set of winnable terms than any single research session could have produced.
FAQ
How many keywords fit in the iOS keyword field?
It depends on byte length, not a fixed count. The field is 100 bytes of UTF-8 with single-comma separators. ASCII words fit more; CJK, emoji, or accented terms cost 2 to 4 bytes per character, so far fewer fit. Count with Buffer.byteLength(value,'utf8'), not value.length. Drop the spaces after commas to recover bytes, and remember each term must be longer than two characters to be indexed at all.
How do I know a keyword's search volume on iOS?
You don't. Apple doesn't publish volume. Use Apple Search Ads Search Popularity as a relative, storefront-scoped index, roughly 0 to 100 and exponential, to compare terms against each other rather than as an absolute demand figure. Treat any 'X searches per month' figure as fabricated. The index also grew noisy and floor-pinned in late 2025, so smooth readings over a window, drop floor-level values, and ignore 'insufficient data' terms instead of guessing.
Should I include both singular and plural keywords?
No. Apple handles singular and plural variation, so adding the plural of a term you already have wastes bytes. Pick one form and use the saved space for a new relevant term. The same applies to obvious word stems Apple already covers. You also don't need to write out multi-word phrases from words you already list separately, because Apple auto-combines adjacent terms across the name, subtitle, and keyword field.
Should I repeat my app name or subtitle words in the keyword field?
No. Those fields are indexed separately and carry higher weight. Repeating their words in the keyword field is counted once but pays for the bytes twice, so spend the bytes on terms that appear nowhere else. Treat the name, subtitle, and keyword field as one shared word pool with no duplicates, and reserve the hidden 100 bytes for the winnable terms you could not fit into your two visible, higher-weighted fields.
Where should I source keyword candidates without breaking Apple's rules?
Use sanctioned rails only: the iTunes Search and Lookup endpoints, Apple's search autosuggest, your own App Store Connect and Apple Search Ads data, and your own reviews and support messages for real user language. You can read competitors' visible name and subtitle through the public lookup APIs. Never scrape store HTML, which violates Apple's terms. Cache results and back off on rate limits, since the iTunes endpoints are sanctioned but throttled.
appusula puts these checks in one self-hosted dashboard: keyword ranks, metadata validation, competitor tracking, and AI visibility.
Get started