Squeezing Every Character of Value Out of Your App Store Keyword Field — A Practical ASO Guide for Rork-Built Apps

I was about to submit a minor update of my wallpaper app one evening when I opened the keyword field in App Store Connect almost by accident, and stopped. Words from the app name were sitting there again, every comma was politely followed by a space, and of the hundred characters available, maybe half were doing any work.

I had spent an entire weekend replacing screenshots for that release. The keyword field, on the other hand, had been filled in a few minutes on launch day and never touched since. I only noticed because I had been staring at Analytics trying to understand why search installs had flattened out.

What follows is the way I now design the keyword field for Rork-built apps, in the order I actually do it, plus a small script at the end that counts the remaining budget and catches duplicates so I don't have to.

Why This One Field Can Move Rankings

App Store search ranks apps on a blend of signals: name, subtitle, keyword field, category, downloads, and ratings. The keyword field is the only one of those where you explicitly tell the store "treat these words as searchable for my app." If a word appears in none of your name, subtitle, or keyword field, your app essentially doesn't exist for that query.

For an indie developer with no ad budget, organic search is close to the only acquisition channel there is. I've come to treat those hundred characters as free, targeted distribution — and to reopen them on every release.

There's a second, less obvious advantage. End users never see the keyword field. Unlike your name and subtitle, you can fill it with plain, utilitarian words you'd never put in a tagline. "Tracker," "log," "list," "organizer" — they look dull in marketing copy, but they're exactly what people type into the search bar.

How the 100 Characters Are Counted, and What I Got Wrong for Years

The field takes 100 characters, and a few rules decide what counts as one:

• Each comma counts as one character
• A space before or after a comma counts too — a wasted character
• Every character counts the same, including non-Latin scripts like Japanese
• Line breaks aren't allowed
• Listing both the singular and the plural of an English word tends to waste characters, so I keep only one

The thing I got wrong for years was the spaces. I kept them because the list was easier to read, and in a twelve-word list that quietly cost me eleven characters — an entire short keyword.

NG: recipes, vegan, dinner, easy, quick   (4 characters lost to spaces)
OK: recipes,vegan,dinner,easy,quick

A handful of characters doesn't sound like much, but in a field you're packing to the limit it's one or two extra terms. Deleting those spaces was the easiest and most reliable improvement I ever made to a listing.

Give the Name, Subtitle, and Keyword Field Different Jobs

If there's one thing I'd like you to take from this piece, it's that a word already in your app name or subtitle doesn't need to appear in the keyword field at all.

Search weights words in the name and subtitle more heavily than keyword-field entries, and those words are searchable automatically. If your name is "Bento — Meal Planner" and your subtitle is "Weekly recipes for busy families," then adding "meal," "planner," or "recipes" to the keyword field just burns characters.

The subtitle is nearly as strong as the name for search, so filling it with a vague feature description is a missed opportunity. I lay all three fields side by side in one spreadsheet and cross out duplicates before I design anything. The name and subtitle are the signboard; the keyword field is where the words that didn't fit on the signboard go. Once I drew that line, the leaks mostly stopped.

Choosing Keywords That Actually Get Typed

Cover spelling and script variants

In markets like Japan, the same word can be written in kanji, hiragana, or katakana, and each spelling matches different searches. Most listings only include one. If your budget allows, add two or three variants of your most important terms — the same idea applies to British and American spellings in English.

Mix in one or two words from another language

A surprising number of people search a non-English storefront using English words, especially for developer and creator tools. One or two English terms in a localized keyword field can reach expatriates and bilingual users without touching your UI.

Never include competitor names

It's tempting to target "an alternative to X" by listing X. It violates the App Store Review Guidelines and gets rejected, and trademarked product names are the same story. Even if it worked for a week, I've decided it's not a trade I'm willing to make.

Read autocomplete on both iPhone and iPad

Type your category into the App Store search bar and note every suggestion. Those are real queries with real volume, and most of them aren't the ones you'd think of from your desk. The suggestions can differ slightly between iPhone and iPad, so if your app supports both, check both.

The Five-Step Workflow I Use for Rork-Built Apps

1. Pick the core verb. What does the user do with your app — track, edit, plan, learn? One word.
2. List 5 to 10 nouns attached to that verb. What's being tracked, edited, planned? Be specific.
3. Pull 10 to 15 terms from App Store autocomplete. Type each noun into the search bar and write down what appears.
4. Strike out anything already in the name or subtitle. Those characters are wasted.
5. Pack what's left, comma-separated, no spaces, until you reach 100. Include spelling variants where they matter.

Steps 4 and 5 are where I always miscount by hand, so I hand them to a script.

A Script That Counts the Budget and Catches Duplicates

Edit the arrays, run node keyword-budget.mjs, and it drops any candidate already covered by the name or subtitle, removes duplicates, and prints how many characters remain. Length is measured with Array.from so it counts code points — emoji and combining characters won't throw it off the way String.length can.

