多个产品的证书和configuration文件组织
在我的工作场所，我们已经完成了一个iOS应用程序的开发，即将踏上第二步。
在此之前，我想澄清一些关于证书和configuration文件和构build环境的事情：
问题1：我认为苹果账户只能拥有一个分销证书是否正确，因此这两个应用程序都可以使用？ （通过configuration文件中的configuration文件，我将创build一组包含新应用的新应用ID的configuration文件）。
Q2：因为这是证书，而不是安装到钥匙串中的configuration文件，所以我假设新的应用程序应该build立在当前为当前应用程序设置的生成机器上。
问题3：与第二季度相关，我想知道是否有必要，或者是一个好主意，通过将当前应用程序和新应用程序的构build放在不同的物理构build计算机上（或将构build计算机划分到虚拟机中） 。 如果这两个应用程序使用不同的证书，我认为这是必要的（或至less分割钥匙链）。 我担心出现证书和钥匙串问题。 但是，如果第一季度的答案是只有一个分发证书，那么理论上应该不需要为每个应用程序分别构build机器。
问题4：这两个应用程序都使用推送通知，可以同时使用相同的推送证书（当然是不同的configuration文件）？
TIA
证书和configuration可能是一个棘手的话题，所以在不经意间引起一些痛苦之前先问一下是一个好主意！
Q1：每个账户只有一个分销证书？
是的，个人和公司账户每个会员年度只限于一份积极的分销证书，但如果个人或公司认为有必要，可以随时吊销和重新发放证书（公钥/私钥泄密，员工离职访问私钥等）。 我最近回答了一个问题： “什么是代码签名身份？” 这可能有助于提供关于编码到供应configuration文件中的信息的一些额外上下文，以及在执行设备构build时Xcode如何查找此信息。 请记住，根据使用的供应configuration文件（开发与分配）的types，将更改在供应configuration文件中编码的证书和testing设备的数量和types。
你也是绝对正确的，你将重复使用现有的分发证书和一套全新的预configuration文件，这些预configuration文件是用准备写/正在编写的第二个应用程序的App ID / Bundle ID进行编码的。
Q2：证书而不是Provisioningconfiguration文件是在Keychain中安装的权限？ build造机器如何受到影响？
是的，这是正确的。 您的开发证书和分发证书都是安装到Keychain中的，而Provisioning Profiles安装到Xcode中的特殊目录中以便与Code Sign操作一起使用。
假设你已经有了你的机器设置，并为你的第一个应用程序工作，你已经做了很多艰苦的工作。 您仍然需要做的事情的高级列表：
- 使用现有证书为新的AppId生成一组供应configuration文件
- 在生成环境中安装供应configuration文件
- 确保将Xcode项目的“代码签名标识”版本设置configuration为使用新创build的预configuration文件，如果您的项目configuration允许，则更理想地使用“自动configuration文件select器”。
- configuration您的生成系统实际上使新的应用程序。
这些高级任务的具体HOWTOs将取决于你如何设置你的项目和构build系统，但通常应该遵循与构build第一个应用程序时使用的相同的工作stream程。
问题3：将构build环境分割到不同的机器上是否有必要/好主意？
就这个问题的“必要”部分而言，不，不要求您物理地或虚拟地分离构build环境，以便能够并行构build这些应用程序，但是如果您的业务可以select这样做需求是这样的，你需要每个应用程序的专用构build环境。
从技术angular度来看，Provisioning Profiles提供了能够并行构build所需的99％的分区。 如果你是两个或两个以上iOS开发程序的成员，并且每个团队发布的证书上的“通用名称”匹配，那么唯一一次遇到可能需要物理或虚拟分区的情况就是： “iPhone Distribution：MyCompany”是来自Team1的证书的通用名称，与Team2颁发的证书完全相同）。 如果是这种情况，你会看到Xcode中的警告和错误，如下所示：
代码签名错误：证书身份“iPhone分发：我的名字”在钥匙串中多次出现。 codesign工具要求只有一个。
在其他所有情况下，假设您安装了证书和供应configuration文件并且Code Signing Identity值设置正确，那么Code Sign可以自行处理。
问题4：两个应用程序重复使用相同的推送证书是否可以？
这是一个坚实的“不”。 每个应用程序标识都有自己的一组configurationconfiguration文件，配有一组权利，其中一个是推送通知。 当使用推送通知权利构build新的供应configuration文件时，系统会要求您生成新的推送证书 – 没有机会向Apple提供现有的证书。 这样做是为了确保推送通知“提供者”（创build发送到Apple推送网关的推送通知有效内容的服务器）以类似于iOS生态系统中的方式进行沙盒处理 – 每个AppId只有一个提供者…每个AppId的沙箱。
从安全的angular度来看，这可以防止攻击者仅通过在Apple的Push网关上提供有效的Push令牌和有效负载来向用户发送垃圾邮件推送通知。 您可以设置提供商代码的第二个实例，并使用生成新提供configuration文件时生成的推送证书，或者更新您的现有提供商以跟踪每个应用程序级别的推送通知令牌，并在发送推送通知有效负载时使用正确的证书到苹果。 不幸的是，只有你（或你的同事）可以做出这个决定，因为决定将受现有提供者的技术能力以及你/公司愿意在同一提供者实例上统一推送通知的风险程度的控制。
其他人可能会在这里提供一些关于他们如何设置他们自己的提供商的其他见解，但我已经完全分开的实例，以防止一个应用程序的推送通知的更新可能会打破一个完全不同的应用程序的推送通知的情况。