TestFlight上传高版本构建包后能否回退提交2.5.x等更低版本？

核心结论 #

TestFlight 完全支持提交比已上传版本号更低的构建包，无需严格按版本号递增顺序提交，你描述的操作计划可以正常执行。

fastlane 运行失败的常见原因 #

你遇到的不提升版本号就运行失败的问题，和 TestFlight 的版本号规则无关，通常是以下两种原因导致：

• 你的 fastlane 脚本默认开启了自动提升对外版本号（Version 号，即 2.5.4/2.6.0 这类用户可见的版本标识）的逻辑，比如调用了 increment_version_number 动作
• 同一个对外版本号下的构建号（Build 号，即内部编译编号）未做递增，App Store Connect 要求同一版本号下的所有构建包 Build 号必须全局唯一且递增，否则会拒绝上传

操作方案适配指导 #

按照你计划的执行顺序，只需要遵守「同一版本号下 Build 号持续递增」的规则即可正常完成所有操作：

1. 提交 2.6.0 版本 TestFlight 包：对外版本号设为 2.6.0，Build 号设为高于你历史所有构建包的数值即可上传
2. 提交新版 2.5.4 版本 TestFlight 包：对外版本号保持 2.5.4，将 Build 号提升到高于此前所有 2.5.4 版本构建包的数值，直接上传即可，系统不会因版本号低于已上传的 2.6.0 而拦截
3. 提交 2.5.5 版本的 TestFlight 及 App Store 包：对外版本号设为 2.5.5，Build 号继续递增即可正常提交，只要你此前未将 2.6.0 版本提交 App Store 正式审核上线，2.5.5 可以正常通过审核发布
4. 回归 2.6.0 版本迭代：对外版本号保持 2.6.0，继续提升 Build 号提交新测试包，正式发布时选择对应构建包即可

补充规则：仅当某个版本号已经通过 App Store 正式审核并公开发布后，后续新提交的正式审核版本号才需要高于已上线的正式版本号，TestFlight 测试版本完全不受该规则限制。

fastlane 配置优化建议 #

你可以修改 fastlane 配置，关闭自动提升 Version 号的逻辑，改为执行时手动指定 Version 号、脚本自动提升 Build 号，避免误操作，参考配置如下：

lane :upload_tf do |options|
  # 执行命令示例：fastlane upload_tf app_version:2.5.4
  increment_build_number(xcodeproj: "你的项目文件名.xcodeproj")
  build_app(
    workspace: "你的项目名.xcworkspace",
    scheme: "你的项目Scheme名",
    xcargs: "MARKETING_VERSION=#{options[:app_version]}"
  )
  upload_to_testflight(skip_waiting_for_build_processing: true)
end

内容的提问来源于stack exchange，提问作者Ramy Al Zuhouri