The release notes state the following:
To protect users’ privacy, app group containers (in ~/Library/Group Containers) are now protected by System Integrity Protection. This is similar to the protection added to app data containers in macOS Sonoma. An app that’s properly entitled for an app group continues to have access to the app group container. Specifically, the app must use FileManager to get the app group container path and meet one of the following requirements: the app is deployed through Mac App Store; the app group identifier is prefixed with the app’s Team ID; or the app group identifier is authorised by a provisioning profile embedded within the app. If the app doesn’t meet these requirements, the system might present the user a prompt to authorize the app’s use of the app group container. If granted, that consent applies only for the duration of that app instance. This restriction also applies to app extensions, although in that case the system won’t prompt the user for consent but will instead just deny the access. (114586798)
We have a helper app which is not sandboxed (due to it requiring Accessibility access/permissions) that accesses our group container.
I've tested our helper app with the current beta of macOS Sequoia 15 (24A5264n) and it still works correctly, however I'm not clear if these restrictions are actually enforced in the current beta. I've tried testing for this by accessing the group container via Terminal (with Full Disk Access disabled for Terminal), but did not get any alert mentioned in the notes (or been otherwise restricted).
Are these restrictions currently enforced?
My assumption here is that:
-
Your main app and your helper app are signed by the same Team ID.
-
Your app group ID is prefixed by your Team ID.
If so, you’ve nothing to worry about here.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"