Bitccode实际上只是LLVM的中间语言。当您使用LLVM工具链编译源代码时，源代码被翻译成一种名为Bitcode的中间语言。然后对Bitcode进行分析、优化，并最终转换为所需目标CPU的CPU指令。
这样做的好处是，所有基于LLVM的前端(如clang)只需要将源代码转换为Bitccode，从那里起，无论源语言，它的工作是一样的，因为LLVM工具链不关心Bitcode是由C, c++， obc, Rust, Swift或任何其他源语言生成;一旦有了Bitccode，其余的工作流程总是相同的。
Bitccode的一个好处是，您可以稍后为另一个CPU生成指令，而不必重新编译原始源代码。例如，我可以编译一个C代码到Bitccode，并让LLVM生成一个x86 cpu的运行二进制文件。但是，如果我保存了Bitcode，我可以告诉LLVM也从Bitcode创建一个ARM CPU的运行二进制文件，而不需要编译任何东西，也不需要访问原始的C代码。生成的ARM代码就像我从一开始就编译到ARM一样好。
如果没有Bitccode，我将不得不将x86代码转换为ARM代码，因此这种转换产生的代码会更糟糕，因为代码的原始意图通常会在编译CPU代码的最后一步丢失，这也涉及到CPU特定的优化，这对其他CPU没有意义，而Bitccode很好地保留了原始意图，只执行所有CPU都会受益的优化。
拥有所有应用程序的Bitccode允许苹果为特定的CPU重新编译Bitcode，使应用程序与不同类型的CPU或完全不同的架构兼容，或只是从新的编译器版本的更好优化中受益。例如，如果苹果明天发布了一款使用RISC-V而不是ARM CPU的iPhone，那么所有带有Bitcode的应用都可以重新编译成RISC-V，并原生支持新的CPU架构，尽管应用的作者甚至从未听说过RISC-V。
我想这就是为什么苹果希望所有应用程序都采用Bitccode格式的原因。但这种方法一开始就存在问题。一个问题是Bitcode不是一种冻结的格式，LLVM每次发布都会更新它，他们不能保证完全向后兼容。Bitccode从来都不是用于永久存储或存档的稳定表示。另一个问题是不能使用汇编代码，因为汇编代码不会发出Bitccode。另外，你不能使用没有Bitcode的预先构建的第三方库。
最后但并非最不重要的是:据我所知，苹果迄今为止从未使用过Bitccode的任何优势。尽管过去要求所有的应用程序都包含Bitccode，但这些应用程序也必须包含针对所有支持的cpu的预构建的胖二进制文件，而苹果总是只发布这些预构建的代码。例如，对于曾经拥有32位ARMv7和64位ARM64版本的iphone，以及Bitccode，在应用细化期间，苹果会移除32位或64位版本，以及Bitccode，然后发布剩余的内容。好吧，但如果没有Bitcode，他们也可以这么做Bitccode不需要瘦架构的胖二进制!
重新构建不同的架构需要Bitccode，但苹果从未这样做过。没有一个32位的应用程序神奇地变成64位的苹果重新编译位代码。当苹果按需重新编译Bitcode时，没有64位的应用程序能够神奇地用于32位系统。作为一名开发者，我可以向你保证，iOS App Store总是准确地提供你自己构建和签名的二进制代码，而不是苹果自己从Bitcode创建的任何代码，所以没有任何服务端优化。即使当苹果从英特尔切换到M1，也没有macOS应用程序神奇地转换为原生ARM，尽管苹果拥有Bitcode，应用商店中的所有x86应用程序都可以这样做。相反，苹果仍然发布了x86版本，并让它在Rosetta 2中运行。
因此，通过强制所有代码以Bitccode的形式提供给开发者各种各样的缺点，而不使用Bitccode所能给你的任何优势，会让整个过程变得毫无意义。现在所有的平台都迁移到ARM64，在几年内甚至不会再有胖的二进制文件了(一旦x86对Mac的支持被放弃了)，继续使用那些东西的意义是什么?我猜苹果抓住这个机会彻底埋葬了这个想法。即使有一天他们将RISC-V添加到他们的平台上，开发人员仍然可以同时发布包含ARM64和RISC-V代码的胖二进制文件。这一理念非常有效，非常简单，除了“更大的二进制文件”之外没有任何缺点，这是服务器端应用程序细化可以解决的问题，因为在下载过程中只需要包含当前平台的代码。
