kTCCServiceSystemPolicyAppData warning from Transparency Consent and Control (TCC)

The problem is described in full with log output in #16844

We are having an issue with TCC prompting users for access to the app group container despite signing with entitlements following all guidelines.

This is a regression from the Feb 2025 Changes discussed in App Groups: macOS vs iOS: Working Towards Harmony

The problem can only be reproduced with Xcode 16.0 and later.

The entitlements for the app include access for the group container with

[Key] com.apple.security.application-groups
	[Value]
		[Array]
			[String] G69SCX94XU.duck

The documentation notes the group name can be arbitrary, e.g. <team identifier>.<group name>. Cyberduck uses G69SCX94XU.duck by default. Interestingly enough the alert is not shown when a group name matching the bundle identifier is used, e.g. G69SCX94XU.ch.sudo.cyberduck.

Answered by DTS Engineer in 859880022

Interesting. That setup shouldn’t trigger a TCC alert.

Do you see the problem if your run the app on a fresh system? That is, one that’s never seen your app before? App group containers do record the identity if the code that created them, and that can sometimes confuse things, so it’s best to verify the result on a fresh Mac.

I generally use a VM for this, restoring it to a fresh snapshot between tests. However, you can also do this by creating a new user account on your main Mac. And once you get into the swing of things, you can simple delete the container from ~/Library/Group Containers.

Share and Enjoy

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

What does this report:

% security cms -D -i "Cyberduck Nightly.app/Contents/embedded.provisionprofile" | plutil -p -

I would expect to see the profile authorise your claim to com.apple.security.application-groups > G69SCX94XU.duck.

Share and Enjoy

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

The issue is reproduced with a provisioning profile embedded. The output of security cms -D -i is

{
  "AppIDName" => "Cyberduck"
  "ApplicationIdentifierPrefix" => [
    0 => "G69SCX94XU"
  ]
  "CreationDate" => 2025-02-03 20:45:33 +0000
  "DER-Encoded-Profile" => {length = 3546, bytes = 0x30820dd6 06092a86 4886f70d 010702a0 ... 8f791dc8 806888ea }
  "DeveloperCertificates" => [
    0 => {length = 1448, bytes = 0x308205a4 3082048c a0030201 02020854 ... bd543e5c c872b843 }
  ]
  "Entitlements" => {
    "com.apple.application-identifier" => "G69SCX94XU.ch.sudo.cyberduck"
    "com.apple.developer.icloud-container-identifiers" => [
    ]
    "com.apple.developer.icloud-services" => "*"
    "com.apple.developer.team-identifier" => "G69SCX94XU"
    "com.apple.developer.ubiquity-container-identifiers" => [
    ]
    "com.apple.developer.ubiquity-kvstore-identifier" => "G69SCX94XU.*"
    "keychain-access-groups" => [
      0 => "G69SCX94XU.*"
    ]
  }
  "ExpirationDate" => 2043-01-30 20:45:33 +0000
  "IsXcodeManaged" => 0
  "Name" => "Cyberduck Distribution Provisioning Profile"
  "Platform" => [
    0 => "OSX"
  ]
  "ProvisionsAllDevices" => 1
  "TeamIdentifier" => [
    0 => "G69SCX94XU"
  ]
  "TeamName" => "David Kocher"
  "TimeToLive" => 6570
  "UUID" => "27de22e9-7fce-4a84-928a-1260d2a4a1e2"
  "Version" => 1
}

I cannot find the com.apple.security.application-groups in Entitlements.

There is no such thing as to customize the app group when creating a provisioning profile in developer center for macOS.

The issue is reproduced with a provisioning profile embedded that has the com.apple.security.application-groups set

{
  "AppIDName" => "Cyberduck"
  "ApplicationIdentifierPrefix" => [
    0 => "G69SCX94XU"
  ]
  "CreationDate" => 2025-09-23 07:54:54 +0000
  "DER-Encoded-Profile" => {length = 3604, bytes = 0x30820e10 06092a86 4886f70d 010702a0 ... 7013d550 78b027d9 }
  "DeveloperCertificates" => [
    0 => {length = 1448, bytes = 0x308205a4 3082048c a0030201 02020854 ... bd543e5c c872b843 }
  ]
  "Entitlements" => {
    "com.apple.application-identifier" => "G69SCX94XU.ch.sudo.cyberduck"
    "com.apple.developer.icloud-container-identifiers" => [
    ]
    "com.apple.developer.icloud-services" => "*"
    "com.apple.developer.team-identifier" => "G69SCX94XU"
    "com.apple.developer.ubiquity-container-identifiers" => [
    ]
    "com.apple.developer.ubiquity-kvstore-identifier" => "G69SCX94XU.*"
    "com.apple.security.application-groups" => [
      0 => "G69SCX94XU.*"
    ]
    "keychain-access-groups" => [
      0 => "G69SCX94XU.*"
    ]
  }
  "ExpirationDate" => 2043-09-19 07:54:54 +0000
  "IsXcodeManaged" => 0
  "Name" => "Cyberduck Distribution Provisioning Profile"
  "Platform" => [
    0 => "OSX"
  ]
  "ProvisionsAllDevices" => 1
  "TeamIdentifier" => [
    0 => "G69SCX94XU"
  ]
  "TeamName" => "David Kocher"
  "TimeToLive" => 6570
  "UUID" => "6ac7645d-fbd4-427a-8cb9-b8f53edae62d"
  "Version" => 1
}
Accepted Answer

Interesting. That setup shouldn’t trigger a TCC alert.

Do you see the problem if your run the app on a fresh system? That is, one that’s never seen your app before? App group containers do record the identity if the code that created them, and that can sometimes confuse things, so it’s best to verify the result on a fresh Mac.

I generally use a VM for this, restoring it to a fresh snapshot between tests. However, you can also do this by creating a new user account on your main Mac. And once you get into the swing of things, you can simple delete the container from ~/Library/Group Containers.

Share and Enjoy

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

I can confirm this is not reproduced in a virtual machine running 15.6_24G84 (btw cannot find 15.7 (24G222) for download). As previously written to DTS this was not reproduced in 26.0_25A5327h either and the reason was this was also tested in a clean virtual machine.

On the installation this is reproduced running 15.7 (24G222) the folder in ~/Library/Group Containers has indeed a .com.apple.containermanagerd.metadata.plist file with faulty, cached MCMMetadataIdentifier key referencing a different team identifier that was used for testing at some point.

Yeah, that’s always tricky.

The next step is to configure your VM to run the previous released version of your app and then run the new distribution-signed version. Hopefully that’ll work, in which case your real users won’t have problems, and we can write this off as a development-only occurrence.

Share and Enjoy

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

kTCCServiceSystemPolicyAppData warning from Transparency Consent and Control (TCC)
 
 
Q