I regularly see folks confused by the difference in behaviour of app groups between macOS and iOS. There have been substantial changes in this space recently. While much of this is now covered in the official docs (r. 92322409), I’ve updated this post to go into all the gory details.
If you have questions or comments, start a new thread with the details. Put it in the App & System Services > Core OS topic area and tag it with Code Signing and Entitlements. Oh, and if your question is about app group containers, also include Files and Storage.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
App Groups: macOS vs iOS: Working Towards Harmony
There are two styles of app group ID:
iOS-style app group IDs start with group., for example, group.eskimo1.test.
macOS-style app group IDs start with your Team ID, for example, SKMME9E2Y8.eskimo1.test.
This difference has been the source of numerous weird problems over the years. Starting in Feb 2025, iOS-style app group IDs are fully supported on macOS for all product types [1]. If you’re writing new code that uses app groups, use an iOS-style app group ID. If you have existing code that uses a macOS-style app group ID, consider how you might transition to the iOS style.
IMPORTANT The Feb 2025 changes aren’t tied to an OS release but rather to a Developer website update. For more on this, see Feb 2025 Changes, below.
[1] If your product is a standalone executable, like a daemon or agent, wrap it in an app-like structure, as explained in Signing a daemon with a restricted entitlement.
iOS-Style App Group IDs
An iOS-style app group ID has the following features:
It starts with the group. prefix, for example, group.eskimo1.test.
You allocate it on the Developer website. This assigns the app group ID to your team.
You then claim access to it by listing it in the App Groups entitlement (com.apple.security.application-groups) entitlement.
That claim must be authorised by a provisioning profile [1]. The Developer website will only let you include your team’s app group IDs in your profile.
For more background on provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles.
iOS-style app group IDs originated on iOS with iOS 3.0. They’ve always been supported on iOS’s child platforms (iPadOS, tvOS, visionOS, and watchOS). On the Mac:
They’ve been supported by Mac Catalyst since that technology was introduced.
Likewise for iOS Apps on Mac.
Starting in Feb 2025, they’re supported for other Mac products.
[1] Strictly speaking macOS does not require that, but if your claim is not authorised by a profile then you might run into other problems. See Entitlements-Validated Flag, below.
macOS-Style App Group IDs
A macOS-style app group ID has the following features:
It should start with your Team ID [1], for example, SKMME9E2Y8.eskimo1.test.
It can’t be explicitly allocated on the Developer website.
Code that isn’t sandboxed doesn’t need to claim the app group ID in the App Groups entitlement. [2]
To use an app group, claim the app group ID in the App Groups entitlement.
The App Groups entitlement is not restricted on macOS, meaning that this claim doesn’t need to be authorised by a provisioning profile [3].
However, if you claim an app group ID that’s not authorised in some way, you might run into problems. More on that later in this post.
If you submit an app to the Mac App Store, the submission process checks that your app group IDs make sense, that is, they either start with your Team ID (macOS style) or are assigned to your team (iOS style).
[1] This is “should” because, historically, macOS has not actually required it. However, that’s now changing, with things like app group container protection.
[2] This was true prior to macOS 15. It may still technically be true in macOS 15 and later, but the most important thing, access to the app group container, requires the entitlement because of app group container protection.
[3] Technically it’s a validation-required entitlement, something that we’ll come back to in the Entitlements-Validated Flag section.
Feb 2025 Changes
On 21 Feb 2025 we rolled out a change to the Developer website that completes the support for iOS-style app group IDs on the Mac. Specifically, it’s now possible to create a Mac provisioning profile that authorises the use of an iOS-style app group ID.
Note This change doesn’t affect Mac Catalyst or iOS Apps on Mac, which have always been able to use iOS-style app group IDs on the Mac.
Prior to this change it was possible to use an iOS-style app group ID on the Mac but that might result in some weird behaviour. Later sections of this post describe some of those problems. Of course, that information is now only of historical interest because, if you’re using an iOS-style app group, you can and should authorise that use with a provisioning profile.
We also started seeding Xcode 16.3, which has since been release. This is aware of the Developer website change, and its Signing & Capabilities editor actively encourages you to use iOS-style app groups IDs in all products.
Note This Xcode behaviour is the only option for iOS and its child platforms. With Xcode 16.3, it’s now the default for macOS as well. If you have existing project, enable this behaviour using the Register App Groups build setting.
Finally, we updated a number of app group documentation pages, including App Groups entitlement and Configuring app groups.
Crossing the Streams
In some circumstances you might need to have a single app that accesses both an iOS- and a macOS-style app group. For example:
You have a macOS app.
You want to migrate to an iOS-style app group ID, perhaps because you want to share an app group container with a Mac Catalyst app.
But you also need to access existing content in a container identified by a macOS-style app group ID.
Historically this caused problems (FB16664827) but, as of Jun 2025, this is fully supported (r. 148552377).
When the Developer website generates a Mac provisioning profile for an App ID with the App Groups capability, it automatically adds TEAM_ID.* to the list of app group IDs authorised by that profile (where TEAM_ID is your Team ID). This allows the app to claim access to every iOS-style app group ID associated with the App ID and any macOS-style app group IDs for that team. This helps in two circumstances:
It avoids any Mac App Store Connect submission problems, because App Store Connect can see that the app’s profile authorises its use of all the it app group IDs it claims access to.
Outside of App Store — for example, when you directly distribute an app using Developer ID signing — you no longer have to rely on macOS granting implicit access to macOS-style app group IDs. Rather, such access is explicitly authorised by your profile. That ensures that your entitlements remain validated, as discussed in the Entitlements-Validated Flag, below.
A Historical Interlude
These different styles of app group IDs have historical roots:
On iOS, third-party apps have always used provisioning profiles, and thus the App Groups entitlement is restricted just like any other entitlement.
On macOS, support for app groups was introduced before macOS had general support for provisioning profiles [1], and thus the App Groups entitlement is unrestricted.
The unrestricted nature of this entitlement poses two problems. The first is accidental collisions. How do you prevent folks from accidentally using an app group ID that’s in use by some other developer?
On iOS this is easy: The Developer website assigns each app group ID to a specific team, which guarantees uniqueness. macOS achieved a similar result by using the Team ID as a prefix.
The second problem is malicious reuse. How do you prevent a Mac app from accessing the app group containers of some other team?
Again, this isn’t an issue on iOS because the App Groups entitlement is restricted. On macOS the solution was for the Mac App Store to prevent you from publishing an app that used an app group ID that’s used by another team.
However, this only works for Mac App Store apps. Directly distributed apps were free to access app group containers of any other app. That was considered acceptable back when the Mac App Store was first introduced. That’s no longer the case, which is why macOS 15 introduced app group container protection. See App Group Container Protection, below.
[1] I’m specifically talking about provisioning profiles for directly distributed apps, that is, apps using Developer ID signing.
Entitlements-Validated Flag
The fact that the App Groups entitlement is unrestricted on macOS is, when you think about it, a little odd. The purpose of entitlements is to gate access to functionality. If an entitlement isn’t restricted, it’s not much of a gate!
For most unrestricted entitlements that’s not a problem. Specifically, for both the App Sandbox and Hardened Runtime entitlements, those are things you opt in to, so macOS is happy to accept the entitlement at face value. After all, if you want to cheat you can just not opt in [1].
However, this isn’t the case for the App Groups entitlement, which actually gates access to functionality. Dealing with this requires macOS to walk a fine line between security and compatibility. Part of that solution is the entitlements-validated flag.
When a process runs an executable, macOS checks its entitlements. There are two categories:
Restricted entitlements must be authorised by a provisioning profile. If your process runs an executable that claims a restricted entitlement that’s not authorised by a profile, the system traps.
Unrestricted entitlements don’t have to be authorised by a provisioning profile; they can be used by any code at any time.
However, the App Groups entitlement is a special type of unrestricted entitlement called a validation-required entitlement. If a process runs an executable that claims a validation-required entitlement and that claim is not authorised by a profile, the system allows the process to continue running but clears its entitlements-validated flag.
Some subsystems gate functionality on the entitlements-validated flag. For example, the data protection keychain uses entitlements as part of its access control model, but refuses to honour those entitlements if the entitlement-validated flag has been cleared.
Note If you’re curious about this flag, use the procinfo subcommand of launchctl to view it. For example:
% sudo launchctl procinfo `pgrep Test20230126`
…
code signing info = valid
…
entitlements validated
…
If the flag has been cleared, this line will be missing from the code signing info section.
Historically this was a serious problem because it prevented you from creating an app that uses both app groups and the data protection keychain [2] (r. 104859788). Fortunately that’s no longer an issue because the Developer website now lets you include the App Groups entitlement in macOS provisioning profiles.
[1] From the perspective of macOS checking entitlements at runtime. There are other checks:
The App Sandbox is mandatory for Mac App Store apps, but that’s checked when you upload the app to App Store Connect.
Directly distributed apps must be notarised to pass Gatekeeper, and the notary service requires that all executables enable the hardened runtime.
[2] See TN3137 On Mac keychain APIs and implementations for more about the data protection keychain.
App Groups and the Keychain
The differences described above explain a historical oddity associated with keychain access. The Sharing access to keychain items among a collection of apps article says:
Application groups
When you collect related apps into an application group using
the App Groups entitlement, they share access to a
group container, and gain the ability to message each other in
certain ways. You can use app group names as keychain access
group names, without adding them to the Keychain Access Groups
entitlement.
On iOS this makes a lot of sense:
The App Groups entitlement is a restricted entitlement on iOS.
The Developer website assigns each iOS-style app group ID to a specific team, which guarantees uniqueness.
The required group. prefix means that these keychain access groups can’t collide with other keychain access groups, which all start with an App ID prefix (there’s also Apple-only keychain access groups that start with other prefixes, like apple).
However, this didn’t work on macOS [1] because the App Groups entitlement is unrestricted there. However, with the Feb 2025 changes it should now be possible to use an iOS-style app group ID as a keychain access group on macOS.
Note I say “should” because I’ve not actually tried it (-:
Keep in mind that standard keychain access groups are protected the same way on all platforms, using the restricted Keychain Access Groups entitlement (keychain-access-groups).
[1] Except for Mac Catalyst apps and iOS Apps on Mac.
Not Entirely Unsatisfied
When you launch a Mac app that uses app groups you might see this log entry:
type: error
time: 10:41:35.858009+0000
process: taskgated-helper
subsystem: com.apple.ManagedClient
category: ProvisioningProfiles
message: com.example.apple-samplecode.Test92322409: Unsatisfied entitlements: com.apple.security.application-groups
Note The exact format of that log entry, and the circumstances under which it’s generated, varies by platform. On macOS 13.0.1 I was able to generate it by running a sandboxed app that claims a macOS-style app group ID in the App Groups entitlement and also claims some other restricted entitlement.
This looks kinda worrying and can be the source of problems. It means that the App Groups entitlement claims an entitlement that’s not authorised by a provisioning profile. On iOS this would trap, but on macOS the system allows the process to continue running. It does, however, clear the entitlements-validate flag. See Entitlements-Validated Flag for an in-depth discussion of this.
The easiest way to avoid this problem is to authorise your app group ID claims with a provisioning profile. If there’s some reason you can’t do that, watch out for potential problems with:
The data protection keychain — See the discussion of that in the Entitlements-Validated Flag and App Groups and the Keychain sections, both above.
App group container protection — See App Group Container Protection, below.
App Group Container Protection
macOS 15 introduced app group container protection. To access an app group container without user intervention:
Claim access to the app group by listing its ID in the App Groups entitlement.
Locate the container by calling the containerURL(forSecurityApplicationGroupIdentifier:) method.
Ensure that at least one of the following criteria are met:
Your app is deployed via the Mac App Store (A).
Or via TestFlight when running on macOS 15.1 or later (B).
Or the app group ID starts with your app’s Team ID (C).
Or your app’s claim to the app group is authorised by a provisioning profile embedded in the app (D) [1].
If your app doesn’t follow these rules, the system prompts the user to approve its access to the container. If granted, that consent applies only for the duration of that app instance.
For more on this, see:
The System Integrity Protection section of the macOS Sequoia 15 Release Notes
The System Integrity Protection section of the macOS Sequoia 15.1 Release Notes
WWDC 2024 Session 10123 What’s new in privacy, starting at 12:23
The above criteria mean that you rarely run into the app group authorisation prompt. If you encounter a case where that happens, feel free to start a thread here on DevForums. See the top of this post for info on the topic and tags to use.
Note Prior to the Feb 2025 change, things generally worked out fine when you app was deployed but you might’ve run into problems during development. That’s no longer the case.
[1] This is what allows Mac Catalyst and iOS Apps on Mac to work.
Revision History
2025-08-12 Added a reference to the Register App Groups build setting.
2025-07-28 Updated the Crossing the Streams section for the Jun 2025 change. Made other minor editorial changes.
2025-04-16 Rewrote the document now that iOS-style app group IDs are fully supported on the Mac. Changed the title from App Groups: macOS vs iOS: Fight! to App Groups: macOS vs iOS: Working Towards Harmony
2025-02-25 Fixed the Xcode version number mentioned in yesterday’s update.
2025-02-24 Added a quick update about the iOS-style app group IDs on macOS issue.
2024-11-05 Further clarified app group container protection. Reworked some other sections to account for this new reality.
2024-10-29 Clarified the points in App Group Container Protection.
2024-10-23 Fleshed out the discussion of app group container protection on macOS 15.
2024-09-04 Added information about app group container protection on macOS 15.
2023-01-31 Renamed the Not Entirely Unsatisfactory section to Not Entirely Unsatisfied. Updated it to describe the real impact of that log message.
2022-12-12 First posted.