昨天我认识到有关parse.com库的大量警告：
紧急：将删除所有位代码，因为构建的[[path] /Parse.framework/Parse（PFAnalytics.o）'没有位代码。您必须在启用位码（Xcode设置ENABLE_BITCODE）的情况下重建它，从供应商处获取更新的库，或禁用此目标的位码。注意：这将是将来的错误。
我知道我可以通过此答案删除这些警告，但现在我想知道这是否会对AppStore提交和/或我的应用的实际性能产生负面影响。
Xcode通知您有关位码的信息
激活此设置表示目标或项目应在为支持它的平台和体系结构编译期间生成位码。对于存档版本，将在链接的二进制文件中生成位代码，以提交到应用商店。对于其他构建，编译器和链接器将检查代码是否符合生成位代码的要求，但不会生成实际的位代码。[ENABLE_BITCODE]
但是我从本文中没有得到任何真正有用的信息。
ENABLE_BITCODE真正做的，它会在未来的非强制性要求？Answers:
- ENABLE_BITCODE实际做什么，将来会成为非可选要求吗？
我不确定您要在什么级别上找到答案，所以让我们花一点时间。您可能已经知道其中一些。
在构建项目时，Xcode会调用clangObjective-C目标和swift/ swiftc来调用Swift目标。这两个编译器都将应用程序编译为中间表示（IR），其中一个IR是位码。通过此IR，一个名为LLVM的程序将接管并创建x86 32位和64位模式（对于模拟器）和arm6 / arm7 / arm7s / arm64（对于设备）所需的二进制文件。通常，所有这些不同的二进制文件都集中在一个称为胖二进制文件的文件中。
ENABLE_BITCODE选项完成了最后一步。它使用IR位码二进制文件创建该应用程序的版本。它具有许多不错的功能，但是有一个巨大的缺点：它无法在任何地方运行。为了使带有位代码二进制文件的应用程序可以运行，需要将位代码重新编译（可能是汇编的或转码的……我不确定正确的动词），将其编译为x86或ARM二进制文件。
当位代码应用程序提交到App Store时，Apple将执行此最后一步并创建完成的二进制文件。
目前，位码应用程序是可选的，但是历史证明，苹果将可选内容变成了需求（例如64位支持）。这通常需要几年时间，因此第三方开发人员（如Parse）有时间进行更新。
- 我可以使用上述方法而不会产生任何负面影响，又不会影响以后的Appstore提交吗？
是的，您可以关闭ENABLE_BITCODE，一切将像以前一样工作。在Apple将位码应用程序作为App Store的要求之前，您会很好的。
- 如果启用/禁用性能会有任何影响？
启用它永远不会对性能产生负面影响，但是用于测试的应用内部分发可能会变得更加复杂。
至于积极影响……那很复杂。
为了在App Store中分发，Apple将为每种计算机体系结构（arm6 / arm7 / arm7s / arm64）创建单独的应用程序版本，而不是一个带有胖二进制文件的应用程序。这意味着安装在iOS设备上的应用将变小。
另外，当重新编译位码（也许再次被汇编或转码……我不确定动词是否正确）时，它会被优化。LLVM一直在努力创建更好的新优化。从理论上讲，App Store可以使用每个新发行的LLVM在App Store中重新创建该应用程序的单独版本，因此可以使用最新的LLVM技术对您的应用程序进行重新优化。
位码是iOS 9的新功能
位码是已编译程序的中间表示。您上载到iTunes Connect的包含位码的应用程序将在App Store上进行编译和链接。包含位码将使Apple将来可以重新优化您的应用二进制文件，而无需向商店提交新版本的应用。
注意：对于iOS应用，位码是默认值，但是可选的。如果提供位码，则应用程序捆绑包中的所有应用程序和框架都必须包含位码。对于watchOS应用，需要位码
因此，您应该禁用位码，直到应用程序的所有框架都启用了位码。
位代码使崩溃报告更加困难。这是HockeyApp的报价（其他崩溃报告解决方案也是如此）：
将应用程序上载到App Store并保持启用“ Bitcode”复选框时，Apple将使用该Bitcode构建并在最终将其重新编译之前将其分发给设备。这将导致二进制文件获得新的UUID，并且可以选择通过Xcode下载相应的dSYM。
注意：答案于2016年1月进行了编辑，以反映最新更改
@ vj9 thx。我更新到xcode 7。它告诉我同样的错误。设置为“否”后，构建良好
设置为“ NO”，效果很好。
在这里您可以找到有关位码的所有解决方案
根据Apple Doc
位码是已编译程序的中间表示。您上载到iTunes Connect的包含位码的应用程序将在商店中进行编译和链接。包含位码将使Apple将来可以重新优化您的应用二进制文件，而无需向商店提交新版本的应用。
Xcode默认隐藏在构建期间生成的符号，因此Apple无法读取它们。仅当您在将应用程序上载到iTunes Connect时选择包含符号时，这些符号才会发送到Apple。您必须包含符号才能从Apple接收崩溃报告。
注意：对于iOS应用，位码是默认值，但是可选的。对于watchOS和tvOS应用程序，需要位码。如果提供位码，则应用程序捆绑包中的所有应用程序和框架（项目中的所有目标）都需要包含位码。使用iTunes Connect分发应用程序后，可以下载dSYMs文件进行构建，如在“设备”窗口中查看和导入崩溃中所述。
苹果最初推出的比特码和应用程序稀疏服务被搁置了，因为从一种类型的硬件升级到另一种类型的硬件的问题未能恢复正确版本的二进制文件。此问题随后在iOS 9.0.2中得到修复，并重新启用了该功能。
比特码一直是LLVM编译和优化阶段的一部分，但是通过将后端逻辑转移到Apple服务器，它会将优化和组装阶段从开发人员的编译时间转移到App Store部署。这释放了将来进行重新优化或重新转换以支持将来更新更快的处理器的潜力。watchOS和tvOS部署需要位码部署，并且可以使用项目设置中的“启用位码”选项有条件地为现有iOS部署启用位码。这将为调试版本添加标志embed-bitcode-marker，为存档/设备版本添加标志embed-bitcode。这些可以通过-embed-bitcode或通过clang与-fembed-bitcode传递给Swift编译器。
位码也有一些缺点。开发人员可以通过存储调试符号的副本来调试应用程序中的崩溃报告，该调试符号的副本与运至Apple的二进制文件相对应。当给定堆栈中发生崩溃时，开发人员可以使用这些调试符号通过符号化崩溃报告来恢复原始堆栈跟踪。但是，符号是将中间形式转换为二进制形式的副产品。但是，如果该步骤在服务器上完成，则此信息会丢失。如果开发人员在应用程序发布时已上载调试符号，则Apple提供的崩溃报告服务可以充当调试器的角色。开发人员从未看到确切的二进制文件这一事实意味着，随着新硬件的发展，他们可能无法测试特定问题。
最后，服务器上的位代码可以转换为支持新架构和指令集的发展。假设它们保持调用约定以及对齐方式和单词的大小，则可以将位码应用程序转换为不同的体系结构类型，并专门针对新处理器进行优化。如果使用用于数学和向量例程的标准库，则可以将这些库优化为处理器特定的向量指令，以针对给定应用获得最佳性能。优化器甚至可能生成多种不同的编码，并根据大小或执行速度进行判断。
来自文档
比特码将使Apple可以优化应用程序，而无需提交其他版本。但是，只有在应用程序捆绑包中的所有框架和应用程序都启用了此功能后，才能启用此功能。拥有它会有所帮助，但没有它不会产生任何负面影响。
对于iOS应用，位码是默认值，但是可选的。如果提供位码，则应用程序捆绑包中的所有应用程序和框架都必须包含位码。对于watchOS应用程序，需要位码。
App Store和操作系统通过根据用户特定设备的功能量身定制应用程序交付，从而以最小的占用空间优化了iOS和watchOS应用程序的安装。此优化称为应用程序精简，使您可以创建使用最多设备功能，占用最少磁盘空间并容纳Apple可以应用的将来更新的应用程序。更快的下载速度和更多空间可用于其他应用程序和内容，从而提供更好的用户体验。
不应有任何性能影响。
