Preparing your store listing

Every app needs a listing: the name people see under the icon, the description, the categories, a privacy policy, and — for a members-only community — an account the reviewer can sign in with. Store submission collects all of it in one place and checks it against each store’s rules as you type.

Open it from your app’s page: Store submission → Prepare listing.

Why it is not just a form

The two stores disagree about almost everything, and the differences are the kind that cost a rejection rather than a warning:

	App Store	Google Play
Name	30 characters	30 characters
Subtitle	30 characters	—
Short description	—	80 characters
Description	4000, plain text only	4000, limited HTML allowed
Keywords	100 characters, comma separated	no such field
Promotional text	170 characters	—

The page draws each field from the store you are on, so you never fill in a box that store will ignore, and the character counter is the store’s real limit.

Keywords count their own commas

Apple counts the whole keyword string against 100 characters — the commas included, and a space after a comma is a character like any other. Typing the list the way you would punctuate a sentence quietly costs you a keyword or two.

Memberside removes those spaces when you save, and counts the shortened version. So this:

clubs, events, members, forum

is stored and counted as:

clubs,events,members,forum

HTML is allowed on one store and not the other

Google Play renders a small set of tags in the full description. The App Store renders none of them — it shows <b>bold</b> as those literal characters. So the same paragraph is accepted on one store and rejected on the other, and the page tells you which you are writing for.

Drafts are saved half-finished

You can save at any point. Required fields you have not filled in are not a save error — they appear in the checklist above the form as things to fix before you submit. A listing is written over days, and a form that refuses to keep a half-finished draft is a form people abandon for a spreadsheet.

The checklist

Above the form is a list of everything that would stop this app being accepted, worked out from your app’s own configuration rather than from a generic checklist. It is in three levels:

Blocking — a store would reject this, or the app is broken as configured.
To check — likely to be asked about. The answer may well be fine.
Ready — checked and satisfied.

What it can prove for you

Apple asks the same questions of every community app, and your app usually already has the answer. Where a feature you placed satisfies a guideline, the checklist says so and names the screen:

✓ Members can report objectionable content In “Community Feed”, members report a post or a comment from the ⋯ menu beside it. Reports go to your site’s moderators.

✓ Members can delete their own account In “My Account”, members delete their own account from the Delete tab, confirmed with their password.

Those same sentences go into your review notes, so a reviewer gets the answer before they ask.

It only claims what the app can actually do. BuddyPress Activity has no report action, so an app whose only feed is BuddyPress gets a warning rather than a tick — a claim a reviewer disproves in one tap is worse than no claim.

It suggests what would fix the rest

Where something is missing, the row offers the thing that would satisfy it — a feature to place, or a plugin to install:

⚠ Published terms and a moderation commitment ➕ Single Page — point it at your terms page so the terms are reachable inside the app 🧩 Ultimate Member — AI Moderation — filters spam and harmful content automatically

Plugins you already have are not suggested. If your site cannot be reached, or the account you connected is not an administrator, every suggestion is shown rather than none — the same way the builder’s feature list behaves when it cannot check.

What it cannot answer for you

Some things are genuinely yours: whether someone reads the report queue, and what you sell. The checklist says so plainly rather than guessing, and the generated notes leave a bracketed prompt where your answer belongs.

The reviewer’s account

If any screen in your app is visible only to signed-in members, review needs a working account or they will reject the app as unusable. Enter one under Store details.

Make it a real member account on your own site, with whatever roles the restricted screens need. The checklist warns you when a screen is restricted to a role, because a reviewer who signs in without it sees a restriction message and reports the screen as broken.

When it does not work

Symptom	Cause	Fix
A field says the name is too long, but it looks fine	The counter is per store; Apple and Play both cap the name at 30	Shorten it, or check you are on the store you meant
The description is rejected for HTML	You are on the App Store tab, which allows none	Remove the tags; line breaks survive
Keywords are rejected at what looks like under 100	The commas count too	The page shows the real count beside the field
A saved password field looks empty	It is never sent back to the browser	The placeholder confirms one is saved; leave it blank to keep it
The checklist keeps a blocker after you fixed it	The list refreshes on save	Save the form