Fastlane递增Build Number报错：格式错误的64位版本号

我完全懂你遇到的这个坑——用Fastlane的increment_build_number设置时间戳格式的build号（比如201901091627）时，链接器突然抛出malformed 64-bit a.b.c.d.e version number错误。本质原因是Fastlane的这个动作默认会修改项目里所有目标的版本相关字段，包括动态框架的Current Library Version（对应构建设置里的DYLIB_CURRENT_VERSION），而这个字段要求必须是主版本.次版本.修订版本这类分段格式，根本不认连续的长数字串。

下面给你几个实用的解决思路，按需选择：

方案1：精准指定修改目标，只碰主App的build号 #

最简单的办法就是给increment_build_number加上target参数，限制它只作用于你的主应用目标，完全不触动动态框架。示例代码：

new_build_number = Time.now.strftime("%Y%m%d%H%M")
increment_build_number(
  build_number: new_build_number,
  target: "YourMainAppTargetName" # 替换成你项目里主App的实际target名称
)

这样Fastlane就只会更新主App的CFBundleVersion，动态框架的DYLIB_CURRENT_VERSION会保持你原来的设置，从根源上避免错误。

方案2：手动修改Info.plist，绕过Fastlane的全局修改 #

如果你的项目结构比较复杂，或者不想依赖increment_build_number的默认行为，可以直接用update_info_plist工具只修改主App的Info.plist文件，完全不碰任何框架的构建设置：

new_build_number = Time.now.strftime("%Y%m%d%H%M")
update_info_plist(
  plist_path: "./YourMainApp/Info.plist", # 替换成你主App Info.plist的实际路径
  build_number: new_build_number
)

这种方式更精准可控，完全不会影响动态框架的版本设置。

方案3：锁定动态框架的版本号设置 #

如果你一定要保留increment_build_number的全局使用，可以在Xcode里给动态框架的Current Library Version设置加锁：

• 打开动态框架的构建设置，找到Current Library Version（即DYLIB_CURRENT_VERSION）
• 右键这个设置项，选择Lock Settings
• 把它设置成符合规范的分段版本号（比如1.0.0）

这样Fastlane就无法修改这个字段了，不过这种方法需要你手动维护框架的版本号，适合框架版本不频繁变动的场景。

额外建议：分开管理主App和动态框架的版本 #

如果你的动态框架需要独立的版本管理，建议把框架的Current Library Version设置成a.b.c格式的规范版本，主App的build号用时间戳格式，两者分开处理。Fastlane可以分别操作：

# 更新主App的时间戳build号
new_app_build = Time.now.strftime("%Y%m%d%H%M")
increment_build_number(
  build_number: new_app_build,
  target: "YourMainApp"
)

# 更新动态框架的规范版本号（按需执行）
new_framework_version = "1.0.1"
increment_version_number(
  version_number: new_framework_version,
  target: "YourDynamicFramework"
)

内容的提问来源于stack exchange，提问作者Pablo Sanchez Gomez