The App Store subtitle is 30 characters, indexed for search, and needs a new build to change. Promotional text is 170 characters, not indexed, and can be updated any time without a release. The keyword field is 100 characters, invisible to users, and indexed. On Google Play the short description is 80 characters and is indexed, so it does double duty as both a search asset and a conversion line.
Which fields actually affect search?
Most indie developers fill these fields in once during submission, never touch them again, and lose steady traffic for years without noticing. I've done it myself on two apps, and on one of them the promotional text still described a feature that had been removed.
The confusion is understandable. Four short text fields that all look like taglines, with no indication in the interface of which ones do what.
Only some of them feed search. Only some of them can be changed without a release. Getting those two facts straight is most of the value here, so let me lay them out properly before talking about how to write them.
What does each field do?
App Store promotional text, 170 characters. Appears above the description, and here's the important part: it is not indexed, and it can be changed at any time without submitting a build. That combination makes it a completely different tool from the subtitle.
App Store keyword field, 100 characters. Comma separated, invisible to users, purely for the algorithm. Requires a new build to change.
App Store description, up to 4000 characters. Not indexed on the App Store, which surprises people. It is there to convert someone who is already reading, not to help them find you.
Google Play short description, 80 characters. Indexed, and shown prominently. It has to work as both a search asset and a persuasive line, which is a harder brief than anything on Apple's side.
Google Play full description, 4000 characters. Unlike Apple, this one is indexed. So the same text does very different jobs on each store, and copying one to the other wastes an opportunity on Play and clutters the App Store.
That asymmetry is the single most useful thing to internalise. Apple indexes short fields, Google indexes long ones. Apple's product page guidance covers the field definitions if you want the source.
How should you write the subtitle?
The mistake I see most is using it as a slogan. "Simple. Beautiful. Yours." is thirty characters of nothing. It ranks for no useful terms and tells a browsing user nothing about what the app does.
The better pattern is a compressed benefit that also contains a term people search. "Scan receipts and track VAT" tells a human what it does and puts real query words in an indexed field.
Do not repeat words from your app name. Apple indexes the name and the subtitle together, so repeating a word wastes characters that could have covered another term. If your app is called Receipt Scanner, the subtitle should not contain "receipt scanner".
Same logic applies between the subtitle and the keyword field. Duplication across indexed fields is wasted space. Treat all your indexed characters as one shared budget and cover as many distinct terms as you can.
Avoid the words Apple ignores anyway. Category names you're already listed under, and the word "app" itself, are usually not worth the characters.
A worked example helps. Say you're shipping a habit tracker.
Weak: "Build better habits daily" is 25 characters of pure slogan, ranking for almost nothing.
Better: "Habit tracker with streaks" is 26 characters, contains the category term people actually type, and still reads as a description rather than a keyword list.
Best if your name already says "habit": "Streaks, reminders and stats" spends every character on terms the name doesn't already cover.
I'd write five candidates, count the characters, and pick the one that reads naturally when a stranger says it aloud. Cramming keywords produces subtitles that rank slightly better and convert noticeably worse, and conversion is the thing that compounds.
What is promotional text actually for?
Because it isn't indexed, there is no reason to put keywords in it. Because it can be changed without a build, it is the only field on your product page that can respond to something happening this week.
Good uses:
Announcing what's in the version that just shipped, so returning users see it immediately.
Running a seasonal message. A sale, a holiday theme, an event tie-in.
Answering a complaint that's showing up in recent reviews. If three reviews this month say the export is confusing, promotional text saying "Now with one tap CSV export" addresses it at the point of decision.
Testing messaging cheaply. Change it, watch the conversion rate, change it back. It isn't a proper A/B test since you're comparing across time rather than simultaneously, but it costs nothing and it's directionally useful when the effect is large. For actual controlled testing, that's what the A/B testing guide covers.
The failure mode is leaving it empty or leaving it identical for two years. An empty promotional text field means your description's first lines get pushed down for no reason, and a stale one signals an abandoned app to anyone paying attention.
I've started treating it as a release checklist item rather than a marketing task. Every time a build goes out, the promotional text gets read and either updated or deliberately kept. That takes about ninety seconds and it stopped mine from rotting, which is the entire problem it needed solving.
The other habit worth adopting: keep the previous versions in a note somewhere. When you change it and conversion moves, you want to be able to go back to exactly what was there before rather than reconstructing it from memory.
How does Google Play differ?
The 80 character short description is indexed and prominent, so it carries both jobs at once. It needs to contain your primary term and read as a compelling sentence. That's genuinely harder than Apple's split of subtitle and promotional text, where each field does one job.
The full description being indexed changes everything about how you write it. On Play, natural repetition of your important terms across 4000 characters helps. On Apple, that same repetition is pure clutter that nobody reads.
Note "natural" there. Keyword stuffing gets punished on Play and reads badly to humans. Aim for terms appearing where a normal writer would use them, a handful of times across the whole text, not a list.
Play also gives you Store Listing Experiments, which is proper simultaneous A/B testing built into the console, including for text. Apple has Product Page Optimization for a similar purpose. If you're going to test anything, test the short description on Play first, because it's the most valuable indexed field you can change without a release.
None of this text work matters if the visuals fail first, though. People look before they read, and a listing with weak screenshots won't be saved by a well written subtitle. If the images aren't doing their job yet, start with the design mistakes checklist, get the frames right in the device library, and build the set in the studio before you spend an afternoon on thirty characters of text.
Frequently asked questions
Is the App Store subtitle indexed for search?
Yes, words in the subtitle count toward what you rank for, and it also appears in search results so it does conversion work too. Changing it requires shipping a new app version, which makes it the highest stakes text field on your product page.
Is promotional text indexed on the App Store?
No, and that's the point of it. Because it isn't indexed there's no reason to put keywords in it, and because it can be changed without submitting a build it's the only field that can respond to something happening this week, like a sale or a fix mentioned in recent reviews.
Should the subtitle repeat words from my app name?
No. Apple indexes the name and subtitle together, so repeating a word wastes characters you could have spent covering another search term. The same applies between the subtitle and the keyword field, since duplication across indexed fields is wasted budget.
Is the App Store description indexed?
Not on Apple's side, which surprises a lot of developers. It exists to convert someone already reading. On Google Play the full description is indexed, so the same text does completely different jobs on each store and shouldn't just be copied across.
How long should a Google Play short description be?
Up to 80 characters, and you should use most of them. It's indexed and prominently displayed, so it has to contain your primary search term and read as a persuasive sentence at the same time. That dual job makes it harder to write than anything on Apple's side.
Which text field should I test first?
The Google Play short description, since it's the most valuable indexed field you can change without a release, and Store Listing Experiments lets you test it properly. That said, visuals are read before text, so fix weak screenshots first using the [design mistakes checklist](/blog/app-screenshot-design-mistakes-fix-fast-2026).
Build the mockup in your browser.
Drop a screenshot into a real device frame and export at the exact store size — free, no signup.