证书和配置可能是一个棘手的话题，所以在无意中给自己带来一些痛苦之前先问清楚当然是个好主意！
Q1：每个帐户只有 1 个分发证书？
是的，个人和公司帐户在每个会员年度仅限于一个有效的分发证书，但是如果个人或公司认为有必要这样做（泄露的公钥/私钥，终止有权访问私钥的员工等）。我最近回答了一个问题"What are Code Signing Identities?"，这可能有助于提供一些关于编码到配置文件中的信息以及 Xcode 在执行设备构建时如何查找此信息的额外上下文。请记住，根据使用的配置文件的类型（开发与分发）将改变配置文件中编码的证书和测试设备的数量和类型。
您也绝对正确，因为您将使用一组全新的配置文件重用现有分发证书，这些配置文件使用您准备/正在编写的第二个应用程序的 App Id/Bundle Id 进行编码。
Q2：在钥匙串中安装证书而不是配置文件是什么？构建机器会受到怎样的影响？
是的，这是正确的。您的开发证书和分发证书都安装到 Keychain 中，而 Provisioning Profiles 安装到 Xcode 中的一个特殊目录中，用于代码签名操作。
假设您已经设置好构建机器并为您的第一个应用程序工作，那么您已经完成了很多艰苦的工作。您仍然需要做的事情的高级列表：
- 使用现有证书为新的 AppId 生成一组配置文件
- 在构建环境中安装 Provisioning Profile(s)
- 确保将 Xcode 项目的“代码签名身份”构建设置配置为使用新创建的配置文件，或者如果您的项目配置允许，最好使用“自动配置文件选择器”。
- 配置您的构建系统以实际制作新应用。
这些高级任务的具体 HOWTO 将在一定程度上取决于您如何设置项目和构建系统，但通常应遵循构建第一个应用程序时使用的相同工作流程。
Q3：是否有必要/好主意将构建环境分区到不同的机器上？
就这个问题的“必要”部分而言，不，您不需要物理或虚拟分离构建环境才能并行构建这些应用程序，但是您可以 如果您的业务需求需要基于每个应用程序的专用构建环境，请选择这样做。
从技术角度来看，Provisioning Profiles 提供了能够并行构建所需的 99% 的分区。唯一会遇到可能需要物理或虚拟分区的情况是，如果您是两个或多个 iOS 开发计划的成员，并且每个团队颁发的证书上的“通用名称”匹配（例如。 “iPhone Distribution: MyCompany”是 Team1 证书的通用名称，与 Team2 颁发的证书完全相同）。如果是这种情况，您会在 Xcode 中看到如下警告和错误：
代码签名错误：证书身份“iPhone Distribution: MyName”在钥匙串中出现多次。协同设计工具只需要一个。
在所有其他情况下，假设您同时安装了证书和配置文件并且正确设置了代码签名身份值，那么代码签名可以自行处理。
Q4：是否可以为两个应用重复使用相同的推送证书？
这是一个坚定的“不”。每个 App Id 都有自己的一组配置文件，这些配置文件伴随着一组权利，其中一个是推送通知。在构建具有推送通知权利的新供应配置文件时，系统会要求您生成新的推送证书——没有机会向 Apple 提供您现有的证书。这样做是为了确保推送通知“提供者”（创建发送到 Apple 推送网关的推送通知有效负载的服务器）以类似于 iOS 生态系统中的方式被沙盒化——每个 AppId 一个提供者...一个每个 AppId 的沙盒。
从安全角度来看，这可以防止攻击者通过在 Apple 的 Push Gateway 上提供有效的 Push 令牌和有效负载来向您的用户发送垃圾邮件推送通知。设置提供程序代码的第二个实例并使用在制作新的配置文件时生成的推送证书，或者更新现有的提供程序以跟踪每个应用程序级别的推送通知令牌，并在发送推送通知有效负载时使用正确的证书给苹果。不幸的是，只有您（或您的同事）才能做出此决定，因为该决定将取决于您现有提供商的技术能力以及您/您的公司愿意在同一提供商实例上采取统一推送通知的风险程度。
其他人可能会在这里提供一些关于他们如何设置自己的提供程序的额外见解，但我已经使用完全独立的实例来防止出现这样的情况：一个应用程序的推送通知的更新可能会破坏一个完全不同的应用程序的推送通知.