我最近参与了一个团队，该团队有一个用于 iOS 开发的组织帐户。
他们有多个团队都在开发独立的 iOS 应用程序。得知组织的“iOS 分发”证书的使用完全没有协调，我感到有些惊讶。相反，无论哪个开发人员需要提交构建，都只会创建一个新构建，并在必要时撤销一个或多个现有构建(苹果似乎允许其中三个的有限供应同时“上线”)。这种做法的理由似乎是以下观察结果的结合:
- 一个开发人员创建的分发证书不能(轻松地)被另一个开发人员使用(您可以在这个主题上找到很多关于 SO 的问题；解决方案似乎是确保证书的私钥元素也被共享, 但该组织尚未将其纳入其中。Example , another example ；还有更多)。
- xcode7 比以往任何时候都更容易搅动分发证书，因此这显然是 Apple 的预期方式(xcode6 需要访问开发人员中心)。
- 只有相当小的应用商店提交窗 Eloquent 需要分发证书；一旦应用进入应用商店，分发证书是否被吊销都没有关系。
- Apple 似乎有一些关于分发证书更新的稍微奇怪的后进先出规则(如果您有“旧”、“较新”和“最新”并且您撤销“较新”或“最新”...你会发现在撤销“旧”之前你仍然无法创建新的)。或者至少对于一个希望在各个团队/项目之间分配有限库存的分发证书的组织来说，这些规则看起来很奇怪，但发现这不符合 Apple 实际提供的内容。
但是，我观察到这种快速分发证书流失政策的一个非常严重的负面后果是 testflight 构建不会在很长时间内保持有效，并且 tesflight 用户发现自己收到有关无效证书或正在使用的应用程序的对话框应该是过早从试飞中消失的试飞测试员。 (事实上 ，另请参阅 this question 沿着相同的路线)。
鉴于 Apple 清楚地将 testflight 视为应用商店基础设施的重要组成部分，我很难相信这个组织正在按照 Apple 实际打算做事的方式开展工作。 能否请对正确做事方式有所了解的人赐教？
如果我的术语在上面的某些内容中出现问题，我深表歉意......我只是涉足这些东西。
最佳答案
正确的做法是拥有一个分发证书并共享私钥。我们共享一个小型钥匙串(keychain)，其中仅包含在我们的组织中进行开发/分发所需的私钥和证书。您可以将这个“ stub ”钥匙串(keychain)添加到您所有的开发机器上，如果它被 checkin 版本控制，您可以轻松地向所有人推送更新。你也可以用密码保护它，在这种情况下，Xcode 会要求你在使用代码签名时解锁它。
在 IMO 看来，“很容易”篡改证书实际上是一件坏事。正如您所观察到的，团队中的其他开发人员很容易把事情搞砸，尤其是关于 TestFlight，尽管我最近从另一位开发人员那里听说 Apple 可能已经解决了这个问题。 (我自己没有证实。)
关于ios - 拥有多个正在开发的 iOS 应用程序的组织应如何管理 iOS 分发证书？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/36987995/