Sequoia Group Container for Mac Catalyst Apps

Prior to Sequoia, Mac Catalyst Apps worked fine when using group folders that started with group. They now get an alert that the Mac Catalyst app is trying to access data from other applications. This may also impact some SwiftUI developers.

According to this the documentation for the App Group Entitlements entitlement, on macOS we should begin use the Team Identifier instead of group.

Should Mac Catalyst follow the macOS or iOS rules for com.apple.security.application-groups? If they should need to follow the macOS rules now, that creates several issues for developers. We would now need separate build targets to pick up the different Entitlements files. More distressing is that we would need to do some kind of migration process to get our files to the new location. There wouldn't be a transparent way to do so where the user wasn't warned about the application accessing files that don't belong to it.

Any clarification on what Mac Catalyst developers should be doing to prepare for Sequoia would be greatly appreciated.

Answered by DTS Engineer in 794749022

There is a bunch of stuff to unpack here. First up, I’m gonna assume that you’re familiar with the backstory in App Groups: macOS vs iOS: Fight!. If not, read it now.

In that I wrote:

In Mac Catalyst things behave as they do on iOS.

and I wasn’t kidding. A Mac Catalyst app should use iOS-style app group names (group.*), where those app group entitlement claims are authorised by its provisioning profile. Here’s an example of that:

% vtool -show-build Test758358.app/Contents/MacOS/Test758358
…
 platform MACCATALYST
…
% codesign -d --entitlements - Test758358.app               
…
	[Key] application-identifier
	[Value]
		[String] SKMME9E2Y8.com.example.apple-samplecode.Test758358
	[Key] com.apple.application-identifier
	[Value]
		[String] SKMME9E2Y8.com.example.apple-samplecode.Test758358
    …
	[Key] com.apple.security.application-groups
	[Value]
		[Array]
			[String] group.eskimo1.test
…
% security cms -D -i Test758358.app/Contents/embedded.provisionprofile | plutil -p -
{
  …
  "Entitlements" => {
    "application-identifier" => "SKMME9E2Y8.com.example.apple-samplecode.Test758358"
    "com.apple.application-identifier" => "SKMME9E2Y8.com.example.apple-samplecode.Test758358"
    …
    "com.apple.security.application-groups" => [
      0 => "group.eskimo1.test"
    ]
    …
  }
  …
}

As you can see, the group.eskimo1.test app group claim is authorised by the allowlist in the app’s provisioning profile.

Note Having both the application-identifier (iOS) and com.apple.application-identifier (macOS) entitlement is a tell-tale sign of a Mac Catalyst app. But if you want to confirm that, vtool is a great option.

Thus, Mac Catalyst apps meet the third criterion (“the app group identifier is authorised by a provisioning profile embedded within the app”). However, this isn’t working right now )-:

Based on bug reports from you and other developers, we investigated this and determined that there’s a bug in the app group authorisation check (r. 129667695).

As always, I can’t make any promises as to when this’ll be fixed, but I encourage you to monitor both Feedback Assistant and any future macOS 15 beta seeds.


Non-Catalyst apps should use Mac-style app group names (TTT.*, where TTT is the Team ID). That’ll avoid the container prompt because of the second criterion (“the app group identifier is prefixed with the app’s Team ID”)

Non-Catalyst apps deployed via the Mac App Store may also use an iOS-style app group name (group.*) as long as that group is registered to the app’s team. This is the first criterion mentioned in the release notes (“the app is deployed through Mac App Store”).


Finally, some thoughts on testing. First, when testing this stuff it’s best to create a new app. macOS 15 beta has some built-in compatibility exceptions and it’s easy to get confused if you run your tests using popular products [1].

Second, to do a full test you’ll need multiple teams. That’s tricky if you’re a member of just one team. A neat way to get around this is to use a different Apple ID as a Personal Team.

Third, I’ve found that VMs are super helpful when testing stuff like this, because I can easily reset the VM back to a clean state, one where it’s never seen any of my test apps.

Share and Enjoy

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

[1] Ask me how I know )-:

It would be great if there was a setting to turn off this check as a developer, maybe like the developer mode on iOS.

Sequoia Group Container for Mac Catalyst Apps
 
 
Q