Invalid code signing entitlements with app group on macOS

I'm getting this error when uploading a build of my macOS app to App Store Connect. It has always worked before, and nothing changed about my use of app groups, and the iOS build uploaded without any problems. Cleaning the build folder and derived data folder doesn't help. I'm using automatically managed signing in Xcode.

Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “[group.<rest of app group ID>]” value for the com.apple.security.application-groups key in “<bundle identifier>.pkg/Payload/<app name>.app/Contents/MacOS/<app name>” isn’t supported. This value should be a string or an array of strings, where each string is the “group” value or your Team ID, followed by a dot (“.”), followed by the group name. If you're using the “group” prefix, verify that the provisioning profile used to sign the app contains the com.apple.security.application-groups entitlement and its associated value(s).

Answered by DTS Engineer in 826363022
It mysteriously got resolved

App groups are more complicated than you might think. I have a bunch of backstory to this in App Groups: macOS vs iOS: Fight!.

Note that the story has changed in the last few days. I suspect that the action you took here caused Xcode to rebuild your distribution profile, resulting in a new profile that includes your app group in its allowlist.

The good news here is that, now that we fully support iOS-style app groups on macOS, we’ll see a lot fewer problems like this.

Share and Enjoy

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

I solved this issue by recreating the Certificates and Profiles on the Apple Developer website

I solved this issue by recreating the Certificates and Profiles on the Apple Developer website

Hi, thanks for sharing your solution. Could you please list all the steps you took to recreate the certificates and profiles on the Apple Developer website? I suspect I might be missing something in my process.

Also, did you upload the archive using those newly created certificates, or did you switch back to using automatic ones afterward? Did you have to remove any existing certificates to get it to work?

Thanks a lot for your help!

I also have been blocked by a sudden failure to upload macOS archives to App Store Connect the past few days, but finally managed to fix it by forcing XCode 16.3 beta to regenerate the provisioning profile(s) of the offending app extensions that uses the App Groups capability. I deliberately include all the steps I took to provide as much detail as possible for anyone else facing the same issue.

The exact error I got is as follows (redacted for privacy reasons):

ITMS-90286: Invalid code signing entitlements - Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “[group.com.xxx]” value for the com.apple.security.application-groups key in “com.xxx.appname.pkg/Payload/appname.app/Contents/PlugIns/AppNameExtension.appex/Contents/MacOS/AppNameExtension” isn’t supported. This value should be a string or an array of strings, where each string is the “group” value or your Team ID, followed by a dot (“.”), followed by the group name. If you're using the “group” prefix, verify that the provisioning profile used to sign the app contains the com.apple.security.application-groups entitlement and its associated value(s).

The XCode managed provisioning profiles can be found in "~/Library/Developer/Xcode/UserData/Provisioning Profiles". Upon inspecting the .provisionprofile for AppNameExtension, I found that there was no value set for the key "com.apple.security.application-groups".

Following the suggestions here, I installed XCode 16.3 beta (16E5104o) as I'd rather not deal with managing profiles & certificates. To force XCode to regenerate provisioning profiles, simply delete/move the files found at the path I mentioned above.

However, validating an archive failed with the same error even after regenerating all profiles! Upon examining the new provisioning profile for AppNameExtension, I realised that here was still no value set for the key "com.apple.security.application-groups".

This was puzzling, and I reluctantly went to the Apple Developer website and tried to generate a profile manually for AppNameExtension. This required me to generate a certificate signing request (CSR) with Keychain Access on my Mac. After doing all this, I downloaded the generated profile and inspected it. Again, there was no value set for the key "com.apple.security.application-groups"!

I was at a lost for what to do, but I gave XCode 16.3 beta another chance and tried regenerating the profiles again. This time, I played around with the App Groups capability under the Signings & Capabilities tab. I deleted the capability, then forced a regeneration by deleting the profile. Of course, there would be no value set for the key "com.apple.security.application-groups", since I disabled App Groups. Then, I added back the capability, selected my app group, and re-generated the profile once more. At last, there was a value set for the key "com.apple.security.application-groups"! And it corresponded to my app group: "group.com.xxx".

