iOS/OSX 应用程序组 ID，以“组”开头。还是“团队ID”？答案

【问题标题】：iOS/OSX App Group Ids, start them with "group." or "team-id."?iOS/OSX 应用程序组 ID，以“组”开头。还是“团队ID”？
【发布时间】：2015-06-24 16:38:52
【问题描述】：

在 Provisioning Portal（或现在称为的任何名称）中创建 App Group id 时，它会说“为您的 App Group 输入一个唯一标识符，以字符串 'group' 开头”，并且似乎在条目中强制执行此操作场地。此外，许多示例代码使用应用程序组 id 字符串，例如“group.com.company.blah”。

但是，我在整个文档中看到链接的权威部分， App Sandbox Design Guide > App Sandbox In Depth > Container Directories and File System Access > The Application Group Container Directory 和 Entitlements Key Rerefence > Enabling App Sandbox > Adding an App to an App Group 直接反驳这一点，明确表示“必须以您的开发团队 ID 开头，后跟句号”。

这些部分中给出的示例分别类似于“Z123456789.com.example.app-group”和“DG29478A379Q6483R9214.HolstFirstAppSuite”。 （哇，最后一个是超级奇怪的团队 ID 还是什么？）

因此，由于存在这种不一致，我该怎么做才能使应用组 ID 正常工作？我应该进入供应门户“group.TEAM-ID.com.example.blah”吗？我应该在我的源代码字符串中使用相同的字符串，还是省略“组”。部分就像许多代码示例？还是文档有误，并且永远不需要团队 ID？

上下文...我一直在尝试更新 iOS cocoapod 的测试应用程序，以便我可以看到扩展程序应用程序通信在起作用。将应用程序 id 和组 id 更新到我的控制范围后，当使用类似于项目原始组 id 的组 id 时，例如“group.com.mycompany.thingie”，我看到containerURLForSecurityApplicationGroupIdentifier: 除了返回 nil 和 @ 什么都不做987654323@已修复。

更新：（添加这个是为了清楚地看到 SO 是如何告诉我这个 Q 得到了很多点击） 事实证明，这个东西比我最初想象的更宽容，因为 nil 结果变成（主要是？）我的所作所为。请参阅答案及其评论线程。我还没有检查文档和示例是否更清晰。

【问题讨论】：

如何在macOS github.com/onmyway133/blog/issues/201共享应用组UserDefaults

标签： ios macos cocoa cocoa-touch appstore-sandbox

【解决方案1】：

当您转到“应用程序组”部分并首先生成您的应用程序组时，在“证书、标识符和配置文件”内的 https://developer.apple.com 上，所需要的只是强制执行的 group.com.companyname.appname

只要 com.companyname.appname 与您在常规下为目标设置的捆绑标识符匹配，您应该能够然后转到“功能”选项卡，打开“应用程序组”单击刷新符号并您刚刚在 Provisioning Portal 中创建的组应该出现在那里，作为“group.com.companyname.appname”，您可以选择将其选中，然后会出现权利错误。单击“修复问题”应该会自动解决它。

现在，如果您导航到您的权利文件，您会注意到“com.apple.security.applications-groups”将有一个项目，它将被设置为完全相同的“group.com.companyname.appname”值.

我已经在设备上进行了测试，还没有出现任何问题。这并不能解释文档中的不一致，但我可以保证这是可行的。

【讨论】：

“只要 com.companyname.appname 与您设置的捆绑标识符相匹配” .. 对于应用程序和扩展程序，或多个应用程序的集合，不能为真。那么“组”之后的组 id 值是否有限制。部分与否？
对于我在 Apple 的“WatchKit Catalog Watchkit App”示例代码中看到的扩展，捆绑标识符选择了一个附加部分，例如“com.example.apple-samplecode.WatchKit-Catalog.watchkitextension " 然后对于 WatchKit 应用程序，它还选择了一个附加部分 "com.example.apple-samplecode.WatchKit-Catalog.watchkitapp" 所以也许唯一的限制是捆绑标识符的第一部分。
注意：我刚刚更改了我的应用程序和扩展程序的包 ID，重新创建了一个与应用程序包 ID 匹配的组 ID，更新了功能、信息列表、应用程序中的字符串。所有签名问题都已修复，所有权利复选标记都已检查，一切都在没有警告的情况下构建，但仍然看到 containerURLForSecurityApplicationGroupIdentifier：在应用程序中调用时返回 nil --- 结果证明这是一个愚蠢的程序员错误：正在将 msg 发送到 nil文件管理器实例。也许它一直在工作：^/
备案：以上应该确实有效，但仅适用于iOS目标。对于 OSX，您需要 $(TeamIdentifierPrefix)$(CFBundleIdentifier) 格式，其中 $(TeamIdentifierPrefix) 是必需的，并且 $(CFBundleIdentifier) 是可选的（可以是您选择的任何唯一值），如果 $(TeamIdentifierPrefix) 不用作组 ID前缀在验证上传到应用商店时会出错
错误将是这样的：无效的代码签名权利。您的应用程序包的签名包含 Mac OS X 不支持的代码签名权利。具体而言，不支持密钥“com.apple.security.application-groups”的值。这个值应该是一个字符串或一个字符串数组，每个字符串都以您的 TEAMID 开头，后跟一个点 '.' .

【解决方案2】：

在提交我的应用程序的 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 应用程序之间造成不一致。

【讨论】：

是的，但是你可能会得到一个错误，比如“使用带有容器的 kCFPreferencesAnyUser 只允许用于系统容器，从 cfprefsd 分离”（stackoverflow.com/questions/38275395/…）——真是奇怪的情况。
我没有：AFAIK，可以忽略此错误消息，因为它是错误的，并不表示行为发生变化。

【解决方案3】：

tl;dr 版本：https://stackoverflow.com/a/66647419/15809
但如果你想知道这一切背后的所有细节，请看下文。

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 应用程序组，并且一些魔法使该组在没有 group. 前缀的情况下在 Mac 上工作，但事实并非如此。他们刚刚注册了一个同名的 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

【讨论】：