fastlane deliver failed with error "invalid pre-release train" when uploading build

TL;DR

Close or complete the currently open version train in App Store Connect, then upload again. The error means a previous app version is still in a state that blocks new pre-release builds for the same version string, usually a version awaiting review or with an expired build attached. Either bump the marketing version for the new build or finish, cancel or replace the stuck version, then re-run deliver or pilot.

invalid pre-release train

Use this when

• fastlane deliver or pilot fails while uploading metadata or a build.
• A version with the same number sits in Waiting for Review, Prepare for Submission or a rejected state.
• You changed the version string in the project but not in App Store Connect, or the reverse.

Not for this skill when

• The upload fails at authentication before reaching the train check. Resolve API key or session issues first.
• You are uploading to a brand new app record. A first version has no old train to close.

Steps

1. Open App Store Connect and list every version on the App Store page, noting any version matching the build you are uploading. Verify: each same-number version and its status is identified
2. If a same-number version is in review and you no longer want it, remove its build or cancel the submission; if it should ship, wait for review to finish. Verify: no same-number version remains in an in-review or stuck state, or you decide to bump instead
3. Decide the path: bump the marketing version in the project settings for the new build, or clear the old train. Verify: the version string in the project and the intended Connect version agree
4. Rebuild or at least re-export the build so its version metadata matches the decision, since the train is keyed on the version inside the binary. Verify: the IPA Info.plist version equals the target Connect version
5. Re-run the fastlane lane with deliver or pilot and watch the upload phase complete. Verify: fastlane reports the build uploaded and processing starts in TestFlight
6. Confirm the build is attached to the correct version or test group in Connect. Verify: the build shows under the expected version with status Processing or Ready
7. Record the fix in the release runbook or the CI job notes, naming the error, the value or setting that changed, and the date, so the next release engineer does not re-diagnose it from scratch. Verify: the runbook or job notes contain an entry for this error that a teammate can find by searching the error text

Why it happens

App Store Connect organises builds into version trains. Only one train for a given version string can accept pre-release builds at a time, and a train locked by review, an expired build or an abandoned submission rejects newcomers. fastlane surfaces this as the invalid pre-release train error because the API refuses the association, not the binary itself.

In practice this failure is rarely a one-off. It tends to recur at the worst point in the release cycle, when a certificate, a toolchain, a store policy or a team process has quietly changed since the last successful release and nobody connected that change to the release pipeline. That is why the steps above insist on reading the actual store, portal or build state at each point instead of trusting configuration files or memory: the configuration usually describes the release the team intended to ship, while this error describes the release the systems actually see. Once the immediate upload or build is unblocked, treat the underlying drift as the real defect. Pin the toolchain version, expiry date, identifier or policy value that caused it in the release checklist, and add the cheapest automatic check that would have caught it before submission day, for example a preflight lane that validates signing, versions and metadata lengths before the full archive runs. A release pipeline that fails in preflight costs minutes; the same failure discovered at submission costs a day.

Variants and edge cases

invalid pre-release train fastlane deliver

The exact lane-level phrasing; check Connect version states first. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

could not create pre-release train App Store Connect

A close API wording for the same locked-train state. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

Edge case: expired builds locking a version

An expired TestFlight build can keep a train half-open. Removing the build from the version usually releases it without a version bump. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstqSUWoM2hrAe5dH1toGqng