File access popups with shared containers on Sequoia

Question

Created 3w

Replies 4

Boosts 0

Participants 2

We have a sandboxed swift app with an associated network extension where both write to the same log file in a shared container (via NSFileCoordinator)

On sonoma all was good. With sequoia, we get a popup requesting access to the file from the user.

I realize this is all in the name of security, but is there any way to prevent this popup?

alf

Answered by alfred_eisenberg in 809863022

I did mention in first message it was sandboxed.

What screwed me up a bit was what I assume is an xcode 16 bug/feature. If you edit the entitlements in build settings after you alread put the right format in the entitlements file it jams the group. in there. Anyway, managed to get it working on mac and ios once I got the provisioning set and platform specific entitlement files

Boost

Answer 1

DTS Engineer OP

Apple

3w

We added app group container protection in macOS 15. See the link to the WWDC session in Trusted Execution Resources and this info in the macOS Sequoia 15 Release Notes. It’s most likely that your app and NE provider have an app group entitlement issue. What is your app group name?

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

0

Answer 2

alfred_eisenberg OP

3w

I was using group.com.company.appname but in the documentation I saw that on mac that we should use group.$TeamIdentifierPrefix)com.company.appname

Still get popups either way. Is that what you are asking for?

if the entitlments are wrong I'm wondering why they were able to share data in that container in Sonoma.

0

Answer 3

DTS Engineer OP

Apple

3w

if the entitlments are wrong I'm wondering why they were able to share data in that container in Sonoma.

Because app group container protection is a new security feature on macOS 15. Previous there was nothing to stop a (non-sandboxed) app from reading the files in any app group container.

I saw that on mac that we should use group.$TeamIdentifierPrefix)com.company.appname

No, you’ve misread that. On macOS it’s just $(TeamIdentifierPrefix)com.company.appname. If you maintained the group. prefix then it’s not surprising you’re seeing the same behaviour.

Overall, the situation with app groups is… well… complicated. I talk about this in detail in App Groups: macOS vs iOS: Fight!.

The best path forward depends on a bunch of factors:

Does you app ship on the Mac App Store? Or do you distribute it directly?
Does your app use Mac Catalyst?
Is your app sandboxed?
Is your NE provider packaged as an app extension or a system extension?

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

0

Answer 4

alfred_eisenberg OP

2w

Recommended

I did mention in first message it was sandboxed.

What screwed me up a bit was what I assume is an xcode 16 bug/feature. If you edit the entitlements in build settings after you alread put the right format in the entitlements file it jams the group. in there. Anyway, managed to get it working on mac and ios once I got the provisioning set and platform specific entitlement files

0