iOS/OSX 应用组 ID，以 "group." 或 "team-id." 开头？
iOS/OSX App Group Ids, start them with "group." or "team-id."?
在 Provisioning Portal（或现在的任何名称）中创建应用程序组 ID 时，它会向 "Enter a unique identifier for your App Group, starting with the string 'group'" 说明并且似乎在输入字段中强制执行该 ID。此外，许多示例代码使用应用组 ID 字符串，例如 "group.com.company.blah".
但是，我看到在整个文档中链接的最终部分，
App Sandbox Design Guide > App Sandbox In Depth > Container Directories and File System Access > The Application Group Container Directory and Entitlements Key Rerefence > Enabling App Sandbox > Adding an App to an App Group，直接反驳这个，明明是"must begin with your development team ID, followed by a period".
这些部分给出的示例分别如 "Z123456789.com.example.app-group" 和 "DG29478A379Q6483R9214.HolstFirstAppSuite"。 （哇，最后一个是超级奇怪的团队ID还是什么？）
对于这种不一致的情况，我该怎么做才能让应用程序组 ID 发挥作用？我应该进入 Provisioning Portal "group.TEAM-ID.com.example.blah" 吗？我应该在我的源代码字符串中使用相同的字符串，还是像许多代码示例一样省略 "group." 部分？还是文档有误，根本不需要团队 ID？
上下文...我一直在尝试更新 iOS cocoapod 的测试应用程序，这样我就可以看到扩展程序 <-> 应用程序通信正在运行。在将应用程序 ID 和组 ID 更新为我控制的一个之后，当使用类似于项目原始组 ID 时，如 "group.com.mycompany.thingie"，我看到 containerURLForSecurityApplicationGroupIdentifier: 除了 return nil 什么都不做nothing else 已经修复了它。
更新：（添加这个是为了清楚地看到 SO 如何通知我这个 Q 获得了很多点击） 事实证明这个东西比我原先想象的更宽容，因为nil 结果证明是（大部分？）我做的。查看答案及其评论线程。我还没有检查文档和示例是否更清楚。
在 "Certificates, Identifiers & Profiles" 内的 https://developer.apple.com 上，当您转到 "App Groups" 部分并首先生成您的应用组时，所需要的只是强制执行的 group.com.companyname.appname
只要 com.companyname.appname 与您在一般情况下设置的目标包标识符相匹配，您就应该能够转到 "Capabilities" 选项卡，打开 "App Groups"单击刷新符号，您刚刚在 Provisioning Portal 中创建的组应该出现在那里，因为 "group.com.companyname.appname" 您可以选择将其取消，然后将出现权利错误。单击 "fix issue" 应该会自动解决它。
现在，如果您导航到您的权利文件，您会注意到 "com.apple.security.applications-groups" 将有一个项目，它将被设置为完全相同的 "group.com.companyname.appname" 值。
我已经在设备上进行了测试，目前还没有任何问题。这并不能解释文档中的不一致，但我可以保证这是有效的。
我在提交我的应用程序的 macOS Sierra 版本时被 iOS 和 macOS 之间的不一致所困扰。
group.better.fyi 适用于 iOS 提交，但在 macOS 提交期间会导致以下错误（否则运行良好，没有警告或错误）：
ERROR ITMS-90286: "Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on macOS. Specifically, value '[group.better.fyi]' for key 'com.apple.security.application-groups' in 'ind.ie.Better-Mac.pkg/Payload/Better.app/Contents/PlugIns/Blocker-Mac.appex/Contents/MacOS/Blocker-Mac' is not supported. This value should be a string or an array of strings, each starting with your TEAMID followed by a dot '.' ."
在“应用程序组”下的“功能”选项卡中将其替换为 $(TeamIdentifierPrefix)better.fyi 解决了该问题。
这当然会在 iOS 和 Mac 应用程序之间造成不一致。
tl;dr 版本：
但如果你想知道这一切背后的所有细节，请看下文。
iOS
在门户中，创建的所有应用组 ID 必须以 group. 开头；门户网站实际上会强制执行此操作，因此如果没有该前缀甚至无法在那里注册一个组。
如果随后在门户中的应用 ID 上设置了应用组 ID，并且为该应用 ID 创建了 iOS 配置文件，则应用组将完全按照注册时的样子嵌入到配置文件中.看看这样的配置文件，您会在那里找到应用程序组 ID。
如果 iOS 应用在其协同设计授权文件中有应用组 ID，协同设计将确保授权中的组 ID 也在配置文件中找到，否则它将拒绝对该应用进行签名。因此，配置文件将这些应用程序组的使用列入白名单。
当您在 Xcode 中的功能部分为应用配置应用组 ID 时，Xcode 会为您将该 ID 放入代码签名授权文件中。为 iOS 个应用配置的应用组必须与在门户中注册的应用组 ID 完全匹配。
macOS
不过，对于 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 应用程序组，并且一些魔法使这个组在 Mac 上没有 group. 前缀的情况下工作，但事实并非如此案件。他们刚刚注册了一个同名的 iOS 群组，TEAM.<whatever> 在 Mac 上工作的原因是因为该群组不需要在门户中注册。
现在有些读者会说：等一下；如果我可以将任何应用程序组 ID 放入我的权利文件中并且它将始终签名，那么实际上谁在强制它以我的团队 ID 为前缀？ Mac 应用商店。 Mac App Store 不允许您发布应用组 ID 未以发布者团队 ID 为前缀的应用。如果您尝试，上传将失败。
应用程序组和安全
您可能想知道：对于在应用商店外分发的应用，谁强制要求应用组以您的团队 ID 为前缀？没有人。但是，在应用商店之外分发的应用程序可以声称自己是任何应用程序组的成员，甚至是来自不同开发团队的应用程序，那么这如何保证安全呢？它不是。在应用程序商店之外分发的应用程序甚至不必进行沙盒化，如果它们没有进行沙盒化，它们就可以访问您的整个磁盘，包括所有应用程序的所有应用程序组文件夹，所以如果不正确地声明它们会如何降低安全性成为应用组的成员？
如果出于安全原因希望限制自己，则在应用程序商店外分发的应用程序可能会被沙盒化，但即使他们选择加入，他们也可以根据需要或希望自由地在自己的沙盒中戳出尽可能多的漏洞因为与通过应用商店分发时不同，没有审查可以确保他们只戳需要和合理的漏洞。
在 iOS 上，所有应用程序始终通过 App Store 进行沙盒化和分发，因此甚至不会出现这个问题。
应用组和钥匙串共享
钥匙串项目共享怎么样？通过应用组共享钥匙串项目仅适用于 iOS，不适用于 macOS；正是出于这个原因！在 Mac 上会不安全。在 macOS 上，只有与钥匙串访问组共享才有效，这些在配置文件中，也在 macOS 配置文件中，对于那些代码签名，将始终强制配置文件在签署任何内容之前将它们列入白名单。
来自 Apple 的参考资料
您想直接由 Apple 确认所有这些吗？当然，这是我们最著名的 Apple 技术支持专家 Quinn 提供的参考资料：
https://developer.apple.com/forums/thread/133677?answerId=422887022#422887022
在 Provisioning Portal（或现在的任何名称）中创建应用程序组 ID 时，它会向 "Enter a unique identifier for your App Group, starting with the string 'group'" 说明并且似乎在输入字段中强制执行该 ID。此外，许多示例代码使用应用组 ID 字符串，例如 "group.com.company.blah".
但是，我看到在整个文档中链接的最终部分， App Sandbox Design Guide > App Sandbox In Depth > Container Directories and File System Access > The Application Group Container Directory and Entitlements Key Rerefence > Enabling App Sandbox > Adding an App to an App Group，直接反驳这个，明明是"must begin with your development team ID, followed by a period".
这些部分给出的示例分别如 "Z123456789.com.example.app-group" 和 "DG29478A379Q6483R9214.HolstFirstAppSuite"。 （哇，最后一个是超级奇怪的团队ID还是什么？）
对于这种不一致的情况，我该怎么做才能让应用程序组 ID 发挥作用？我应该进入 Provisioning Portal "group.TEAM-ID.com.example.blah" 吗？我应该在我的源代码字符串中使用相同的字符串，还是像许多代码示例一样省略 "group." 部分？还是文档有误，根本不需要团队 ID？
上下文...我一直在尝试更新 iOS cocoapod 的测试应用程序，这样我就可以看到扩展程序 <-> 应用程序通信正在运行。在将应用程序 ID 和组 ID 更新为我控制的一个之后，当使用类似于项目原始组 ID 时，如 "group.com.mycompany.thingie"，我看到 containerURLForSecurityApplicationGroupIdentifier: 除了 return nil 什么都不做nothing else 已经修复了它。
更新：（添加这个是为了清楚地看到 SO 如何通知我这个 Q 获得了很多点击） 事实证明这个东西比我原先想象的更宽容，因为nil 结果证明是（大部分？）我做的。查看答案及其评论线程。我还没有检查文档和示例是否更清楚。
在 "Certificates, Identifiers & Profiles" 内的 https://developer.apple.com 上，当您转到 "App Groups" 部分并首先生成您的应用组时，所需要的只是强制执行的 group.com.companyname.appname
只要 com.companyname.appname 与您在一般情况下设置的目标包标识符相匹配，您就应该能够转到 "Capabilities" 选项卡，打开 "App Groups"单击刷新符号，您刚刚在 Provisioning Portal 中创建的组应该出现在那里，因为 "group.com.companyname.appname" 您可以选择将其取消，然后将出现权利错误。单击 "fix issue" 应该会自动解决它。
现在，如果您导航到您的权利文件，您会注意到 "com.apple.security.applications-groups" 将有一个项目，它将被设置为完全相同的 "group.com.companyname.appname" 值。
我已经在设备上进行了测试，目前还没有任何问题。这并不能解释文档中的不一致，但我可以保证这是有效的。
我在提交我的应用程序的 macOS Sierra 版本时被 iOS 和 macOS 之间的不一致所困扰。
group.better.fyi 适用于 iOS 提交，但在 macOS 提交期间会导致以下错误（否则运行良好，没有警告或错误）：
ERROR ITMS-90286: "Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on macOS. Specifically, value '[group.better.fyi]' for key 'com.apple.security.application-groups' in 'ind.ie.Better-Mac.pkg/Payload/Better.app/Contents/PlugIns/Blocker-Mac.appex/Contents/MacOS/Blocker-Mac' is not supported. This value should be a string or an array of strings, each starting with your TEAMID followed by a dot '.' ."
在“应用程序组”下的“功能”选项卡中将其替换为 $(TeamIdentifierPrefix)better.fyi 解决了该问题。
这当然会在 iOS 和 Mac 应用程序之间造成不一致。
tl;dr 版本：
但如果你想知道这一切背后的所有细节，请看下文。
iOS
在门户中，创建的所有应用组 ID 必须以 group. 开头；门户网站实际上会强制执行此操作，因此如果没有该前缀甚至无法在那里注册一个组。
如果随后在门户中的应用 ID 上设置了应用组 ID，并且为该应用 ID 创建了 iOS 配置文件，则应用组将完全按照注册时的样子嵌入到配置文件中.看看这样的配置文件，您会在那里找到应用程序组 ID。
如果 iOS 应用在其协同设计授权文件中有应用组 ID，协同设计将确保授权中的组 ID 也在配置文件中找到，否则它将拒绝对该应用进行签名。因此，配置文件将这些应用程序组的使用列入白名单。
当您在 Xcode 中的功能部分为应用配置应用组 ID 时，Xcode 会为您将该 ID 放入代码签名授权文件中。为 iOS 个应用配置的应用组必须与在门户中注册的应用组 ID 完全匹配。
macOS
不过，对于 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 应用程序组，并且一些魔法使这个组在 Mac 上没有 group. 前缀的情况下工作，但事实并非如此案件。他们刚刚注册了一个同名的 iOS 群组，TEAM.<whatever> 在 Mac 上工作的原因是因为该群组不需要在门户中注册。
现在有些读者会说：等一下；如果我可以将任何应用程序组 ID 放入我的权利文件中并且它将始终签名，那么实际上谁在强制它以我的团队 ID 为前缀？ Mac 应用商店。 Mac App Store 不允许您发布应用组 ID 未以发布者团队 ID 为前缀的应用。如果您尝试，上传将失败。
应用程序组和安全
您可能想知道：对于在应用商店外分发的应用，谁强制要求应用组以您的团队 ID 为前缀？没有人。但是，在应用商店之外分发的应用程序可以声称自己是任何应用程序组的成员，甚至是来自不同开发团队的应用程序，那么这如何保证安全呢？它不是。在应用程序商店之外分发的应用程序甚至不必进行沙盒化，如果它们没有进行沙盒化，它们就可以访问您的整个磁盘，包括所有应用程序的所有应用程序组文件夹，所以如果不正确地声明它们会如何降低安全性成为应用组的成员？
如果出于安全原因希望限制自己，则在应用程序商店外分发的应用程序可能会被沙盒化，但即使他们选择加入，他们也可以根据需要或希望自由地在自己的沙盒中戳出尽可能多的漏洞因为与通过应用商店分发时不同，没有审查可以确保他们只戳需要和合理的漏洞。
在 iOS 上，所有应用程序始终通过 App Store 进行沙盒化和分发，因此甚至不会出现这个问题。
应用组和钥匙串共享
钥匙串项目共享怎么样？通过应用组共享钥匙串项目仅适用于 iOS，不适用于 macOS；正是出于这个原因！在 Mac 上会不安全。在 macOS 上，只有与钥匙串访问组共享才有效，这些在配置文件中，也在 macOS 配置文件中，对于那些代码签名，将始终强制配置文件在签署任何内容之前将它们列入白名单。
来自 Apple 的参考资料
您想直接由 Apple 确认所有这些吗？当然，这是我们最著名的 Apple 技术支持专家 Quinn 提供的参考资料：
https://developer.apple.com/forums/thread/133677?answerId=422887022#422887022