After this, I tried validating the same archive and it was successful, and I proceed to upload the archive to App Store Connect, which also succeeded of course.

I hope this long story helps someone solve this, as it was an extremely frustrating experience for me to do such a simple thing as releasing a patch update for my macOS app.

Could you please list all the steps you took to recreate the certificates and profiles on the Apple Developer website?

This is how I did it:

Add correct app group capability

  • Go to https://developer.apple.com/account/resources/identifiers/list and open the identifier belonging to your app/extension (you have to do follow all of these steps for every target included in your app)
  • Enable the 'App Groups' capability, click 'Configure', and enable the app group that you need. Then save.

Generate provisioning profile

  • Go to https://developer.apple.com/account/resources/profiles/list, click the plus button next to the Profiles title
  • Select 'macOS App Development', then continue
  • Select the correct App ID, then continue
  • Select the development certificate that you use in Xcode, then continue
  • Select your device, then continue
  • Give the profile a name, then click 'Generate'
  • Download the certificate

Select provisioning profile in Xcode

  • Go to the 'Signing & Capabilities' tab of the target settings
  • Disable 'Automatically manage signing'
  • In the macOS section of Signing, select the dropdown next to Provisioning Profile, select 'Import Profile', and select the profile you just downloaded

[quote='826809022, Moleskyth, /thread/775022?answerId=826809022#826809022, /profile/Moleskyth']

did you upload the archive using those newly created certificates, or did you switch back to using automatic ones afterward? Did you have to remove any existing certificates to get it to work?

did you upload the archive using those newly created certificates, or did you switch back to using automatic ones afterward? Did you have to remove any existing certificates to get it to work?

One of my goals for today was to explore how Xcode 16.2 handles the app group changes we recently introduced. So I sat down and ran some tests.

