You push, the build runs, the archive and export steps succeed, the upload step succeeds, the workflow finishes green. You open App Store Connect to check on it and TestFlight shows... the previous build. Not a failed build. Not a processing build. Nothing new at all.
This one is genuinely confusing the first time it happens, because there's no error anywhere — everything you can see reports success.
What's actually happening
App Store Connect silently rejects an upload if it reuses the same marketing version and build number as a build you've already uploaded — even one from weeks ago. It considers that pair a duplicate. But the upload tool (xcrun altool, or the newer transporter flows) reports a successful file transfer regardless — it uploaded the bytes fine, it just didn't tell you App Store Connect threw the result away on the other end.
So the failure genuinely happened, it's just invisible at the layer your CI log is watching.
The fix
Make sure your build number (CURRENT_PROJECT_VERSION in Xcode's build settings) changes on every single upload, even when your marketing version stays the same across several builds while you're iterating.
The reliable way to do this in GitHub Actions is to use GitHub's own per-workflow run counter instead of anything you maintain by hand:
xcodebuild archive \
CURRENT_PROJECT_VERSION="$BUILD_NUMBER" \
...
# where, earlier in the workflow:
env:
BUILD_NUMBER: ${{ github.run_number }}
github.run_number increments by one on every run of that specific workflow, forever, with no state you have to track yourself. The actual root cause most of the time is someone customizing the archive step and dropping the dynamic build number in the process, usually while debugging something unrelated.
If you're already using a dynamic build number and this is still happening: double check the substitution is actually reaching the archive command — a common way this breaks is the environment variable being set in the wrong step or shell context, so $BUILD_NUMBER silently expands to empty.
How to confirm this is actually your problem
In App Store Connect, look at "Build Activity" or the processing history rather than just the current builds list — a duplicate-version upload sometimes doesn't even appear there. Worth separately ruling out: processing does take a few minutes even on a successful upload, so if it's only been a minute or two, it may simply not have finished yet.
The Macless workflow file sets CURRENT_PROJECT_VERSION from github.run_number by default, so this failure mode doesn't happen unless you specifically override it. Full details at macless.dev.
