"No editable App Store version": why metadata and screenshot pushes fail
App Store metadata does not belong to your app. It belongs to a version, and only a version in an editable state accepts writes. If your app has no version in one of those states, every push of a description, a keyword set or a screenshot fails, and the API says so in various unhelpful ways.
The editable states are:
PREPARE_FOR_SUBMISSIONREJECTEDMETADATA_REJECTEDDEVELOPER_REJECTED
Everything else is locked. A version that is WAITING_FOR_REVIEW, IN_REVIEW, PENDING_DEVELOPER_RELEASE, PROCESSING_FOR_APP_STORE or READY_FOR_SALE will refuse your changes, and it is supposed to.
The two records people confuse
App Store Connect splits your listing across two record types, and they have different rules. This is the detail that explains most "but I can edit it in the browser" confusion.
App Info holds the things that are not version-specific: app name, subtitle, category, age rating, privacy policy URL. A live app carries two App Info records at once. One is the live record, locked forever, and one is the editable record your staged changes go into. Patch the live one and you get a 409 along the lines of "can not be modified in the current state".
App Store Version holds the version-specific copy: description, keywords, promotional text, what's new, and the screenshot sets. One record per version, editable only in the four states above.
So "the app name is locked" and "the description is locked" are two different problems with two different fixes, even though they look identical from the outside.
Reads want the live record, because that is what shoppers see. Writes must target the editable one. There is no useful fallback: writing to the live record never works, so a tool that silently falls back to it is just producing a slower failure.
Why your push failed
Work down this list.
The app is brand new and has no version at all. Creating the app record in App Store Connect does not create a version. A fresh app with no version has nothing for screenshots to attach to.
The only version is with App Review. Once you submit, the version locks. Screenshots, description and what's new are frozen until the review resolves one way or another. This is by design: the reviewer is looking at a fixed thing.
The app is live and you have not started a new version. READY_FOR_SALE is not editable. A live app with no next version in progress has exactly one version record and it is locked. You need to create the next one.
The version is processing. PROCESSING_FOR_APP_STORE is a transient state after a build is accepted, and it does not take writes. Wait it out rather than working around it.
You are approved and waiting to release. PENDING_DEVELOPER_RELEASE means Apple said yes and is holding the release for you. The version is locked. You cannot slip a screenshot change in between approval and release; that would defeat the point of the review.
Creating an editable version
Three routes, in the order most people should use them.
In App Store Connect. Open the app, and in the sidebar use the option to add a version for the platform you are shipping. Give it a version string higher than the live one. It appears in Prepare for Submission and everything unlocks.
Through the API. POST /v1/appStoreVersions with platform and versionString in attributes, and a relationship to the app. The new version lands in PREPARE_FOR_SUBMISSION.
As a side effect of starting a release in your tooling. Anything that manages releases end to end will create the version for you when you begin one, because there is no way to attach a build without one.
What does not create a version: uploading a build. A build uploaded with no version waiting for it sits in your build list, valid and unattached. This surprises people who expect the upload to do the whole job.
Version string rules that bite here
The new version's string has to be higher than the last approved one, and Apple compares it as a dotted version rather than a decimal. 1.10 is higher than 1.9. 1.1 is not higher than 1.10.
Getting this wrong does not usually fail at version creation. It fails later, at upload, with ITMS-90062 telling you the value for CFBundleShortVersionString must be higher than the previously approved version. Two different layers, one mistake, and the error arrives a step after the cause.
What you can change without a new version
Very little, and this is worth knowing before you create a version you did not need.
Promotional text is the documented exception: Apple's design intent is that you can update it without submitting an app update. If you only wanted to change that one field, check whether you can do it on the current version before starting a new one.
Pricing, availability and in-app purchase metadata live outside the version record entirely and are not affected by this error at all. If a pricing change is failing, this is not your problem.
Order of operations for a clean release
- Create the version. Version string higher than the live one, dotted comparison.
- Push metadata and screenshots while it sits in Prepare for Submission.
- Upload the build, with a build number higher than any build you have uploaded for that version string.
- Attach the build to the version.
- Submit.
Steps 2 and 3 can swap. Steps 1 and 5 cannot move. Almost every "no editable version" failure is somebody attempting step 2 without step 1, usually because the last release finished and nothing has started the next one.
When the fix is to wait
If the version is in review, do not create a second version to get around the lock. You will end up with two version records, the wrong one editable, and a submission whose metadata does not match what you think you changed.
Wait for the review to resolve. Both REJECTED and METADATA_REJECTED unlock the same version you already have, so a rejection gives you back the edit access you wanted anyway.
AppSubmit checks for an editable version before it attempts a push and, when there is not one, says so with the two ways to create one rather than returning Apple's error. The state list at the top of this page is the same check.