Problems with multi-platform apps using app groups on macOS 15

In fact, I can add an app group identifier that doesn't start with group. only if my app's destination is macOS only. Then, when I add iOS as a destination, Xcode shows me an error that says that app groups must begin with group., and the app won't build. This seems to be a serious bug with Xcode. There should be separate app group sections in the "Signing & Capabilities" panel for macOS and iOS to allow for these different conventions.

I've also noticed that the permission prompt is shown every time the app launches, even after the user has given their permission on the first launch.

I have the exact same issue with my app. It seems that Sequoia expects the app group to start with the team identifier. But it is not possible to create a group identifier specifically for macOS in multi-platform targets and iOS groups always need to start with group.

It is not even possible to create a separate target for macOS because XCode only allows one target per app identifier.

This is a serious issue because the first thing users see when they launch the app is a security warning that is incorrect. Either macOS should also accept iOS style group identifiers or XCode should allow setting different identifiers for each system. Yet, the first would be much better, because otherwise, we would need to migrate existing data to a new group folder, which again requires the user to agree to the security alert.

As a temporary workaround, it looks like you can add the app group ID prefixed with the team ID in your .entitlements file, and the macOS app will build and use the correct app group directory without asking the user for permission. Then, to allow your iOS app to build, you'll need to remove the macOS app group ID from that file. I haven't tried submitting to the App Store with this setup yet, but assuming it works, you'll need to remember to include the correct app group ID for each build you submit.

Since Apple is unlikely to change their access control policy for app group directories on macOS, the most sensible solution would be to create a separate app group section for macOS under "Signing & Capabilities" in Xcode, which allows you to specify the correct app group ID for macOS.

See also this post about the same issue: https://developer.apple.com/forums/thread/762639

As that post mentions, this problem could also be solved if the macOS provisioning profile included the app group identifier used in the iOS version.

I’ve been talking to other folks about the multiplatform app problem. See this thread for example.

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

I have found that the release notes of Sequoia actually state that any app group format should work, when the app is distributed through the app store or includes it in the provisioning profile (highlights by me):

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.

Also, I have discovered in the release notes of macOS 15.1 beta 4 sate that it fixes the following issue:

Fixed: Users might be incorrectly prompted when an app that is distributed through TestFlight attempts to access an application group container. (131606564) (FB14288230)

I understand, that the security alert should actually not be shown and is currently only shown for XCode and TestFlight builds. I can verify, that no such alert is shown when I run the App Store version of my app. I haven't tested the new 15.1 beta yet, however.

So this might actually not be a big issue after all. 😮‍💨

I understand, that the security alert should actually not be shown and is currently only shown for XCode and TestFlight builds. I can verify, that no such alert is shown when I run the App Store version of my app.

I just tested this myself and can confirm that it is the case. So I'll keep using the app group prefixed with group. in my macOS app, and hopefully this will be resolved for Xcode builds from macOS 15.1 on.