As a first step, I created a new app that does need a provisioning profile but doesn’t use an app group. The goal here is to cause Xcode to create and stash the development and distribution profiles for that app. Here’s what I did:

  1. Using Xcode 16.2 on macOS 15.3.1, I created a new app from the macOS > App template. I gave it a new, unique bundle ID, com.example.apple-samplecode.Test775022D, to make sure I’m starting from scratch.

    Note Note the D suffix. It took me 4 tries to get this right (-:

  2. In the Signing & Capabilities editor, I set the Team popup and confirmed that automatic signing was enabled.

  3. I added the iCloud capability. This forces Xcode to allocate an App ID and generate a profile for that App ID. Without that, Xcode uses my wildcard App ID, which just confuses things.

  4. I left the iCloud setup blank. I don’t need this app to use iCloud.

  5. I chose Product > Build.

  6. In Terminal, I dumped the signing state of the app:

    % codesign -d --entitlements - Test775022D.app 
    …
    [Dict]
        [Key] com.apple.application-identifier
        [Value]
            [String] SKMME9E2Y8.com.example.apple-samplecode.Test775022D
        …
    % security cms -D -i Test775022D.app/Contents/embedded.provisionprofile | plutil -p -
    {
      …
      "Entitlements" => {
        "com.apple.application-identifier" => "SKMME9E2Y8.com.example.apple-samplecode.Test775022D"
        "com.apple.developer.icloud-container-development-container-identifiers" => [
        ]
        "com.apple.developer.icloud-container-identifiers" => [
        ]
        "com.apple.developer.icloud-services" => "*"
        "com.apple.developer.team-identifier" => "SKMME9E2Y8"
        "com.apple.developer.ubiquity-container-identifiers" => [
        ]
        "com.apple.developer.ubiquity-kvstore-identifier" => "SKMME9E2Y8.*"
        "keychain-access-groups" => [
          0 => "SKMME9E2Y8.*"
        ]
      }
      …
    }
    

    This is pretty much what you’d expect.

  7. Back in Xcode, I chose Product > Archive.

  8. In the organiser, I selected the archive, clicked Distribute App, and followed the Custom > App Store Connect > Export workflow. In that workflow, I again chose to use automatic signing.

    That resulted in an installer package, confirming that the basics are set up correctly.


My next step was to add an app group to the app. Here’s what I did:

  1. On the Development website, I confirmed that the target app group ID, group.eskimo1.test, was allocated to my team.

    IMPORTANT If that’s not the case for you, sort that out before continuing.

  2. In Xcode, in Signing & Capabilities, I added the App Groups capability.

  3. Under the group list I clicked the add (+) button and entered the app group from step 1. This requires some care because Xcode really wants to apply the $(TeamIdentifierPrefix) prefix.

    Note This is where things go wrong with Xcode 16.2. If you were working on an iOS app, Xcode would present you with a list of your app group IDs and enabling one would add it to your App ID and then force a provisioning profile rebuild. Xcode 16.2 doesn’t do that for Mac apps; Xcode 16.3 beta is smarter.

  4. I chose Product > Build.

  5. And dumped the signing state of the app:

    % codesign -d --entitlements - Test775022D.app
    …
    [Dict]
        [Key] com.apple.application-identifier
        [Value]
            [String] SKMME9E2Y8.com.example.apple-samplecode.Test775022D
        …
        [Key] com.apple.security.application-groups
        [Value]
            [Array]
                [String] group.eskimo1.test
        …
    % security cms -D -i Test775022D.app/Contents/embedded.provisionprofile | plutil -p -
    {
      …
      "Entitlements" => {
        … as above …
      }
      …
    }
    

    Here you see the problem. The app is claiming the group.eskimo1.test but that claim is not authorised by the allowlist in its provisioning profile.

  6. I chose Product > Archive.

  7. I exported the app from the organiser.

  8. I unpacked the resulting installer package (.pkg). I used Pacifist for this, but you can do it manually. See Unpacking Apple Archives.

  9. I dumped the signing state of this app. It looks just like the development version, which is bad. With the recent changes, App Store Connect will chuck a wobbly if I try to submit this app.


Finally, I set about fixing this. The first step is was to add the app group to the App ID:

  1. On the Developer website, I found my app ID and viewed it.

  2. I enabled the App Groups capability.

  3. I clicked the Configure button next to it.

  4. In the app groups editor, I selected my test app group and clicked Continue.

  5. Back in the main editor, I clicked Save.

Now it’s time to give Xcode the memo:

  1. In Signing & Capabilities, I added the Custom Network Protocol capability to my app.

    Note The goal of doing this is to get Xcode to rebuild the app’s provisioning profile. There are lots of other ways to do that. Indeed, I’ll explain another one below. I like this approach because it’s easy and absolutely definitive.

  2. I chose Product > Build.

  3. And dumped the signing state of the app:

    % codesign -d --entitlements - Test775022D.app
    …
    [Dict]
        [Key] com.apple.application-identifier
        [Value]
            [String] SKMME9E2Y8.com.example.apple-samplecode.Test775022D
        …
        [Key] com.apple.developer.networking.custom-protocol
        [Value]
            [Bool] true
        …
        [Key] com.apple.security.application-groups
        [Value]
            [Array]
                [String] group.eskimo1.test
        …
    % security cms -D -i Test775022D.app/Contents/embedded.provisionprofile | plutil -p -
    {
      …
      "Entitlements" => {
        "com.apple.application-identifier" => "SKMME9E2Y8.com.example.apple-samplecode.Test775022D"
        …
        "com.apple.developer.networking.custom-protocol" => 1
        …
        "com.apple.security.application-groups" => [
          0 => "group.eskimo1.test"
        ]
        …
      }
      …
    }
    
  4. Now we’re cooking with gas! Adding the new capability forced Xcode to rebuild the profile, and that new profile’s allowlist includes the app group ID that I added to my App ID.

  5. Back in Signing & Capabilities, I removed the Custom Network Protocol capability; we don’t want to ship with that (-:


With the development build sorted out, it was time to return to the distribution build:

  1. I chose Product > Archive.

  2. I exported the new archive from the organiser.

  3. I unpacked the installer package and dumped the signing state of the latest app:

    % codesign -d --entitlements - Test775022D.app
    …
    [Dict]
        [Key] com.apple.application-identifier
        [Value]
            [String] SKMME9E2Y8.com.example.apple-samplecode.Test775022D
        …
        [Key] com.apple.security.application-groups
        [Value]
            [Array]
                [String] group.eskimo1.test
        …
    % security cms -D -i Test775022D.app/Contents/embedded.provisionprofile | plutil -p -
    {
      …
      "Entitlements" => {
        "com.apple.application-identifier" => "SKMME9E2Y8.com.example.apple-samplecode.Test775022D"
        "com.apple.developer.icloud-container-development-container-identifiers" => [
        ]
        "com.apple.developer.icloud-container-identifiers" => [
        ]
        "com.apple.developer.icloud-services" => "*"
        "com.apple.developer.team-identifier" => "SKMME9E2Y8"
        "com.apple.developer.ubiquity-container-identifiers" => [
        ]
        "com.apple.developer.ubiquity-kvstore-identifier" => "SKMME9E2Y8.*"
        "keychain-access-groups" => [
          0 => "SKMME9E2Y8.*"
        ]
      }
      …
      "UUID" => "51779317-654f-4c0b-a6c1-52de5ca4dab9"
      …
    }
    

    So, I’ve fixed my day-to-day signing but there’s still a problem with signing for release.

  4. I noted down the UUID of the profile in question.

  5. I quit Xcode.

  6. In the Finder, I navigated to ~/Library/Developer/Xcode/UserData/Provisioning Profiles.

  7. I deleted the profile with the UUID I noted down in step 4.

  8. I relaunched Xcode.

  9. Back it the organiser, I went through the export process again.

  10. And then unpacked the installer package and dumped the latest signing state:

    % codesign -d --entitlements - Test775022D.app
    …
    [Dict]
        [Key] com.apple.application-identifier
        [Value]
            [String] SKMME9E2Y8.com.example.apple-samplecode.Test775022D
        …
        [Key] com.apple.security.application-groups
        [Value]
            [Array]
                [String] group.eskimo1.test
        …
    % security cms -D -i Test775022D.app/Contents/embedded.provisionprofile | plutil -p -
    {
      …
      "Entitlements" => {
        "com.apple.application-identifier" => "SKMME9E2Y8.com.example.apple-samplecode.Test775022D"
        "com.apple.developer.icloud-container-development-container-identifiers" => [
        ]
        "com.apple.developer.icloud-container-identifiers" => [
        ]
        "com.apple.developer.icloud-services" => "*"
        "com.apple.developer.networking.custom-protocol" => 1
        "com.apple.developer.team-identifier" => "SKMME9E2Y8"
        "com.apple.developer.ubiquity-container-identifiers" => [
        ]
        "com.apple.developer.ubiquity-kvstore-identifier" => "SKMME9E2Y8.*"
        "com.apple.security.application-groups" => [
          0 => "group.eskimo1.test"
        ]
        "keychain-access-groups" => [
          0 => "SKMME9E2Y8.*"
        ]
      }
      …
      "UUID" => "e555bc01-0390-4f1b-923d-65bd18e28422"
      …
    }
    

    Now things are working. This is a new profile (note the new UUID) and it includes my app group in its allowlist. App Store Connect should be happy to accept it.

*phew*

Share and Enjoy

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

@DTS Engineer

Thank you for the detailed instructions.

I followed each step carefully and achieved the "same" results as outlined in your guide (with different identifiers, of course). Specifically, I generated a new provision profile UUID and group identifiers starting with “group.” And in the provision profile file with the new UUID, there is key "com.apple.security.application-groups" with same value as set in Xcode. However, after uploading the archive to the App Store via Xcode Organizer, I am still encountering the same error as before.

... This value should be a string or an array of strings, where each string is the “group” value or your Team ID, followed by a dot (“.”), followed by the group name. If you're using the “group” prefix, verify that the provisioning profile used to sign the app contains the com.apple.security.application-groups entitlement and its associated value(s). ...

Additionally, when testing the widget using WidgetKit Simulator on macOS, I receive error message continually when show the timeline.

The operation couldn't be completed. (CHSErrorDomain error 1103.)

Could you kindly advise on a solution for this as well?

I’ve learnt a new trick so I wanted to expand on the steps I posted yesterday. I started off by running the steps up to “My next step was to add an app group to the app” point. From there I did this:

  1. On the Development website, I confirmed that the target app group ID, group.eskimo1.test, was allocated to my team.

  2. In Xcode, I navigated to the build settings for my app target.

  3. I clicked the add (+) button and added a custom build setting of REGISTER_APP_GROUPS with a value of YES. This enables the iOS-style app groups UI on Xcode 16.2.

  4. I navigated to Signing & Capabilities and added the App Groups capability.

  5. Under the group list I clicked the add (+) button. This presents the iOS-style UI.

  6. In that UI, I entered my group, group.eskimo1.test, and click OK. Xcode’s automatic code signing machinery kicked in and updated my profile. No muss, no fuss!

  7. I chose Product > Build.

  8. I dumped the signing state of the development app:

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

    Xcode has done the right thing. Yay!

I then continued on the process from my previous post (step 7, choosing Product > Archive). Things didn’t work out of the box; Xcode continued to use its cached provisioning profile. However, the same steps from my previous post — using the UUID to fix and nix the profile in ~/Library/Developer/Xcode/UserData/Provisioning Profiles — resolved the issue.

Share and Enjoy

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

So I:

  • Added the REGISTER_APP_GROUPS custom build setting to all my macOS targets.
  • Removed and re-added the App Groups capability using the iOS group format (it was already in this format, but I did it anyway)
  • Verified that the entitlement in the built product is correct.
  • Deleted the profile with the UUID found in the built product, following the same steps used by Quinn to fix the distribution build.
  • Selected Product > Build

But I stil get the same error when submitting to App Store Connect. I also tried disabling automatic signing and using a manually generated profile from the Developer website, but the error continues.

Is there anything else I need to do to be able to submitting it to App Store Connect?

I resolved this issue by following these steps (with Automatically manage signing enabled):

  1. Close Xcode and delete all files in ~/Library/Developer/Xcode/UserData/Provisioning Profiles.

  2. On the Apple Developer website, go to Identifiers and locate the identifier mentioned in the error message.

  3. Click on the identifier, find the App Groups section, and click the Edit button. In the pop-up window, check the corresponding app group name.

  4. Rebuild the project in Xcode.

Thank you so much for your help—you literally saved my day! I really appreciate you taking the time to share your solution.

@DTS Engineer Still no luck for me. I have an unusual arrangement: my app is a Mac Catalyst app that embeds a non-Catalyst Mac app as a LoginItem.

All my Mac targets (Catalyst and non-Catalyst) have REGISTER_APP_GROUPS = YES and all have the App Group entitlement. When I inspect the archived build as you suggest, every provisioning profile appears to have application-groups set correctly. But I still get the same error from ASC.

I filed a Feedback and attached an archive build, if you or the ASC team could please take a look: FB16664827

my app is a Mac Catalyst app that embeds a non-Catalyst Mac app as a LoginItem.

Ah, that’s fun. And you’re not the only person to play such games [1].

I filed a Feedback … FB16664827

Thanks. That’s definitely the right path forward in your case.

Share and Enjoy

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

[1] Indeed, I’ve done this myself to work around a keychain issue in the Personal VPN support within Network Extension framework.

Still not resolved

Success! I finally noticed a difference between the instructions in the latest Xcode beta release notes and Quinn's instructions:

… remove related profiles from ~/Library/Developer/Xcode/UserData/Provisioning Profiles and ~/Library/MobileDevice/Provisioning Profiles

I had cleaned out that first directory but not the second. Deleting the relevant profiles in both directories seems to have fixed everything.

Thanks for sharing your update. I’m glad to hear that you got past this roadblock.


Speaking more generally, I’ve been working in private with a number of developers who’ve hit issues like this. I’m still researching various edge cases but, as far as I can tell right now, there doesn’t seem to be an App Store Connect problem here. That is, ASC is accepting what it should be accepting. Rather, there’s a caching problem causing Xcode to submit the wrong thing. And hence the workaround in the Xcode release notes.

So, for other folks hitting this problem, please try that workaround and let us know how you get along.

Share and Enjoy

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

After the launch of macOS 15, I migrated my app group from [group.mydomain] to [TeamID.mydomain].

Now, I need my app to support both app group identifiers simultaneously.

However, none of the methods in this thread so far have been effective. So frustrated.

I’m still researching various edge cases but, as far as I can tell right now, there doesn’t seem to be an App Store Connect problem here.

I take that back. There are four possible cases here, and I tried each one:

iOS-style macOS-style Result
--------- ----------- ------
no        no          OK
no        yes         OK
yes       no          OK
yes       yes         NG

That is, all the cases work except the one where you have an app that uses both an iOS-style and a macOS-style app group. In that case you hit one of two problems:

  • If your app ships on the Mac App Store, you’ll hit a validation issue.

  • If you distribute your app directly, you’ll hit an app group container protection issue when accessing at least one of the app groups.


So frustrated.

Yeah, that’s understandable. Sorry.

Please file a bug about this, then post your bug number here. I’ll use your bug to drive the escalation of this issue.

Share and Enjoy

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

That is the bucket we are in as well. iOS and macOS style. Filed as FB16807199.

Filed as FB16807199.

Thank you. I’ve passed this on to the relevant folks, and I’m actively monitoring this issue in general.

Share and Enjoy

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

I submitted a case where a macOS app has both iOS-style and Mac-style App Groups at the same time. as FB17014708

Help please. I have two macOS apps, that both share an App Group to exchange information.

I use Xcode 15.2, Ventura 13.6.1

Until mid Feb 25, all was working fine, but now I get the same error message upon distribution attempt as many above: Provisioning profile failed Qualification; Profile doesn't support App Groups.

I also now have two capabilities, both called App Groups in my Signing&Capability section;

One lists my App Group, starting with the team name as it is a macOS app and another capability that just states: Application Groups entitlement may require additional configuration. With an arrow that points to my entitlement file that contains the macOS app group name.

If I try to delete the second one, that was not there before, both App Group Capabilities are deleted, together with the corresponding entitlement.

In my developer account, the app IDs have the App Group box selected but I did not further 'configure', including registration, as this is a macOS app and any name other than starting with group (for iOS app groups) is not accepted.

I deleted the provisioning profiles in MobileDevice folder, but to no avail (no UserData folder in Ventura I think)

Am I missing something? I tried to follow all the comments within this thread.

The only item I failed with was to dump the actual provisioning profile. I selected Direct Distribution for the archived project and then exported it. It is exported as an app, not an installer file And when trying to dump the app, I get the error message that the embedded provisioning profile is not found.

So what used to be a formality procedure, has now taken a day of my life ;-) and I am still no wiser.

Any help appreciated!

To whom it may concern and help:

Summary: If you have macOS Apps and use App Groups and want to distribute to the App Store, do yourself a favour and upgrade your macOS to Sequoia and Xcode to at least 16.3.

Detail: I had no issues with app groups for macOS apps until after mid Feb 25. I used Xcode 15.2 on a Ventura iMac. Then, as per posts above, it all failed upon distribution. I also saw two AppGroup capabilities in Signing&Capability. I tried everything I read here and more. Registered the app group (although it is not necessary for a macOS app), included in Build Settings the 'Register App Group' trick from Eskimo (but it is for iOS App Groups), tried to monitor what is going on with my provisioning profile (but dump on exported app does not work as macOS apps do not embed a provisioning profile I think), deleted all provisioning profiles, created my own manually etc etc. Nothing worked. Upgrading to Sequoia and Xcode 16.3 does it without any pain: no registration of the App Group necessary, only 1 App Group in Signing and Capabilities, no configuration of AppGroups in AppID identifier necessary (as this would be for iOS App Groups) - only ticking the box for the AppGroup Capability.

Looks like I also ran into this issue, having both an application group starting with a team identifier and one with the "group" prefix.

Please file a bug about this, then post your bug number here. I’ll use your bug to drive the escalation of this issue.

Sure thing: FB17613203

Invalid code signing entitlements with app group on macOS
 
 
Q