Xcode 14弃用Bitcode的原因及后续iPhone编译机制咨询

随年度WWDC发布的Xcode 14 Beta版本说明中，已正式将Bitcode标记为弃用功能，开发者如果手动开启Bitcode编译配置，会收到系统弹出的警告提示。以下是对应问题的具体解答：

Apple弃用Bitcode的核心原因 #

Bitcode是LLVM体系下的中间码格式，Apple最初推出这项能力的初衷，是希望开发者上传中间码后，Apple可以在服务端直接针对新发布的芯片架构、新指令集重新优化App二进制，不需要开发者重新提交版本适配。但从多年的实际落地效果看，这项能力的投入产出比远低于预期，最终走到弃用是必然结果。

Bitcode本身的固有弊端 #

• 排查链路完全黑盒：开发者本地无法100%复现Apple服务端用Bitcode重编译出的最终二进制效果，经常出现本地调试、测试全流程正常，上线后因为服务端编译参数、工具链版本差异出现崩溃、性能劣化的问题，出问题后开发者完全没有排查抓手，这类问题在开发者社区反馈非常多。
• 实际优化收益极低：Bitcode能做的优化基本都是指令集层面的微调整，近几年Apple A系列芯片的前后代架构兼容性做的非常成熟，开发者本地用Xcode编译出的标准二进制，和服务端用Bitcode重编译的版本，实际运行性能差距普遍在2%以内，普通用户完全感知不到差异。
• 额外增加包体积和上传成本：开发者需要上传完整的Bitcode中间码包，体积比最终发布的二进制大出数倍，不管是开发者上传环节的带宽成本，还是本地归档的时间成本都有额外消耗。

维护成本过高确实是核心考量因素之一 #

对Apple来说，Bitcode的服务端编译链路维护成本极高：

• 每一代Xcode升级、LLVM工具链迭代、新芯片发布，都要同步适配服务端的编译逻辑，还要兼容过去数年间开发者上传的、用不同版本工具链生成的Bitcode包，适配、测试、问题排查的人力成本逐年上涨。
• 每次App提交后服务端都要跑全量重编译，消耗的服务器算力、存储成本不是小数目，和这项能力带来的微弱收益完全不对等。

弃用Bitcode后的定向编译运行机制 #

很多开发者担心弃用Bitcode后，App会变成兼容所有机型的通用包、导致用户下载的安装包体积变大，实际上完全不会，原来服务端做的机型定向适配逻辑并没有消失，只是从「拿Bitcode中间码在服务端编译」改成了更高效的链路：

• 开发者本地用Xcode 14及以上版本归档时，会直接生成所有支持机型对应的二进制切片，不需要再上传中间码。
• App Store在用户下载App时，会根据用户的具体iPhone机型，自动匹配下发对应机型指令集的二进制切片，用户拿到的安装包和之前开启Bitcode时的体积没有差异，甚至因为去掉了Bitcode的冗余中间段，部分App的下载体积还有小幅下降。
• 原来服务端做的编译优化，现在全部整合到了Xcode本地编译工具链中，开发者在本地就能看到最终发布版本的编译效果，不管是性能调优还是问题排查，都不再需要面对之前的黑盒链路。

注：目前Xcode 14新建项目已经默认关闭Bitcode配置，后续的Xcode正式版本会逐步彻底移除Bitcode相关能力，还在开启Bitcode的项目建议尽早关闭配置，避免后续版本出现编译失败的问题。

内容的提问来源于stack exchange，提问作者Isaaс Weisberg