Writing store copy that survives review

The check, in a minute

# other-platform references anywhere in metadata and in-app strings
grep -rniE 'android|google play|play store|samsung|pixel|windows' \
  fastlane/metadata store src app 2>/dev/null | head -20

# unsubstantiated claims
grep -rniE '#1|number one|the best|world.?s (best|leading)|[0-9,]+\+? (users|downloads|customers|reviews)|as seen (in|on)|clinically proven|guaranteed' \
  fastlane/metadata store 2>/dev/null | head -20

# competitor marks
grep -rniE '(jobber|housecall|uber|tinder|hinge|bumble|calm|notion|duolingo|mint)' \
  fastlane/metadata store 2>/dev/null | head

# character limits: name and subtitle are 30 each, keywords 100
wc -m fastlane/metadata/en-US/name.txt fastlane/metadata/en-US/subtitle.txt \
      fastlane/metadata/en-US/keywords.txt 2>/dev/null

The last one catches a rework rather than a rejection. A name or subtitle over 30 characters is refused at save time, which is cheap if you notice before writing the whole listing around it and expensive afterwards. App Store Connect first-time setup.

The fields, and what each is for

Name (30). The strongest single ASO signal and what people say when they recommend you. Do not spend all thirty characters on keywords.

Subtitle (30). What the app does, as a fragment. Not a slogan.

Keywords (100). Comma separated, no spaces after commas, because spaces consume characters. Do not repeat words already in the name, subtitle or category — they already index and repeating them wastes the field.

Description. The first two lines are what most people read. Lead with what it does and who it is for; the rest is for someone already interested.

Promotional text. The only field that changes without a review, which is where anything time-sensitive belongs.

What good copy looks like

Concrete, specific, and true:

Every noun in that is checkable. Compare with the version that gets written instead:

Four problems in three sentences: an unsubstantiated superlative, an unsubstantiated user count, an implied guarantee about an outcome Apple controls, and nothing that says what the app does.

The second version is also the one nothing can recommend, because there is no sentence in it that distinguishes the product from any other. Guideline 4.3, spam.

Two things worth stating positively

Say what it does not do. A listing that names its limits reads as credible and heads off the review question about a feature a reviewer cannot find.

Say who it is not for. Costs you nothing in installs that would have converted and saves you a category of one-star reviews from people who bought the wrong thing.

Where it gets reported

Metadata problems usually arrive as Guideline 2.3 findings with the offending text quoted, and sometimes as 2.3.10 specifically. Trademark issues arrive as 5.2, occasionally after release when a rights holder complains rather than at review. Guideline 5.2. · When your app is removed.

And remember the timing rule: name, subtitle, keywords, description, screenshots and previews all need a submission and review to change. Attach every metadata change to a build you are already submitting. After a rejection.

shipcheck scans listing metadata and in-app strings for other-platform references, unsubstantiated claims and third-party marks, and reports the character counts against the limits. What it checks. · The first-submission checklist.

Questions and answers