Writing for Play versus iOS

Expert: with sources and numbers. Plain: the same, without them, for beginners.

Why the same copy cannot serve both stores. Not because of character counts, but because the indexed text does opposite jobs.

Verified 2026-09-19 · 38 days ago both metadata keywords localisation

The character limits are the least important difference. Copy fails when it moves between stores because the indexed text is doing a different job.

The difference that matters

On iOS, the indexed text is mostly hidden. A Apple’s text-relevance inputs are title, subtitle, keywords and primary category, and the keyword field is invisible to users. The description is not named as a search input. (App Store search, verified 2026-09-18)

On Play, every indexed field is visible. A Google identifies apps from metadata including title, description and category. (App Discovery and Ranking, verified 2026-09-18) There is no hidden field.

So:

  • iOS separates the two jobs. Terms go in the keyword field where nobody reads them. Visible text is free to persuade.
  • Play combines them. Every term you want indexed sits in text a human reads. The description must rank and read at once.

That is the whole problem. Everything below follows from it.

What this changes in practice

The description. On iOS, write it for the reader. It is a conversion asset. On Play, it is the main indexed body text and a conversion asset, so it needs natural coverage of how people describe the problem, in prose someone will actually read.

Term repetition. On iOS, repeating a word across fields is waste, the store combines terms across fields (30-04). On Play, B frequency appears to carry some weight, but A Google explicitly warns against “repetition of words” and publishes a keyword-list example of what not to write (Best practices). The answer on Play is natural use, not counting.

Field mapping. There isn’t one.

iOS Play Why it does not transfer
Subtitle, 30 chars Short description, 80 chars Different length, position and job. CONFLICT-003
Keyword field, 100 characters nothing No hidden field exists on Play
Description, 4,000, not a search input Full description, 4,000, indexed Same size, opposite function

Two mistakes, symmetrical. Writing iOS copy the Play way produces a keyword-dense description that does nothing for iOS search and reads badly. Writing Play copy the iOS way produces a description that reads well and leaves Play’s main indexed field carrying no relevant terms.

The claim that comes from crossing the wires

C “The first 245 characters of the description are crucial.” Asserted for iOS reviewed here, where it is wrong twice over: Apple does not name the description as a search input at all, so no part of it is established as indexed.

Its likely origin is Play, where the visible portion before “Read more” genuinely does matter. But as the text that earns the expand, not as a magic character count. Full history in CONFLICT-002.

How to work with it

Write each store’s copy from the same brief, not from each other’s output. Agree positioning, proof points and priority terms once. Then write twice.

Do keyword research once, apply it twice differently. The terms people search are largely the same. Where they go is not: iOS hides them, Play shows them.

Never translate iOS copy into Play copy or the reverse. Not across stores, and not across languages, 30-05.

Schedule them separately. iOS indexed text batches to the release; Play does not (20-07).

What goes wrong

One copy deck for both stores. Produces text that is wrong for at least one of them.

Assuming length equivalence means field equivalence. Both descriptions are 4,000 characters and they do opposite things.

Carrying a Play habit onto iOS. Keyword-dense descriptions are effortful and, on iOS, inert.

Carrying an iOS habit onto Play. A beautifully written description with no relevant terms leaves Play’s main indexed field empty of meaning.

In short

Every fact on this page in one line, with its evidence tier, source and verification date, 4 A · 1 B · 1 C. Generated from the claim register, so it cannot drift from the page above.

A App Store search results are based on text relevance (matches for title, subtitle, keywords and primary category) and on user behaviour including downloads, ratings and reviews.
IOS-RANK-001 · verified 2026-09-18
A Google advises avoiding excessive length, detail, improper formatting and repetition of words in the full description, and publishes a keyword-list example of what not to write.
PLAY-MD-004 · verified 2026-09-18
A Google Play's Metadata policy prohibits misleading, improperly formatted, non-descriptive, irrelevant, excessive or inappropriate metadata, and repetitive or unrelated keywords or references.
PLAY-POL-003 · verified 2026-09-18
A Google states Play discovery and ranking are determined by user relevance, app quality, editorial value, advertising, and user experience on Google Play, weighted differently by surface: top charts emphasise popularity, search emphasises relevance.
PLAY-RANK-001 · verified 2026-09-18
B Google Play weighs term frequency in the full description to some degree.
PLAY-DENS-001 · verified 2026-09-18
C The first 245 characters of the iOS app description are 'crucial' for keyword optimisation.
IOS-DESC-001 · verified 2026-09-18

Think your app deserves better?

Send the App Store link.
The audit comes back within two working days, whether you hire us or not.

Free, and we mean it. No card, no call required.