ios

IOS

在门户中，创建的所有应用组 ID 都必须以group.开头group. ; 门户实际上会强制执行此操作，因此甚至无法在没有该前缀的情况下在那里注册组。

如果然后在门户中的应用程序 ID 上设置应用程序组 ID 并为该应用程序 ID 创建 iOS 配置文件，则应用程序组将完全按照注册时的方式嵌入到配置文件中。 看看这样的配置文件，你会在那里找到应用程序组 ID。

如果 iOS 应用程序在其 codesign 授权文件中有应用程序组 ID，则 codesign 将确保在配置文件中也可以找到来自授权的组 ID，否则将拒绝签署应用程序。 因此，供应配置文件将这些应用程序组的使用列入白名单。

当您在 Xcode 中的功能部分为应用程序配置应用程序组 ID 时，Xcode 会为您将该 ID 放入代码设计授权文件中。 在那里为 iOS 应用程序配置的应用程序组必须与门户中注册的应用程序组 ID 完全匹配。

苹果系统

但是，对于 macOS，情况完全不同！

如果您将应用程序组 ID 添加到门户中的应用程序 ID，这不会影响为该应用程序 ID 创建的 macOS 配置文件。 自己看看； 在生成的配置文件中找不到应用程序组 ID！ 因此，在 macOS 上，配置文件不会将任何应用程序组的使用列入白名单。 您可以将任何应用程序组 ID 放入您的权利文件中，这将始终签名，因为 codesign 不在乎。 Codesign 甚至不在乎您的应用程序组 ID 是否以您的团队 ID 为前缀（或者至少它过去没有使用过，也许现在是这样）。

与 iOS 不同，macOS 上应用程序组 ID 的唯一性不是由门户强制执行的，而是由 Apple 要求您的应用程序组 ID 以您的团队 ID 开头这一事实强制执行，因此跨团队的唯一性得到保证，并在您的应用程序中强制执行唯一性自己的团队是你自己的任务。

实际上，您根本不需要在门户中为 macOS 应用程序注册应用程序组 ID。 只需将您想要的应用程序组 ID 放入您的 Xcode 项目功能中，从而放入您的权利文件中就足够了。 许多人认为他们在门户中注册group.TEAM_ID.<whatever>时已经正确注册了他们的 macOS 应用程序组，并且一些魔法使这个组在没有group.情况下工作group. Mac 上的前缀，但事实并非如此。 他们刚刚注册了一个同名的 iOS 群组，而TEAM.<whatever>在 Mac 上运行的原因是因为该群组不需要在门户中注册。

现在有些读者会说：等一下； 如果我可以将任何应用程序组 ID 放入我的权利文件中并且它始终会签名，那么实际上是谁强制它以我的团队 ID 为前缀？ Mac 应用商店。 Mac App Store 不允许您发布应用组 ID 未以发布者团队 ID 为前缀的应用。 如果您尝试，上传将失败。

应用程序组和安全性

您可能想知道：对于在应用商店之外分发的应用，谁强制要求应用组以您的团队 ID 为前缀？ 没有人。 但是，在应用程序商店之外分发的应用程序可以声称是任何应用程序组的成员，甚至是来自不同开发团队的应用程序，那么这如何安全呢？ 不是。 在应用程序商店之外分发的应用程序甚至不必经过沙盒处理，如果它们没有经过沙盒处理，它们就可以访问您的整个磁盘，包括所有应用程序的所有应用程序组文件夹，那么如果错误声明，安全性将如何降低成为应用程序组的成员？

如果出于安全原因，在应用商店之外分发的应用程序可能会被沙箱化，但即使他们选择加入，他们也可以根据需要或希望自由地在自己的沙箱中插入尽可能多的漏洞，因为与通过分发时不同在应用程序商店，没有任何审查可以确保他们只戳需要和合理的漏洞。

在 iOS 上，所有应用程序总是通过 App Store 进行沙盒化和分发，因此这个问题甚至不会出现。

应用程序组和钥匙串共享

钥匙串项目共享怎么样？ 通过应用程序组共享钥匙串项目仅适用于 iOS，不适用于 macOS； 正是因为这个原因！ 在 Mac 上会不安全。 在 macOS 上，仅与钥匙串访问组共享有效，并且那些在配置文件中，也在 macOS 配置文件中，并且对于这些代码，代码将始终强制配置文件在签署任何内容之前将它们列入白名单。