We've got an in-house Swift macOS desktop app with a FileProvider extension, which has been working fine on various machines up through Sonoma (and still does). We've just installed it on a Sequoia machine, and on it the FileProvider extension has lost the ability to access the shared app group. It can neither log to the Group Containers folder under ~/Library, nor access the pipe to the main app.
The group name is formatted as group.XXXXXXXXXX.com.orgname.appname in both targets. I'm not sure why it combines the iOS and macOS conventions, with both the group prefix and the teamIdentifier one -- it was first built some time before the point in 2025 when macOS supported iOS-style groups -- but again, it's been working.
For the record, The provisioning profile for EMPFileProvider has the App Groups capability enabled, and the App Groups capability is present in both build targets in Xcode. The existing group identifier is registered on the website; I've also manually registered the team-ID-less group name, so I can migrate.
The question is, is this actually the right approach? Will such a change break the app on pre-Sequoia machines? And if I proceed, what do I need to do to complete the migration? The app was built back in Xcode 12.5; will I need to update the entire build environment to take advantage of Xcode 16.3's explicit support for iOS-style group names, or can I get away with it since I've manually registered the new group?
The macOS 15 development cycle triggered a bunch of changes in app groups. See App Groups: macOS vs iOS: Working Towards Harmony for the backstory.
Going forward, I recommend that you:
- Decide on the app group ID you want to use. This can use either the macOS style or iOS style. For new code I recommend the iOS style, although if you have an exist product that uses the macOS style it usually makes sense to stick with that.
- For each program involved (so your app and your file provider appex)…
- Make sure it has an explicit App ID.
- Create a profile that authorises that App ID to access your app group.
- Make sure that profile gets embedded in the program’s bundle.
- Sign the program to claim access to that app group.
IMPORTANT Make sure to sign the program with com.apple.application-identifier so that the system can associated the program with its provisioning profile.
If you’re using Xcode, it will typically take care of this for you, although my experience is that this works better if you’re using an iOS style app group ID.
Will such a change break the app on pre-Sequoia machines?
I think this will back deploy just fine. Prior to macOS 15 the system doesn’t strictly [1] enforce app group ID claims [2] but, even if it did, the presence of a provisioning profile that authorises the claim should be sufficient.
But, as always, I recommend that you test on your each major macOS release that you support, just to be sure.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] I’m using “strictly” here because of the entitlement-validated flag, as explained in App Groups: macOS vs iOS: Working Towards Harmony.
[2] Although they were checked for apps submitted to the App Store [3].
[3] Sometimes |-: There’s a whole different backstory to that.