One possible workaround is to leverage DerivedData. Xcode Cloud caches the DerivedData folder and restores it on subsequent runs. So you can theoretically copy or move some files you need using a post-xcodebuild script: https://developer.apple.com/documentation/xcode/writing-custom-build-scripts. DerivedData is restored right before the post-clone script runs. Thus inside of post-clone you can copy/move the files back to their original location. In our case we were building a Kotlin Multiplatform framework, and we were able to copy the built framework and artifacts into derived data to avoid having to rebuild the binary on the next run. One thing worth mentioning though is that our workflow is triggered off of changes to a single branch (master). I don't think cache gets shared across separate branches or workflows. So this won't work if you are frequently running builds on new branches (e.g. for pull requests).

Same exact issue here -- everything succeeded but was getting that error message at the end. I can confirm it was indeed the build number mismatch. Our app had 6 existing Testflight builds when we started using Xcode Cloud, e.g. "1.0.0 (6)". The workflow finally succeeded on the 7th run. As @smuellner found, it automatically sets the build number equal to the workflow run number.