The three text fields and what each one does
App Store Connect has three text fields that appear on your product page. They look similar but behave very differently:
| Field | Limit | Keyword indexed? | Changeable without review? | Visible where? |
|---|---|---|---|---|
| Subtitle | 30 chars | Yes | No (requires binary) | Below app name in search results and product page |
| Promotional text | 170 chars | No | Yes | Above the description on product page; collapsed behind "more" |
| Description | 4,000 chars | No | No (requires binary) | Product page, collapsed behind "more" after ~3 lines |
The most important thing on this table: neither the description nor the promotional text is keyword-indexed on iOS. Filling your description with keywords does nothing for App Store Search ranking. Google Play indexes the full description — but on iOS, keyword research belongs in your app name, subtitle, and keyword field only. See the App Store keywords guide for where those 100 characters should go.
The subtitle: your most valuable text real estate
The subtitle is indexed for search and visible in search results — both properties that make it the highest-leverage text field after the app name. Yet most developers either leave it vague ("The app for everything") or treat it as a tagline ("Make your life better").
A subtitle that's working hard looks like this: it uses 25–30 of the available 30 characters and puts the most searchable descriptive terms there. For a habit tracker: "Daily streaks & reminders" uses the search terms "daily", "streaks", and "reminders" while reading naturally to a user. That's three additional indexed terms in 30 characters.
The subtitle appears directly below your app name in search results — it's the second thing a user reads before deciding whether to tap. It should describe what your app does concretely, not how it makes you feel. "Track habits, build streaks" converts better than "Your best self, every day."
Since changing the subtitle requires a new binary submission, treat it like the keyword field: update it intentionally alongside feature releases, not reactively.
Promotional text: the field most developers ignore
Promotional text sits above the description on the product page, before the "more" collapse. It's the first prose a user reads after the screenshots. And unlike every other text field, it can be updated at any time without submitting a new binary for review.
This makes it uniquely useful for:
- Time-sensitive messaging: "Now with iOS 18 widgets" or "Updated for iPhone 16" — relevant today, irrelevant in 6 months. Swap it without waiting for review.
- Seasonal campaigns: "50% off Pro through December" during a sale period, then swap back after.
- New feature announcements: call out a major new feature immediately on launch without waiting for a full metadata update to clear review.
- A/B testing messaging: try different value propositions and observe conversion rate changes in App Store Connect, then keep what works.
170 characters is roughly two short sentences. Lead with the strongest, most specific claim you can make: what your app does for the user right now, in concrete terms. "The fastest way to build a daily habit — streaks, reminders, and a 21-day challenge. No account required." is 103 characters and does real work.
The description: writing for users who are already interested
By the time a user taps "more" to read your full description, they've already seen your icon, name, subtitle, screenshots, and ratings. They're interested. The description isn't converting cold traffic — it's addressing the final questions of someone who's already considering installing.
Write the description for that reader, not for search bots (it's not indexed) and not for a first impression (they've already formed one).
The fold problem
On iPhone, roughly the first 3 lines of your description are visible before the "more" button. On iPad, more lines show before collapsing. Design your description for the fold: the first 255–280 characters need to stand alone as a complete pitch, because most users never tap "more."
Common mistake: starting the description with "Welcome to [App Name]!" or "Thank you for checking out our app!" — this wastes the only visible lines on pleasantries. Start immediately with what the app does and who it's for.
Structure that works
A description structure that consistently performs:
- Lead (above fold, ~255 chars): One strong paragraph stating what the app does, who it's for, and the primary outcome. "Habit Builder helps you track daily routines and build streaks that stick. Set a goal, log each day, and watch your streak grow — no complex setup, no account required."
- Feature list (below fold): 5–8 bullet points, each starting with the feature name in bold or caps, followed by the benefit. "DAILY REMINDERS — Set a custom time and never miss a day." Not "We have reminders for your convenience."
- Social proof or context (optional): "Used by over 50,000 people to build lasting habits." Only include if the number is real and meaningful.
- Privacy and technical notes (bottom): no account required, iCloud sync, Apple Health integration, etc. Users who care about these things scroll down looking for them.
What not to do
- Don't keyword-stuff. "habit tracker daily habit tracking habits track your habits habit journal" reads as spam and does nothing for ranking.
- Don't use markdown. The App Store description doesn't render markdown — asterisks and hashes appear as literal characters. Use ALL CAPS for section headers if you want visual hierarchy; it renders consistently.
- Don't promise features you don't have. Guideline 2.3.3 applies to the description too — Apple can reject for misleading feature claims.
- Don't write a novel. 4,000 characters is the limit, not the target. 600–900 characters of strong, specific copy outperforms 3,000 characters of padded feature descriptions.
How description and screenshots tell the same story
Your screenshots and description should reinforce each other, not duplicate each other. The screenshots show the interface; the description explains what it means for the user. A screenshot captioned "Track every habit" and a description bullet that says "HABIT TRACKING — track every habit" are saying the same thing twice. Better: the screenshot caption says "Build a streak that sticks" (outcome) and the description bullet says "FLEXIBLE TRACKING — log once a day or multiple times, your streak adjusts" (mechanism).
Think of the product page as a funnel within a funnel: the screenshot set converts most users; the description converts users with questions the screenshots didn't answer. The two assets do different jobs for different user segments.
ezscreenshots handles the screenshot side of that equation — drop in your Simulator screenshot, add the outcome-focused caption, export at the correct dimensions. The design decisions that make screenshots convert — caption placement, font weight, background contrast — are covered in the App Store screenshot template guide.
Google Play differences
On Google Play, the description is keyword-indexed and affects search ranking. The short description (80 chars) shows in search results and on the store page — it plays the role of the iOS subtitle. The full description (4,000 chars) is indexed, so keyword placement in the first 250 characters matters for Play Store ranking.
If you're maintaining listings on both platforms, the core messaging can be the same, but the optimization strategy differs: on iOS, put keywords in name/subtitle/keyword field; on Play, put them in the short description and early in the full description.
Your description converts users who read it. Your screenshots convert everyone else.
Most users decide from the screenshots alone. ezscreenshots makes it fast to create a screenshot set with outcome-focused captions at the right dimensions. Free, no account needed.
Try ezscreenshots →Summary
- Three separate fields: subtitle (30 chars, indexed, visible in search), promotional text (170 chars, not indexed, changeable without review), description (4,000 chars, not indexed on iOS)
- Description is not keyword-indexed on iOS — put keywords in name, subtitle, and keyword field instead
- Subtitle is your second-most-valuable keyword field — use all 30 characters on descriptive terms, not taglines
- Promotional text is the only field you can update without a review submission — use it for time-sensitive messaging, sales, and new feature calls
- Design for the fold: the first ~255 characters are visible before "more" — lead with a concrete description of what the app does and who it's for
- Description structure: lead paragraph (above fold) → feature bullets → optional social proof → technical notes at the bottom
- Screenshots and description do different jobs: screenshots convert on visual impact; description answers the remaining questions of users who are already interested
- Google Play differs: description is indexed for search on Play — keyword placement in the full description affects Play Store ranking