Update a Store Listing Without a New Binary

You changed one line of store copy and you do not want a release. On iOS that wish is true for a single field. Promotional text, 170 characters at the top of the description, can be edited without submitting a version. The subtitle, the keyword field, the description, and the screenshots cannot. They go out with a version. On Google Play the store listing is a different object from the app bundle. You can update listing assets without uploading a new bundle.

Apple states the promotional-text exception on the product page guide : you can update it at any time without a new version, and you update the description when you submit a version. The same page says the subtitle is updated when you submit a version. How promotional text differs from the description is the promotional text guide. This post is the “do I need a binary?” question for both stores.

The App Store split

Promotional text is the fast lane. Use it for something true and temporary: a seasonal lesson, a tournament week, a note that a feature already in the binary is relevant this month. It does not affect search rank, and Apple says not to use it as a keyword dump. It also will not fix a screenshot. If the first frame is wrong, you are in version territory no matter how clever the 170 characters are.

Keywords, subtitle, description, and screenshots are version metadata. You prepare them on a version and submit. You do not have to ship a new binary if App Store Connect still lets you attach the existing build, but you do have to submit a version. “Without a new binary” and “without a submission” are not the same sentence on iOS. People say the first and mean the second. Only promotional text is the second.

What each store lets you change

On iOS, only promotional text skips a version submission. Keywords, subtitle, description, and screenshots wait for one. On Play, store listing assets can change without a new app bundle.

Google Play is the listing, not the bundle

Play Console separates the main store listing from the release that carries the Android App Bundle. Title, short description, full description, icon, feature graphic, screenshots, and video are listing assets. You update them on the listing. You do not need a new bundle to change a screenshot that showed the wrong screen. You do need a new bundle when the behavior inside the app changed and the listing would otherwise advertise a build people do not get.

That freedom cuts both ways. You can fix a misleading graphic today, and you can also publish a graphic for a feature the production bundle does not have. The listing is public on the test tracks once the assets are there. Do not treat “no new bundle” as “no review” or “no policy.” A false screenshot is still a false screenshot. Staged rollout is about the bundle’s availability to users, not about whether the feature graphic can change. Do not confuse the two knobs.

A seasonal line is usually promotional text

If the binary already contains the seasonal content, the App Store change is often promotional text: what is timely this week, in 170 characters, without a version. The seasonal ASO notes are about when the screenshots and keywords should move, which is a version. Do not put the season’s keywords into promotional text and call the field updated. The keyword field guide is the 100 characters that wait for submission.

On Play, the same season can be a short-description edit and a new screenshot on the listing, shipped without a bundle, as long as the app already does the thing the new assets show. If the season requires new code, you are in a release, and a staged rollout may be how you ship that bundle. The listing can still be updated on its own schedule. Align them so the graphic and the binary tell one story on the day the rollout reaches people.

Phased release is not a listing edit

A phased release on the App Store rolls an approved version out to users over time. It does not let you change keywords halfway through. A staged rollout on Play does the same kind of job for a release: who gets the new bundle. Neither one is how you swap a screenshot. If the only thing wrong is the first frame, use the store’s listing path. If the binary is wrong, stop looking for a copy edit.

Custom product pages and store listing experiments are also not this article. They are extra variants. The default page still follows the rules in the table. AppGrowthKit matters when the screenshot is the thing that must change: build it from the current UI, then attach it to an iOS version or upload it on the Play listing. Do not generate a screen the binary cannot open just because Play will accept the file without a bundle.

Pick the path before you edit

Write the change in one line. “Tell people the winter lesson is in the app they already have” is promotional text on iOS and a short-description tweak on Play. “Rank for a new phrase” is a version on iOS and listing text on Play. “The first screenshot shows a button we removed” is a version on iOS and a listing upload on Play, and it is urgent on both because it is inaccurate. “The button is still in the design file” is a binary, on both stores.

Then look at the live page after the edit. Promotional text should appear at the top of the description without a version number bump. A keyword change should not appear until that version is approved. A Play screenshot should match the production app a new install gets, including during a staged rollout if the old bundle is still what most people receive. The listing is a promise about the bytes. The form you used does not cancel that promise.