因为我使用 Crashlytics 来处理我的崩溃，所以我总是取消选中“为您的应用程序包含应用程序符号以从 Apple 接收符号化的崩溃日志”并保留“包含位码” 在将我的应用程序提交到 iTunes Connect 之前检查了一个(Apple Watch 的 future 证明):
Crashlytics 有一篇关于 Bitcode 和缺失 dSYM 问题的文章:
https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#bitcode-download
根据他们的截图，要下载由 Bitcode 创建的新生成的 dSYM 文件，iTunes Connect 中有一个直接可用的下载链接，但是，似乎您必须选中“包含应用程序符号”才能下载它们，否则你只是得到这个:
所以我对这两个设置对于 Crashlytics 或任何第 3 方崩溃处理程序服务的良好运行有何要求感到有点困惑。
我应该检查这两个设置吗？取消选中“包含应用程序符号”是否可以，因为我不使用 Apple 的崩溃管理器(据我了解，dSYM 文件在其后脚本存档期间上传到 Crashlytics)并且只检查 Bitcode，否则我不会无法下载新的 Bitcode 生成的 dSYM(导致 Crashlytics 出现问题，正确符号化崩溃)？
最佳答案
这是个好问题。有许多旋钮会影响应用调试符号信息的可用性。它令人困惑，人们经常被它绊倒。
这是我的指导方针:
- 在向 Apple 提交应用时始终选中“包含符号”复选框
- 始终剥离您的最终可执行文件(.app、.framework)
- 永远不要剥离你的静态库，如果你有的话
- 您希望 Apple 的崩溃报告发挥作用，即使您不打算查看它
使用此配置，您在本地或由 Apple 生成的 dSYM 将包含 Crashlytics 和 Apple 的记者工作所需的调试信息。在使用 bitcode 时与 Apple 共享符号是关键的。如果不这样做，您可能永远无法看到该应用版本的符号化崩溃。
当然，您可能有一些正当理由不想与 Apple 共享符号。一是您想混淆您的代码。我知道有一些应用程序可以执行此操作。当然，这是一种权衡，因为它使符号化变得更加困难，甚至不可能，具体取决于混淆系统。
还有一些原因可能导致您不想剥离可执行文件。一是您依赖于不支持服务器端符号化的第三方崩溃报告系统。据我所知，这种情况越来越不常见，但这是需要注意的事情。
最后，您绝对希望 Apple 的崩溃报告系统正常工作，即使您从未打算使用它。 Apple 的系统能够比任何第 3 方解决方案更可靠地捕获更多崩溃。我相信它对于 Apple 的内部工作也是无价的。它确实有局限性，但实际上不会花费您任何费用。因此，请继续使用它，如果没有其他原因，只是为了将来可以选择查看它。
关于ios - Xcode Bitcode，包括符号设置对 dSYM 生成的影响，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39843221/