Updating your store page without shipping a build.

Most developers carry a simple mental model of their store listing: it ships with the release, and it's frozen until the next one. That model is half right — and the wrong half costs you. Typos sit live for six weeks because "we'll fix it in 1.4," seasonal copy never happens because nobody cuts a release for marketing, and the fields you could update this afternoon go untouched. Here's exactly what each store locks, what it doesn't, and the workflow that falls out.

Two stores, two philosophies

Apple splits your product page in two: some fields are version-locked — they ride along with an app submission and can't change between releases — while a handful are live-editable at any time. Google locks almost nothing to a release, but routes every change through review before it appears. Neither store matches the "frozen until next release" model, and getting the split wrong in either direction wastes something: time when you ship a binary you didn't need, opportunity when you sit on an edit you could have made today.

What Apple locks to a version

The big surfaces are all version-locked: the description (4,000 characters), the keyword field (100 bytes), screenshots and app previews, the What's New text, and — less obviously — the app name and subtitle (30 characters each). You can edit these only while a version is in an editable state: before you submit, or after a rejection. The moment a version goes live, its metadata is immutable; changing anything means creating the next version in App Store Connect.

And here's the part that stings: there is no metadata-only submission on iOS. A new version can't go to review without a build attached, and a build that already shipped can't be reused. So the true cost of fixing one typo in your description is a version bump, an archive, an upload, and a full pass through App Review. This is why iOS metadata changes should ride release trains rather than trigger them — more on that below.

What Apple lets you touch today

The star of the live-editable group is promotional text: 170 characters that render above your description, updatable at any moment with no new version and no review pass. Apple doesn't index it for search, which makes it a pure conversion surface — and the only genuinely real-time channel on your iOS product page. Use it for the things version-locked copy can't do: a launch-week banner, a limited-time price, a seasonal angle, or an honest "the sync issue is fixed in 2.3.1" while an incident is still fresh.

Also editable while your app is live: the support URL, the marketing URL, and pricing and availability. And if what you actually want to change is screenshots, there are two routes that need review but no binary: custom product pages give alternate screenshot sets their own URLs for campaigns, and product page optimization tests let you run new sets against your live page. Neither touches your default listing directly, but both put fresh screenshots in front of real users between releases.

Google Play: everything is editable, nothing is instant

Play takes the opposite position. The entire store listing — title (30 characters), short description (80), full description (4,000), screenshots, feature graphic — is editable whenever you like, with no release attached. The trade is that every change goes through Google's review before publishing, which typically takes anywhere from a few hours to a few days, and the timing isn't something you control. If timing matters — a listing refresh that must land with a launch — use managed publishing, which holds approved changes until you explicitly push them live.

Two cautions come with all that freedom. Release notes are the exception to the rule: Play's "What's new" field (500 characters) belongs to a release, not the listing, so it still waits for your next rollout. And because edits are cheap, it's easy to thrash — if you're running a store listing experiment, an impulsive mid-test edit quietly contaminates your results. Cheap to change doesn't mean free to change.

The workflow that falls out

Keep one source of truth outside the consoles. Listing text scattered across App Store Connect and Play Console — each holding a slightly different revision — is how wrong copy survives for months. Keep the canonical text in your repo or a shared doc, and treat the consoles as deploy targets.

Run an iOS metadata backlog. Since description, keyword, and screenshot changes can only ship with a version, collect them the way you collect small bugs. When a release train leaves, sweep the whole backlog into it. The worst pattern is remembering the typo the day after you submit.

Treat promotional text as your iOS hotfix channel. Anything time-sensitive belongs there, because it's the only place time-sensitive copy can actually live. If your promotional text has said the same thing for a year, you're paying for a live-update surface and using it as a static one.

On Play, batch and schedule. Group listing edits, put them through review together, and let managed publishing decide the moment they land — especially around launches and running experiments.

Change it once, publish it everywhere

This split is exactly why ShotCanvas publishes directly to both stores: design your screenshots once, generate the metadata, and push to App Store Connect and Google Play from one place. It checks the version state before letting you save, so you're never editing a field the store has already locked — and never shipping a build you didn't need.