iOS provisioning profiles and signing identities
我有点迷失在所有证书/配置文件中。
当我通过首先在 XCode 中执行”归档”然后”分发”并选择我的临时分发配置文件来进行临时分发时，我在项目->目标->构建设置->代码签名？
一方面，我在不同的地方读到，当您归档构建时，您可以(并且确实应该)使用相同的归档进行临时测试，然后在准备好时只需使用应用商店配置文件并上传到应用商店。那种感觉是有道理的。它还告诉我，我真的可以将项目设置中的配置文件留空，实际使用”分发”操作期间选择的配置文件，签名身份实际上是与中列出的分发证书关联的私钥该配置文件。对吧？
另一方面，testflight 说明 (http://help.testflightapp.com/customer/portal/articles/1333914) 明确指出项目设置也应设置为使用 Ad-hoc 配置文件，以及相同的配置文件必须在项目设置和”分发”中使用。这意味着我不能将同一个存档同时用于临时和应用商店分发，可以吗？每次我想为这个或那个发行版发布时，我是否需要更改项目设置？
此外，如果项目设置在存档/分发场景中产生任何差异，则不清楚应该在那里使用什么代码签名身份。 Testflight 屏幕截图显示 iOS Developer 已设置为调试和发布，但 ad-hoc 和应用商店分发都没有与之关联的单独 iOS 开发人员证书，分发配置文件通常与一个且唯一的分发证书相关联。
有人可以解释一下它实际上应该如何工作吗？
谢谢
是的，您的构建设置很重要。 Xcode 从您的初始代码签名/配置配置文件配置中获取各种权利，并且仅在分发…阶段对它们进行最小的更改。
因此，如果 Xcode 在存档步骤中选择了不正确的配置文件，您最终可能会得到不正确的捆绑种子 ID、钥匙串组、APN 环境和 iCloud 权利。
Distribute… 按钮调用 PackageApplication 脚本，该脚本确保 get-task-allow 为 false(调试器无法连接)，嵌入配置文件，然后重新签名并压缩您的应用程序(尽管我可能顺序错了)。
PackageApplication 值得一读。人们可能会指责它不是很聪明，但我认为它应该更严格，并拒绝打包权利与其使用的配置文件不同的应用程序。
你可以在这里找到它Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/PackageApplication
我认为分发 Ad Hoc 构建的一种稳定工作流程是
1. 的原因是通配符配置文件(匹配多个 BundleID 的配置文件，由您手动创建或由 Xcode 自动创建)不值得麻烦。是的，它们可以让你更快地在设备上运行代码，但是如果你想使用推送通知或任何其他有趣的服务，你很快就不得不放弃它们，然后它们会在你的系统上徘徊，迟早 Xcode 会默默地选择其中一个并破坏您的 App Store 提交。
至于第 2 点(选择 App Store 配置文件)，我有点犹豫是否要在项目中指定配置文件，但 App Store 只需在您的证书到期时每年更改一次(除非您编辑证书中的应用标识符，标识符
- 所以我不能存档一次，然后从同一个存档中准备两个不同的发行版？这是否也意味着每次我更改配置文件(向其中添加新的 beta 测试人员 UDID)时，我都必须更改项目设置并将新的配置文件 UUID 提交给 git？
- 不，您可以使用与额外用户相同的配置文件辞职，但如果您更改 APN 或类似的东西，Distribute 将不会创建可安装的应用程序。如果你确实改变了一些重大的事情，你可以用手做你说的，但这很繁琐。
- 现在它变得更清晰了。仍然不确定为什么它如此复杂:)”禁止通配符配置文件”是什么意思？您指的是 XCode 自动为团队创建的 2 个配置文件吗？如果没有，我是否需要手动维护另一个开发配置文件？如果自动的会自动获取新的开发人员许可证和刷新所有新设备，为什么还需要它。开发者资料和 git checkins 的 UUID 呢？每个新的 beta 测试人员 UDID 都会经常更改。谢谢
- 我更新了答案，TL；DR 删除通配符，尤其是 Xcode 的，签入 APPSTORE 配置文件，因为它不经常更改。
- 对于复杂性(卷积？)，它是应用程序的 PKI(曾经配置过 https？)，所以我认为它不会更简单。
- 我已接受答案，谢谢！还有一个问题，那么如何禁用 XCode 创建的自动配置文件？有办法吗？
- 只要说”不”，只要它提出”解决任何问题”就大笑。
来源：https://www.codenong.com/22473806/
