Your App Title Is a Budget, Not a Billboard
Your title and subtitle are the highest-value indexable fields you own, and this piece argues they should be budgeted for being found before being tapped, with the trade-offs, misreads, and a way to verify.
Open a store category page and squint: soon every name blurs into professional, smart, all-in-one. That is what most teams do with the highest-value indexable field they own — turn it into a signboard, brand name first, adjectives after it. I think that is a waste; here is what we do instead. Field lengths and weight rules change, so check the official documentation for the current rules rather than trusting any number I give.
The short version
A title and a subtitle are one small shelf paying two rents at once: one to the machine, which wants the words people type placed where they count, and one to a human scanning a crowded list, deciding in a glance whether to tap. Both come out of the same tiny budget, so there is only a trade, and we spend it in a fixed order — found first, then whatever is left to make the line worth tapping. **We don't recommend treating the brand name as a free pass**: if nobody searches for your name yet, its slot is pure cost.
Two different jobs hiding in one line
Most confusion starts because people treat getting found and getting tapped as one job, when they pull against each other. Getting found is a machine problem: the store reads your indexable text and cares only whether the right words are there and how early they appear — title and subtitle are usually the heaviest fields, though I put no number on it, so check the official documentation for the current rules. Getting tapped is a person problem: one of a row of icons, a name and a short line, and concrete information wins, while adjectives get skipped because everyone uses the same handful.
Treat the character budget like cash
Call it a pile of coins instead of an input box; every coin should buy something, and professional, powerful, all-in-one buy nothing, since almost nobody types them into a search box or installs an app because of them. A phrase someone genuinely types buys a chance to be surfaced, a clause saying what changes for the user buys a chance to be tapped, and repeating one word in both the title and subtitle is paying twice — we don't recommend it; when the budget is tight I cut adjectives first, duplicates second, and only then awkward words that still pull search.
What goes in the title, and what goes in the subtitle
I keep the title formulaic: if the brand name is already something people search for it goes first, because the name *is* the keyword, one coin doing two jobs; if not, I move it back and give the opening slot to a word that says what this thing is. As for casing, how much fits, and which positions are indexed, check the official documentation for the current rules — and the rule I stand behind is that **the earlier a character sits, the more it ought to be something a person would type, not something you want to shout.** The subtitle is a second shelf, and the one thing it must never be is an echo: anything used in the title does not go here, so use an adjacent phrase that did not fit above, or one readable clause telling someone what they get by tapping in.
How we actually write one
We don't start with a sentence; we start with a list of every phrase a person might type, then filter twice — first we cut the words we love internally and users never say, painful because those sound most like "the brand", then we rank by intent so phrases from someone clearly looking for this kind of thing go to the front — and only then do we build a line, words first, sentence second, changing the glue rather than the keywords if it reads stiff.
The mistakes we keep seeing
**Adjectives counted as keywords.** Words like professional or powerful feel weighty to the writer, but almost nobody searches them. **Filling the whole line with brand.** Unless the name is already a search term, pure brand hands the shelf to a word nobody is looking for yet. We don't recommend it. **Deleting keywords to make the sentence smoother.** Smooth is for people; keywords are for the index, so when they clash I keep the keyword and rewrite around it.
One store at a time, and how to tell if it worked
First, the stores do not eat the same meal: some split title and subtitle into two clean fields, others put the editable short copy elsewhere; some lean mostly on the title line, others pull in the subtitle and additional editable fields too — what the fields are called, how much they hold, and how they are weighted differs and changes, so check the official documentation for the current rules. So **one store at a time**, and in a different language market we redo the word list instead of translating.
Judging off a single number turns a normal trade-off into a fake win or loss, so leave a long enough window on both sides and change one variable at a time; what split-testing the consoles support differs, so check the official documentation for the current rules.
What to do next
1. Write your current title and subtitle down and, for each word, ask whether anyone would type it or tap because of it; circle whatever fails both. 2. Rebuild the list of phrases people really type, rank by intent, place the top ones by the rule that earlier characters should be searched words, and cut anything repeating across fields. 3. Pick one store, change one field, keep a long enough window on both sides, read the found-and-tapped numbers together, and check the official documentation for the current rules before you start. 4. Make this a recurring review rather than a one-off fit-out, and rebuild the word list from scratch for each language market instead of translating.
Want your app to rank for the keywords that matter?
Get a Quote