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?

If an application has registered Login Items that are running, what happens if the application bundle is replaced with a new version? Does any currently running processes of the login items get relaunched to use the new version? Are there any specific steps required to ensure the new version is used immediately?