app groups user defaults are not returning values in macOS27 beta

To answer my question, according to https://developer.apple.com/documentation/Xcode/configuring-app-groups

You can also create macOS app groups using the naming convention <Developer team ID>.<group name>. By using this naming scheme, macOS checks that the code signature of processes that try to access the app group container contains the same Developer-Team-ID as app group container ID.

so i need to register the group id something like this <teamid>.group.com.company.app and it worked in macOS 27. apple hase closed the loop of using ios style app group for mac os app that was working with macOS 26

the fix causes problems with widgets i am using. when i use the teamid.group.com.company.app appgroup in the widget it is not getting values from main mac os app it seems to be that widget needs group.com.company.app appgroup then it works in macOS 27.

where as for for swift cli app it needs to teamid.group.com.company.app.

but when i try to create the appgroup prefixed with teamid it is not allowed by xcode or identifiers in apple develope site.

it is very confusing. what is the appgroup we need to use for sharing between mac os app and swift cli app and widget.

the apple documentation says for mac os app use teamid prefix but we cant create appgroup with teamid prefix. could some one from dts support clarify this. Thanks

I’m surprised this worked on macOS 26.

To understand what’s going on here you need to read App Groups: macOS vs iOS: Working Towards Harmony. It explains the two app group ID styles on macOS: The original Mac-style one (TEAM_ID.x.w.z) and the iOS-style one (group.x.y.z). It also explains the entitlements-validated flag, which is critical to understand this behaviour.

You can use either app group ID to access an app group container and as a user defaults suite ID. However, if you’re writing new code then my advice is that you use iOS-style app group IDs. That’s the long-term future direction.

Doing this from a command-line tool is tricky, because:

1. Your claim to that app group is based on entitlements.
2. Those entitlements must be authorised by a provisioning profile.
3. An command-line tool doesn’t have a bundle, and thus there’s no place to store that profile (r. 125850707).

The way out of this conundrum is to put the command-line tool in an app-like wrapper. Signing a daemon with a restricted entitlement explains this process, albeit in a very different context.

If you then want to make it easier for the user to run the tool, install a symlink to the executable within that bundle structure.

Keep in mind that the system needs your command-line tool to have an App ID, and by signed with the App ID entitlement, in order for it to associate your tool with its profile. Without that, depending on your exact setup, the system may allow your tool to run but it’ll run without the entitlements-validated flag, which will be very confusing.

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

Thanks for the replay. it explains everything. this is how i solved for the wdiget and mac os app i used gorup.x.y.z and for swift cli and mac os app i used teamid.x.y.z and code signed the swift cli witht the entitlements and it worked for sharing keys in both macOS 26 and macOS 27. since this is ia not a new app i have to stay with team.x.y.z approach which solves my problem. but what is the right thing to do?

The way out of this conundrum is to put the command-line tool in an app-like wrapper. Signing a daemon with a restricted entitlement explains this process, albeit in a very different context.

I need to do this is it not? If in understnad it correctly.

I need to do this is it not?

It’s complicated )-: Depending on exactly which entitlements you claim, running without a profile might end up with the entitlements-validated flag being cleared. And that may or may not matter depending on which subsystem is checking for entitlements. So my advice is that, yeah, you should ship your command-line tool in an app-like wrapper with a profile that authorises all of your restricted entitlements. However, if things are working right now then you can treat that as a medium-term goal rather than something you have to do immediately.

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

Thanks for the detail i will stick with what it is current and i will have it my roadmap to add a applike wrapper.