App Groups on macOS, 'Register App Groups' Code Signing Problems

There’s a bunch of backstory to this issue in App Groups: macOS vs iOS: Working Towards Harmony.

This was a "macOS styled" group without the group. prefix. So am I supposed to switch it to have the group. prefix?

In the long term, and in an ideal world, the answer to this is “Yes.” However, there are complications.

What are you using the app group for? Specifically, do you use the app group to access on app group container? And have you store irreplaceable user data in that container?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

In this app I have shared preferences for the main app, an Action Extension, a Helper app, and an XPC service.

I do have another app that has an XPC service that writes files inside the group container. When the XPC service is done the main app accesses the files.

From App Groups: macOS vs iOS: Working Towards Harmony.

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.

I'm sure there is a reason but I wonder why existing group container ids can't be registered and why making a new group with a "group." prefix is required.

So I just read this.

>Even outside of the Mac App Store, the presence of the macOS-style app group ID causes problems.

It is possible to work around this limitation, but it requires ‘heroic’ measures. The trick is to split your code into a main app and a helper, with the main app only claiming the iOS-style app group ID and the helper only claiming the macOS-style one. Your main app can then call on the helper to do the necessary work, for example, to access the app group container for the macOS-style app group ID.

This helper can be an XPC service or an embedded helper tool.

Overall, this isn’t a lot of fun [1], and if you’re in this situation you might want to wait for a fix to FB16664827.

[1] Unless, like me, you revel in implementing wacky workarounds (-:

I have an outside the MAS app that claims both style containers. I only added the group. prefix because I just updated to Xcode 16.3 and it nagged me to. What kind of issues can I run into here? I'm not actually writing to the new "group." container prefix yet but I did claim it..

I'm about to push the outside the Mac App Store app out..(already notarized...seems to be working fine) should I not go forward with it and take away the "group." from all targets?

I also have a Mac App Store app that uses the 'Mac style' group I'm going to update. I'm looking for advice on how I should proceed. Xcode nudged me to toggle "Register app groups" and now I have the old identifier listed in "app groups" for all target and it is in red text.

So if I hit the + and make a new identifier with the group. prefix, am I supposed to duplicate the old preferences to new container?

 NSUserDefaults *oldGroupPrefs = [[NSUserDefaults alloc]initWithSuiteName:@"oldcontainerid"];
 NSUserDefaults *newGroupPrefs = [[NSUserDefaults alloc]initWithSuiteName:@"newcontainerid"];
// save the values from oldGroupPrefs to new?

Documentation states:

Format the identifier as follows:

group.<group name>

Apple ensures that the group name you choose is unique when you register the app group on the Apple Developer website. For more information, see Register an app group. In macOS, you can also create app groups or add apps to existing app groups using this identifier format:

<team identifier>.<group name> You don’t need to register app groups that use this format on the Apple Developer website.

So I'm confused. Docs state using the old format is okay..

In the App Groups working towards harmony post:

Without that, you can’t submit an app that claims both styles of app group ID to the Mac App Store. [...]

It is possible to work around this limitation, but it requires ‘heroic’ measures. The trick is to split your code into a main app and a helper, with the main app only claiming the iOS-style app group ID and the helper only claiming the macOS-style one. Your main app can then call on the helper to do the necessary work, for example, to access the app group container for the macOS-style app group ID.

I don't want to do this. I don't have a Catalyst app and I only need one group to write shared preferences in. So I don't really need to do this....unless it is going to be enforced policy. Migrating data from a container is annoying enough but having to migrate from a helper tool seems kind of insane.

It’s hard to reply to three different emails, so let me summarise…

It’s fine to continue to use a macOS-style app group.

It’s also fine to use an iOS-style app group.

Having both styles of app groups is a pain point currently, and I’d advise against doing that unless you already have a shipping product that uses both and you can’t easily migrate it to one or the other.

That previous point is an important factor in whether you should migrate:

• If you store critical user data in an app group container, the obvious way to migrate that is to claim both app groups. However, that’s problematic right now, so if you’re in that situation it might make sense to defer your migration.

• OTOH, if you’re using the app group for other reasons — for non-critical data, or just for IPC — then there’s no real downside to the migration.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"