What you can change without a new app version: Apple vs Google

Before you touch a store listing, there's one question worth answering: is this edit going to cost me a full submission, or can it go out quietly? Get it wrong and you either sit in a review queue you didn't budget for, or you assume a change is live when it's still waiting to be approved. The two stores answer that question in opposite ways, and the difference is the whole reason keeping listings in sync across both is annoying.

Here's the honest, field-by-field version — starting with the matrix, then the reasoning behind each store's rules so you can predict the cases this table doesn't spell out.

The matrix

Every common listing field, and what each store demands when you change it. "New version / release" means the store treats the edit as part of a submission you have to send; "reviewed" means a human or automated check runs before it goes live.

Two things jump out. Apple funnels almost everything through a version record. Google lets the whole listing move on its own. Neither store skips review on the assets that matter — the word "reviewed" shows up in nearly every cell. So the real question is rarely "will this get reviewed," it's "does this edit drag a submission along with it."

Apple: a new version record is not the same as a new build

This is the distinction that trips people up. On the App Store, editing your screenshots, name, subtitle, keyword field, or description creates a new version of your listing. That sounds like it should force you back to Xcode. It doesn't. Apple auto-carries your current metadata into the new version, and a metadata-only change needs no new app code — you attach a build (App Store Connect still requires one on the version) and change nothing about what the app does. You edit the queued fields, submit, and one review cycle covers all of them.

So "no new code, but still reviewed" is the accurate way to hold it in your head. No compile step and no new features — but the edit still enters App Review and waits its turn before it's public. Batch your changes: because a single version record can hold new screenshots, a rewritten description, a fresh subtitle, and updated keywords all at once, there's no reason to spend a separate review cycle on each one.

The app icon is the exception that does need a build. Your primary icon is baked into the binary and drawn from it, so a genuinely new icon means a new build. The same is true of alternate icons — they have to be bundled in the app to be usable, so adding one is a build, not a listing edit.

The two Apple escape hatches

Promotional text. This is the one field you can change with no version and no review. It's 170 characters, sits above the description, and updates whenever you want — handy for a sale, a launch note, or time-sensitive copy. It doesn't affect search ranking and it isn't part of any submission, which is exactly why it's the fastest thing on the store to change. If you need something live today, this is the field that can do it.

Product Page Optimization. PPO lets you test up to three treatments of your screenshots, app previews, and icon against your live product page — without shipping a new app version. It's the closest Apple comes to changing visuals outside a normal submission. Two caveats keep it honest: the treatment metadata still has to be approved before the test runs (so it's reviewed, not instant), and any icon you want to test must already be part of the current app binary. PPO changes what visitors see; it doesn't skip review.

Google Play: publish the listing without a release

Play works the other way around. Your store listing — title, short description, full description, screenshots, feature graphic, icon, promo video — is editable and publishable on its own, with no new app release attached. You make the edits, and they show up in the Publishing overview under changes ready to send for review. You send them, they pass through Google's review, and they go live independent of any build.

A few things to keep precise so you don't overstate it. The changes are still reviewed — Play's review runs on listing edits too, and elements like the app name and icon get checked, so it's not a silent instant swap. And the listing can't float free of a shipped app: Play needs the app to have a prior release before there's a public listing to edit. You can't push a standalone store page for something that has never been released. Managed publishing adds one more wrinkle worth knowing — if it's on, approved changes wait until you actively publish them, which is a feature, not a delay, once you expect it.

The asymmetry, and why it costs you time

Line the two models up and the split is clean. Apple ties nearly every text and image edit to a version record and a review pass, with promotional text and PPO as the only ways around it. Google decouples the listing from the release entirely, reviews the edits, and ships them on their own schedule as long as the app already exists.

That asymmetry is quietly expensive when you run both stores. The same screenshot refresh is a version-record submission on one store and a standalone listing update on the other. A description rewrite is a reviewed version on Apple and a reviewed listing change on Google. The content is the same; the mechanics are not, so a change that's one action on Play becomes a different action on the App Store — and it's easy to ship one and forget the other, or to assume something's live on Apple when it's still in review.

Where Mokbi fits

This cross-store asymmetry is the whole reason a publishing tool earns its keep. Mokbi started as a screenshot editor, but a listing is text and images together — so it designs the screenshot set and drafts the listing copy for both stores in one place: App Store name, subtitle, keyword field, and description; Play title, short description, and full description. You get the fields each store actually indexes, shaped for that store, instead of one block of text you paste twice.

Then it translates the whole listing — screenshots and copy — into 50 languages, so a change you make once lands in the right field in every market rather than staying English in a listing that's localized everywhere else. And it publishes: Mokbi pushes the finished listing straight to Google Play through the Play Developer API, and stages it in App Store Connect ready to submit — Apple still requires the final Submit and review pass on its side, which is an Apple rule and exactly the cross-store asymmetry this whole post is about. That last review is also where the clocks in this post start ticking.

What to read next

• Change App Store screenshots without a new version
• Update a Google Play listing without releasing the app
• The submission checklist: every asset, both stores

Design, translate, and publish your listing →