App title is widely held to be the highest-weighted ASO factor — though neither Apple nor Google publishes a weighting for any metadata field, so treat that ordering as practitioner consensus rather than documented fact. App Store gives 30 characters; Google Play gives 50. Bad patterns: brand alone (loses keyword opportunity), keyword stacking (Apple rejection risk), generic descriptors (no differentiation). The fix is brand + one primary keyword pattern, properly localised, A/B tested. See the App Audit hub for the full ASO program.
App Store: 30 characters
Google Play: 50 characters
Both: brand + benefit keyword pattern works
symbols (• – :) eat characters; use sparingly
Bad: "Acme" (brand only, no keyword) Bad: "Acme - Best CRM Sales Pipeline Lead Tracker Tool" (stacking, rejection risk) Good (iOS): "Acme: CRM & Lead Tracker" (30c) Good (Play): "Acme: CRM, Lead Tracker & Sales Pipeline" (50c) Pattern: Brand : Primary Keyword + Secondary The primary keyword is what users search for your category.
Tools to research (varies by region): - App Store Connect (Apple) — search popularity - Google Play Console — keyword reports - Third-party: Sensor Tower, Data.ai, AppTweak, AppFollow For each candidate: - Search popularity (volume) - Chance you rank (your authority vs competitors) - Conversion intent (does the keyword match what your app does) Pick the keyword that maximises (volume × chance × intent).
Each locale gets its own title (App Store / Play both support). Don't use machine translation — keyword research differs per market: US: "Lead Tracker" common, high-volume UK: "Lead Tracker" common but lower volume DE: "Vertriebs-Tracker" would research locally ES: "Gestor de leads" would research locally Per-locale ASO drives non-English market growth 2-4x.
App Store Connect (iOS 15+) and Google Play Console both support title experiments. Run for minimum 7 days to clear weekly variance. Look at install-per-impression conversion, not just downloads. Title changes can have negative impact even when the change "looks better".
You will read that the title is the highest-weighted ASO factor, the subtitle second, the keyword field third. That ordering is practitioner consensus, inferred from observing apps — neither Apple nor Google publishes a weighting for any metadata field, and both adjust silently.
That is not a reason to disregard it. It is a reason to lean on mechanisms you can verify rather than rankings you cannot, and the mechanisms are more than enough to justify the effort:
Those three facts, none of which requires knowing a weighting, produce every piece of good advice on this page. And where a decision genuinely turns on relative weight, both stores let you settle it with a split test instead of a debate.
Section 4 lists keyword stacking as a rejection risk, and it is worth pressing on why, because the instinct imported from web SEO is that over-optimisation is merely wasteful.
On the web
- Keyword stuffing is largely ineffective
- The cost is a worse page
- Nobody rejects anything
On the App Store and Google Play
- Metadata policies prohibit repetitive, irrelevant
or misleading keywords
- Enforcement is by review — human, immediate
- The cost is a rejected submission or a pulled listing
So "Acme - Best CRM Sales Pipeline Lead Tracker Tool" is not a title that will underperform. It is a title that may not ship, and finding that out during a release window is expensive in a way no ranking loss is.
The standard advice — brand first if the brand is known, keyword first if it is not — is correct, and teams reliably answer the underlying question wrong, because they answer it about themselves rather than about their users.
The question is not whether your brand is good. It is whether anybody is typing it. Those are entirely different facts, and only one of them is checkable.
Check before you decide:
- Branded search volume in App Store Connect
- What share of your installs already come from
people searching your name
- Whether anybody outside your industry has heard of you
If the honest answer is that nobody searches for you by name, brand-first spends your most valuable characters — the ones seen first, everywhere, by everyone — on a word nobody is looking for. That is not a branding decision; it is a rounding error in your acquisition funnel dressed up as one.
And the decision is testable. Both stores support title experiments. A fortnight of real traffic replaces a quarter of internal argument, and it is the rare test whose result nobody can dispute afterwards.
The limit gets treated as a compression exercise: take what we want to say, and squeeze. That framing produces the abbreviated, symbol-strewn titles that fill the store.
Thirty characters is about four or five words. It is not room to describe an app. It is exactly room to say what the app is — and when a team cannot, the limit is not the problem. The problem is that nobody has decided.
That is why title debates become so heated: they are product debates wearing a copywriting costume. The argument about whether "pipeline" or "leads" goes in the title is an argument about what the product is for, and it is worth having on those terms.
One mechanical note, since it costs people characters they never notice losing: separators and symbols consume the budget like any other character. A bullet, a dash and two spaces are four characters gone — more than a tenth of the field — spent on punctuation rather than on a word anybody might search for.
Both stores allow title changes, and the mechanics are the easy part. The judgement is knowing what you are giving up.
What a title change costs
- Review time (Apple reviews; plan for the delay)
- Recognition: people who installed you before may
not find you again by the name they remember
- Word of mouth: everything anyone has ever written
about your app uses the old name
- Any keyword equity the old title had accumulated
That last one is the reason to be careful rather than fearful: a title that has been ranking for a term for two years is holding a position that a new title starts from scratch on. Swapping it is not a free experiment, and the recovery is measured in weeks.
So the sane rule: change the keyword portion freely and test it, and change the brand portion almost never. The keyword is a hypothesis you are entitled to revise. The brand is the thing people say to each other, and it does not survive being A/B tested.
The title deserves its reputation, and it is worth being clear about what it does and does not decide, because teams routinely rewrite it while leaving the assets that actually convert untouched.
The title decides: - Which searches you can appear in - Whether a person understands you in one second The title does NOT decide: - Whether they install (screenshots and rating do) - Whether they stay (the app does)
This matters because store ranking is partly fed by conversion — people who search a term, tap your listing, and install tend to lift you for that term. So the title earns the impression, and the screenshots convert it, and the conversion feeds back into the ranking that produced the impression.
Which means a perfect title in front of weak screenshots is a leak in a loop: you buy impressions with your keyword work and fail to convert them, and the failure to convert quietly costs you the ranking the keyword work bought. Fix the title, then fix the first two screenshots, and the loop starts compounding instead.
Brand first when brand is well-known (people search for it). Keyword first when brand is unknown (you need keyword exposure). For most apps starting out, keyword first works better; established apps lead with brand.
Yes, both stores allow it. Apple reviews changes; Google approves automatically. Plan for 24-72h review on Apple. Don't change too often — store algorithms penalise instability.
Yes — highest-weighted ASO factor. A relevant keyword in the title genuinely moves category rank, and the specific position figures quoted around the web come from vendor case studies on other apps rather than from anything either store publishes. Measure your own with a split test. Conversely, removing the keyword can drop rankings shaions. Conversely, removing the keyword can drop rankings sharply.
30 characters hard limit. Apple truncates with ellipsis in search results around 25 characters depending on device. Front-load the most important keyword.
It is the practitioner consensus, and neither Apple nor Google has published a weighting for any metadata field — so the ordering is inferred from observation rather than documented. Hold it loosely and prefer the mechanisms you can verify: the title is indexed, it is the first thing a person reads, and it appears everywhere your app is shown including places where nothing else does. Those facts justify treating it as your most important field without needing to know a number nobody has published.
Risky. This is the point where habits imported from web SEO become expensive: on the web, keyword stuffing is mostly self-defeating, while Apple's App Review Guidelines and Google Play's store listing policies both prohibit metadata that is repetitive, irrelevant or misleading — and they are enforced by review. The outcome is a rejected submission or a pulled listing, not a slow ranking decline. The feedback is immediate, it comes from a human, and it arrives at the worst point in a release cycle.
By asking what people type. If they search your brand name, brand-first is correct and the keyword is a bonus. If nobody has heard of you, brand-first spends your most valuable characters on a word nobody is searching for, and the keyword should lead. The honest version of that question is uncomfortable for most teams: check your branded search volume before assuming anybody is looking for you by name. And do not guess — both stores let you split-test the title, which turns an opinion into a number in a fortnight.
Get full ASO recommendations across title, subtitle, screenshots.
Run App Audit →aiwebpageseo.com is a data-driven SEO and AEO (Answer Engine Optimisation) platform providing a free suite of technical website tools. Rather than relying on AI-theorised assumptions, the platform analyses live URL performance, delivering objective diagnostics, page speed metrics, CLS debugging, and site crawl data alongside actionable technical tutorials.