在此之前,我想澄清一些有关证书和配置文件以及构建环境的内容：
问题1：我认为Apple帐户只能拥有一个分发证书,这是否正确,因此这将在两个应用程序中使用？ (通过它出现在配置文件中,我将创建一组新的配置文件,其中包含新应用程序的新应用程序ID).
Q2：由于它是证书而不是安装在钥匙串中的配置文件,我假设新应用程序应该构建在当前为当前应用程序设置的构建机器上.
Q3：与Q2相关,我想知道是否有必要或者好主意将当前应用程序和新应用程序的构建通过将它们放在不同的物理构建机器上(或将构建机器分区为虚拟机)来分离.如果两个应用程序使用不同的证书,我认为这是必要的(或至少分区钥匙串).
我担心会出现证书和钥匙串问题.
但是,如果对Q1的答案是只有一个分发证书,那么理论上应该不需要为每个应用程序分别构建机器吗？
问题4：两个应用程序都使用推送通知,是否可以为两者使用相同的推送证书(当然在不同的配置文件中)？
TIA
解决方法
Q1：每个帐户只有1个分发证书？
是的,个人和公司帐户仅限于每个会员年度的单个活动分发证书,但是如果个人或公司认为有必要,可以随时撤销和重新签发此证书(受损的公钥/私钥,终止员工可以访问私钥等).我最近回答了一个问题“What are Code Signing Identities?”,它可能有助于提供有关编码到供应配置文件中的信息的一些附加上下文,以及Xcode在执行设备构建时如何查找此信息.请记住,根据所使用的供应配置文件的类型(开发与分发),将更改供应配置文件中编码的证书和测试设备的数量和类型.
您也绝对正确,因为您将重用现有的分发证书,其中包含一组全新的供应配置文件,这些配置文件使用您准备/正在编写的第二个应用程序的App Id / Bundle Id进行编码.
Q2：证书而不是配置文件是在Keychain安装的吗？构建机器将如何受到影响？
是的,这是正确的.开发证书和分发证书都是安装到Keychain中的,而Provisioning Profiles安装在Xcode中的特殊目录中,用于代码签名操作.
假设您已经为第一个应用程序设置了构建计算机,那么您已经完成了很多艰苦的工作.您仍需要执行的高级别事项列表：
>使用现有证书为新AppId生成一组供应配置文件
>在Build环境中安装Provisioning Profile
>确保Xcode项目的“代码签名标识”构建设置配置为使用新创建的供应配置文件,或者如果项目配置允许,则更理想地使用“自动配置文件选择器”.
>配置您的Build系统以实际制作新应用程序.
这些高级任务的具体HOWTO将在某种程度上取决于您如何设置项目和构建系统,但通常应遵循构建第一个应用程序时使用的相同工作流程.
问题3：将构建环境分区到不同的机器上是否有必要/好主意？
至于这个问题的“必要”部分,不,您不需要在构建环境中进行物理或虚拟分离,以便能够并排构建这些应用程序,但是如果您的业务可以选择这样做需要是您需要基于每个应用程序的专用构建环境.
从技术角度来看,Provisioning Profiles提供了99％的并行构建所必需的分区.如果您是两个或更多iOS开发计划的成员并且每个团队签发的证书上的“公共名称”匹配(例如,您可能遇到可能需要进行物理或虚拟分区的情况). “iPhone distribution：MyCompany”是Team1证书的通用名称,与Team2颁发的证书完全相同.如果遇到这种情况,您会在Xcode中看到警告和错误,如下所示：
Code Sign error: Certificate identity ‘iPhone distribution: MyName’ appears more than once in the keychain. The codesign tool requires there only be one.
在所有其他情况下,假设您同时安装了证书和配置文件以及正确设置了代码签名标识值,则代码签名可以自行处理.
问题4：对两个应用程序重用相同的推送证书是否可以？
这个是坚实的’不’.每个App Id都有自己的供应配置文件集,其中包含一组权利,其中一个是推送通知.使用推送通知权利构建新的配置文件时,系统会要求您生成新的推送证书 – 没有机会向Apple提供现有证书.这样做是为了确保推送通知’提供商'(您的服务器创建发送到Apple的推送网关的推送通知有效负载)以类似于iOS生态系统中的方式进行沙盒化 – 每个AppId一个提供商…一个每个AppId的沙箱.
从安全角度来看,这可以防止攻击者通过在Apple的推送网关上提供有效的推送令牌和有效负载,向您的用户发送垃圾推送通知.设置提供商代码的第二个实例并使用在创建新配置文件时生成的推送证书或更新现有提供商以在每个应用程序级别跟踪推送通知令牌,并在发送推送通知有效负载时使用正确的证书到Apple.遗憾的是,只有您(或您的同事)才能做出此决定,因为该决定将受现有提供商的技术能力以及您/贵公司愿意在同一提供商实例上统一推送通知的风险程度的约束.
其他人可能会在这里进行管理,并提供一些关于他们如何设置自己的提供商的额外见解,但我已经完成了单独的实例,以防止一个应用程序的推送通知的更新可能会破坏针对完全不同的应用程序的推送通知.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