// keyword-budget.mjs — drop words covered by the name/subtitle and count the remaining budget
const name = "Bento — Meal Planner";
const subtitle = "Weekly recipes for busy families";
const candidates = [
  "groceries", "lunchbox", "kids", "vegetarian", "shopping list", "dinner",
  "easy", "quick", "recipes", "planner", "budget", "leftovers", "pantry",
  "bento", "meal prep", "picky eaters", "school lunch", "Groceries ",
];
 
const LIMIT = 100;
const covered = `${name} ${subtitle}`.toLowerCase();
const length = (s) => Array.from(s).length; // count code points, not UTF-16 units
 
const kept = [];
const dropped = [];
for (const raw of candidates) {
  const kw = raw.trim().toLowerCase();
  if (covered.includes(kw)) { dropped.push(`${kw} (already in name/subtitle)`); continue; }
  if (kept.includes(kw)) { dropped.push(`${kw} (duplicate)`); continue; }
  kept.push(kw);
}
 
const field = kept.join(",");
const used = length(field);
console.log(field);
console.log(`used ${used} / ${LIMIT} (remaining ${LIMIT - used})`);
for (const d of dropped) console.log(`- dropped: ${d}`);
if (used > LIMIT) console.log(`over by ${used - LIMIT}; trim from the end`);
if (/,\s|\s,/.test(field)) console.log("there is whitespace next to a comma");

Running it on that example gives:

groceries,lunchbox,kids,vegetarian,shopping list,dinner,easy,quick,budget,leftovers,pantry,meal prep,picky eaters,school lunch
used 126 / 100 (remaining -26)
- dropped: recipes (already in name/subtitle)
- dropped: planner (already in name/subtitle)
- dropped: bento (already in name/subtitle)
- dropped: groceries (duplicate)
over by 26; trim from the end

"recipes," "planner," and "bento" fall out because the name and subtitle already cover them, the stray "Groceries " with a trailing space is trimmed and caught as a duplicate, and the script tells me plainly that I'm 26 characters over. That's the moment to cut the weakest multi-word phrases rather than guess.

One caveat: the check is a substring match. A candidate that only partially overlaps the subtitle — "meal prep" against "Meal Planner," say — survives. I leave that judgment to my own eyes, asking whether the term gets searched on its own.

Design a Separate Field for Each Locale

This one is easy to overlook and pays off well. App Store Connect gives you a separate keyword field for every localization your app supports. The Japanese field and the English (U.S.) field are two independent 100-character canvases.

When you localize a Rork-built app, leaving those fields blank or pasting the English list into them throws away a hundred characters per locale. For each one I adjust three things:

• Refill with the words that market actually types — not translations. "Split bill" is the phrase in English-speaking stores; other regions have their own
• Re-read autocomplete with the storefront switched — the suggestions change with the region, so I collect them again per locale
• Watch currency and unit words — for anything money-related, local currency names show up in queries

The script above works unchanged per locale: swap name, subtitle, and candidates, run it again. Starting with your top two or three locales is realistic; trying to do all of them at once is how I ended up doing none of them.

What to Do After You Change the Field

Editing the keyword field doesn't affect ranking immediately. The change ships with a new version, so the order of operations matters:

• Submit it alongside a new version — until that version is approved, search keeps running on the old keywords
• Watch impressions daily for one to two weeks — App Store Connect Analytics shows impressions and units; if they drop, a term you added may be doing harm
• Save the before and after lists in a spreadsheet — knowing what you changed and what moved is what makes the next revision a decision rather than a guess

Search behavior shifts gradually, so revisiting every three to six months is reasonable. You're not chasing a perfect field, just one slightly better than the last. I ended up folding it into every minor update that already needed a review submission: swap one or two words, submit, move on. The overhead is close to zero that way.

Common Mistakes, Each With Its Fix

• Repeating app-name words in the keyword field → Delete them and spend the freed characters on autocomplete-derived terms
• Spaces after commas → Strip every one and re-pack; this alone often buys a term or two
• A single spelling for each important word → Add one or two variants in markets where scripts or spellings vary
• One keyword list copied across every locale → Redesign at least the top two or three locales individually
• Swapping words without measuring → Keep before/after lists and compare them with the impression trend in Analytics

None of these takes more than an evening. They aren't dramatic fixes, and I've come to believe that's exactly why they compound.

The Next Thirty Minutes

Tonight, before bed, open your listing in App Store Connect and read the keyword field once. Delete any word that already appears in the name or subtitle. With the freed characters, add one or two autocomplete suggestions from the search bar. That alone is often enough to change your search installs.

Rork has shortened the time it takes to build an app, which leaves room for this kind of small, compounding work. I open those hundred characters once on every release and read them through — that habit is the one I keep even in busy weeks.

If you'd like to take ASO further, Making a Rork App Sell on the App Store — ASO, Pricing, and IAP Strategy covers the wider picture, and Linting ASO Keywords Across Locales — Protecting Apple's 160-Character Search Budget extends the same thinking to every locale. For the growth phase right after launch, Rork: From Launch to Your First $1,000 — ASO, Pricing, and Launch Marketing Playbook picks up where keyword design leaves off.