Store listing fields you can change without shipping a new version
The short answer, and the two stores could not be more different:
App Store. Your app name, subtitle, keywords, description and screenshots are attached to an app version. Once that version is live they are frozen until the next one. Promotional text is the exception.
Google Play. Your title, short description, full description and graphics belong to the store listing, not to a release. You can change and publish them any time, with no build. Release notes are the exception.
So the field you can iterate on freely is the opposite one on each store.
App Store, field by field
| Field | Version-bound | How a change goes live |
|---|---|---|
| App name (30) | Yes | With your next version submission |
| Subtitle (30) | Yes | With your next version submission |
| Keywords (100) | Yes | With your next version submission |
| Description (4,000) | Yes | With your next version submission |
| What's New (4,000) | Yes | It is the version's release notes |
| Screenshots and previews | Yes | With your next version submission |
| Promotional text (170) | No | Immediately, on the live version |
| Price and availability | No | Immediately, no review |
| In-app purchase names and descriptions | No | Their own review, separate from the app |
| Privacy Policy URL | No | App-level, not version-level |
| Age rating answers | No | App-level |
| Category | No | App-level |
The mental model that makes this stick: App Store Connect keeps two kinds of metadata. App Information is about the app forever (category, age rating, privacy policy, content rights). Version localisations are about this specific release (name, subtitle, keywords, description, What's New, screenshots).
Anything in the second group moves only when a version moves.
Google Play, field by field
| Field | Release-bound | How a change goes live |
|---|---|---|
| App name / title (30) | No | Publish the store listing, no build |
| Short description (80) | No | Publish the store listing, no build |
| Full description (4,000) | No | Publish the store listing, no build |
| Screenshots, feature graphic, icon | No | Publish the store listing, no build |
| Release notes (500) | Yes | They belong to the release you are rolling out |
| Price and countries | No | Independently, no release |
| Data safety declarations | No | Independently of any release |
| App content declarations | No | Independently of any release |
| In-app products and subscriptions | No | Independently of any release |
Play's version of the trap is release notes. They are attached to a release, so if you write "Now with dark mode" and the rollout is halted, your store listing may already be advertising a feature that is not shipping, because the listing text published independently and the release did not.
What this means in practice
Do your keyword research before you submit, not after. This is the whole reason the distinction matters. If your App Store keyword field is wrong at submission, it stays wrong until your next release, and for a small team that can be weeks. There is no "just edit the keywords" on a live iOS version.
Put anything time-bound in promotional text. A sale, an event, a launch tie-in, a "the crash you reported is fixed" line. It is 170 characters, it sits above the description, it is not indexed for search, and it is the only App Store copy you can change on a whim. That last property makes it more valuable than its length suggests.
Iterate Play copy on a faster cycle than Apple copy. Because Play's indexed fields (title, short description, full description) are all publishable without a build, you can genuinely test store copy on Play in a way you cannot on iOS. Teams that treat both stores as one calendar leave that on the table.
Metadata-only rejections do not need a new build. If Apple rejects a version for metadata, you fix the metadata and resubmit the same binary. You do not increment a version number and you do not rebuild. Similarly, a Play listing rejected under the Metadata policy is a text fix, not a release.
In-app purchases are on their own clock. Subscription and purchase metadata goes through its own review on both stores and is not tied to an app version. You can fix a subscription description without touching the app, which is useful, and you can also get a subscription stuck in review while the app itself is fine.
The launch-day version of this
If you are shipping in the next week, the order that avoids regret:
- Lock the App Store name, subtitle and keyword field first. These are the expensive ones to get wrong. Treat them as part of the build, not part of the copy pass.
- Write the App Store description knowing it is not indexed, and the Play full description knowing it is.
- Leave promotional text empty at submission if you have nothing timely to say. It is easier to add later than to have Apple reviewing a sale that has ended.
- Publish the Play store listing before the release goes out, but not more than a day before, so the listing and the build agree about what the app does.
- Write real release notes. They are version-bound on both stores, so this is the one piece of copy you genuinely only get one shot at per release.
The bit nobody warns you about
Every one of these limits and rules is per language.
A listing in six languages has six App Store keyword fields that are all frozen to the same version, and six Play full descriptions that can all be edited independently. Adding a seventh language to a live iOS app means adding it to your next version, not to your current one, and it is easy to plan a localisation push that cannot ship until a release you had not scheduled.
AppSubmit shows which fields are frozen to the version currently in review, so the "I will just tweak the keywords" mistake surfaces before you have submitted. The tables above are the same information, and you can keep them in a text file.