app groups user defaults are not returning values in macOS27 beta

App & System Services General
rbmanian75 OP
Created 2d
Replies 3
Boosts 0
Views 73
Participants 2

Hi, I have a app group registered in mac os app called gorup.com.company.app and i am saving the key/values in userdefaults to this with suitname. within the mac os app the group userdedaults write/read are working fine.

I have a switt cli app with same app group registered in the code signing entitilement for the swit cli app. trying to read the group user default key value registered in mac os app in swift cli app returning no value. this was working fine with macOS 26. Is there some changes have been made in macos 27 in regaard to this?

Answered by DTS Engineer in 894793022

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"

Replies  3
Boosts  0
Views  73
Participants  2
rbmanian75 OP
2d
Accepted Answer

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
rbmanian75 OP
2d

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

DTS Engineer OP
Apple
1h
Recommended

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"

app groups user defaults are not returning values in macOS27 beta
First post date Last post date
 
 
Q