App Group Not working as intended after updating to macOS 15 beta.

I have exactly the same problem. According to https://developer.apple.com/documentation/xcode/configuring-app-groups, the app group name on macOS should look like this: $(TeamIdentifierPrefix)com.example.mygroup. This does solve the popup problem, but unfortunately creates another one for multi-platform applications. Because the Xcode UI does not allow you to create different app groups for different platforms, app group names that are valid for macOS are invalid for iOS and vice versa. I have not found a solution yet.

I have a bunch of backstory to this issue in App Groups: macOS vs iOS: Fight!. I haven’t yet updated it for the changes in macOS 15 beta, partly because I’m waiting for this stuff to settle.

As to what’s going on in macOS 15 beta, start by reading the macOS Sequoia 15 Beta 2 Release Notes, and specifically the discussion associated with 114586798.

In terms of what you should do, that depends on what you mean by “runs on both iOS and macOS”. There are multiple different ways to have the same code run on both platforms:

• iOS Apps on Mac

• Mac Catalyst

• SwiftUI multiplatform app

• Two independent apps that share the same bundle ID

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

The problem with SwiftUI multiplatform apps at the moment is that it is not possible to declare different app groups for iOS and macOS because they do not use the same app group naming scheme.

@DTS Engineer Is there any solution to this?

Sorry I didn’t reply back in July. As I explain in Quinn’s Top Ten DevForums Tips, it’s important to reply as a reply, not in the comments.

The problem with SwiftUI multiplatform apps at the moment is that it is not possible to declare different app groups for iOS and macOS because they do not use the same app group naming scheme.

Right. Long term I’d like to see iOS-style apps groups supported by macOS provisioning profiles [1] but right now that’s not the case. That makes things hard for you, and for Xcode )-:

You might be able to get around this by conditionalising the entitlements file build setting (Code Signing Entitlements) based on your platform, but I don’t have time today to try this out today )-:

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

[1] Outside of iOS Apps and Mac and Mac Catalyst, where they’re already supported.

@DTS Engineer

Did you have time to try that out Quinn? Without a workaround or a fix, SwiftUI multiplatform apps are not really usable then.

Did you have time to try that out Quinn?

Not yet [1]. My hope that was you’d use my hint to explore this on your own.

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

[1] Although it just came up in another thread, and if I weren’t travelling for work I might’ve had the time to look at it.

The documentation, and Quinn's Fight article, imply that an App Store distribution of a native Mac app with an iOS-style app group will work, due to some manual approval by app store reviewers. Can anyone verify that?

I was able to confirm Quinn's suggested work-around does indeed work! I created a separate copy of the entitlements file for macOS and changed just the com.apple.security.application-groups setting in the macOS version so that the first part of the string is our team ID (instead of "group"). Then I added a macOS variant for both Debug and Release for the "Code Signing Entitlements" in build settings and set the new values to the macOS version of the entitlements file I just created.

Now I'm no longer getting that annoying alert when I run the macOS version! I also confirmed that the iOS version of my app still works as before.

Can anyone verify that?

I would love to hear direct experience from others.

Indirectly, I’ve been told internally that this should work, and I’ve seen numerous apps on the store that use iOS-style group names. However, not being able to submit apps to the store myself, I’ve no direct experience to share )-:

I was able to confirm Quinn's suggested work-around does indeed work!

Cool.

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

I have an app affected by this in production, using the App Group communicate between the widgets and the app. I've filed feedback FB15161604, but I'll assume that going forward I'll need to bite the bullet and move the App Group.

My issue is my users' preferences are trapped in the old App Group.

Are there anticipated issues with including both App Groups, but only accessing the old one to retrieve the old preferences? The users will get a permission prompt for the old App Group on the dev and TestFlight builds, but will they also get one on the App Store builds? It affects whether i need to create a migration UI to explain the situation, or can silently do it in background.

It would certainly be helpful if the TestFlight releases were consistent with the App Store releases.

Are there anticipated issues with including both App Groups, but only accessing the old one to retrieve the old preferences?

I wouldn’t expect to see problems with this on macOS 15. Beyond that, I’m not even going to attempt to predict The Future™.

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

It would certainly be helpful if the TestFlight releases were consistent with the App Store releases.

It seems that macOS engineering agrees with you (-: If you search the macOS Sequoia 15.1 Beta 4 Release Notes for FB14288230, you’ll see that we’ve made improvements in that release.

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

I tested with macOS 15.1 Beta 4 and can confirm that TestFlight builds are now working as expected (even older ones), including the widgets.

Dev builds still have the issues, so still seems like a good idea to migrate the container groups, but at least I should be able to do it transparently to the users.

Thanks!

This removed the error for me, but none of my user data shows on Mac, now. Does that mean I did something wrong, or right?

FWIW, the above solution wasn't working for me. Claude helped me with the following, and it successfully got rid of the prompt, and after a minute, started syncing with iCloud and is once again in sync with my iOS and watchOS versions:

Keep your existing App Group identifier (group.com.xxxxxxx.appName) as it is. This will work for both iOS and macOS. No need to create a separate entitlements file for Mac and do the conditional compiling.

Instead of changing the App Group identifier, we'll modify how we access the shared container on macOS:

Create a new Swift file called AppGroupHelper.swift and add the following code:

import Foundation

enum AppGroupHelper {
    static var containerURL: URL? {
        #if os(macOS)
        return FileManager.default.homeDirectoryForCurrentUser.appendingPathComponent("Library/Containers/com.companyName.AppName/Data/Documents")
        #else
        return FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.companyName.appName")
        #endif
    }
}

Update your CoreDataStack to use this helper:

lazy var persistentContainer: NSPersistentContainer = {
    let container = NSPersistentContainer(name: "appName")
    if let storeURL = AppGroupHelper.containerURL?.appendingPathComponent("appName.sqlite") {
        let description = NSPersistentStoreDescription(url: storeURL)
        description.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey)
        container.persistentStoreDescriptions = [description]
    }

    container.loadPersistentStores { (storeDescription, error) in
        if let error = error as NSError? {
            print("Unresolved error \(error), \(error.userInfo)")
        } else {
            print("Core Data stack has been initialized with description: \(storeDescription)")
        }
    }
    return container
}()

For macOS, you'll need to ensure that your app has the necessary entitlements to access its container directory. Add the following to your appName.entitlements file:

<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>

This approach should resolve the warning on macOS Sonoma while maintaining functionality on both platforms. It uses the app's container directory on macOS instead of the shared App Group container, which should avoid the permissions issue.

So I am still struggling with this issue. My issue is slightly different than most people in that I am not as much worried about Mac/iOS interoperability but just that when a user launches the next version of my app, they don't get the alert to allow the app to have access to the data.

My shipping Mac app stores it's data in an app group so that my internal extensions can also access the same data. This app group is named group.<mycompany>.<myappname>. This has been done for years and works great. It also works fine on Sequoia (for currently shipping version).

However, when I build the app with Xcode 16, I am now getting the alert. The alert happens even before my app delegate is loaded so it appears by just having the app group listed in my entitlements (or info.plist) is causing the alert.

Therefore, even if I wanted to migrate the user's data to a new location, they would still get the alert until all users migrated and I could do a new release removing the entitlement.

To be clear, on Sequoia 15.0.1 and using released Xcode 16, I am still getting this alert when building for the App Store (Test Flight) or direct distribution.

@colink, it sounds like you might have solved this for Test Flight builds but unclear what you did to do this.

Any help on this would be greatly appreciated!!! //Ray

raymo, two questions:

• Is your app distributed via the Mac App Store? Or do you distribute it directly using Developer ID signing?

• Is this a Mac Catalyst app? Or just a standard Mac app?

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

OK.

The group. prefix isn’t historically appropriate for macOS. I talk about this in detail in App Groups: macOS vs iOS: Fight!.

However, if you’re already shipping an app that way then you’ll want to maintain compatibility. The good news is that this should be possible. Quote the System Integrity Protection section of the macOS Sequoia 15 Release Notes:

the app must use FileManager to get the app group container path and meet one of the following requirements:

• the app is deployed through Mac App Store
• the app group identifier is prefixed with the app’s Team ID
• or the app group identifier is authorised by a provisioning profile embedded within the app.

Your app will fall enough case 1.

There are two challenges here:

• This doesn’t help during development. You continue to hit those popups.

• Prior to macOS 15.1 (currently a release candidate), you can’t test this with TestFlight. See the System Integrity Protection section of the macOS Sequoia 15.1 RC Release Notes.

Oh, and if your app group ID isn’t registered with the Developer website, do that now.

ps It’s better to reply as a reply rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other tips.

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

OK thank you!!

I was able to test with 15.1 via Test Flight and it worked! (That is, no alert).

I can live with development issue by using a team identifier for my dev builds.

And group ID is registered,

Thanks again! //Ray

macOS Sequoia has started to fully control security.

The issue is with App Groups in xCode.

The app developer in xCode should go to the section (repeat for each target):

Signing & Capabilities → Targets → TARGET_NAME → App Groups → App Group

in which he should specify the following:

$(TeamIdentifierPrefix)myFirm.myName

A fictitious ID like this does not work:

myGroupID.myFirm.myName

And in the program code he should specify the real group ID (in numbers)

let storeDirectory = FileManager.default.containerURL(
    forSecurityApplicationGroupIdentifier: “0123456789.myFirm.myName”
)

After recompiling the app, the problem disappears.

Is there any chance that this just gets fixed in Xcode so that I can use an app group starting with "group." in a multi-platform app without getting the permission popup every time I run my app from Xcode?

Is there any chance that this just gets fixed in Xcode … ?

Yes. Fixing this requires changes to both Xcode and the provisioning infrastructure on the Developer website. That’s quite feasible, and we all understand what a benefit it would be, but I’ve nothing to say as to when, or indeed if, it’ll actually happen.

For the moment, the advice in App Groups: macOS vs iOS: Fight! should let you:

• Get a good user experience when you deploy your app.

• Work around the problems you’ll encounter during development.

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

Another FB report, in case it helps: FB16680096 (public mirror)

The good news here is that we’re in the process of fixing this:

• We recently started seeding Xcode 16.3 beta, which enables iOS-style app groups in macOS apps.

• At the same time we updated the Developer website to include iOS-style app groups in Mac provisioning profiles.

We’re still working through some of the details where — which is why I haven’t yet updated App Groups: macOS vs iOS: Fight! to cover it in depth — but we’re clearly on a path to a solution now.

If you’re building a building a multi-platform app, try using Xcode 16.3 beta. I suspect it’ll Just Work™. Either way, reply back here with your experience because I’d love to hear it.

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

May seem like a dumb question but I'm somewhat overwhelmed by the amount of information and all the terms and conditions as it relates to this topic. There are several threads about cross platform issues, etc. as it relates to app groups but that is not my situation. Not too long ago I asked a similar question about a different app (not new but an update) and I just stuck with the group prefix on that one but I'd like to know what the recommendation is for a new Mac app.

So I have this simple situation: I have a new Mac app. Two versions:

1. Mac App Store (sandboxed)
2. Non-Mac App Store (not sandboxed).

They both use XPC service embedded in the app. XPC service + main app need an app group. Both non-MAS and MAS use app groups with their own XPC services (not with each other)

I always used teamIdprefix.groupidentifier.

So I configured and registered the group identifier for the outside the Mac App Store version because Xcode prompted me to. I'm using group. prefix (iOS style group). It seems to work fine. Is that the correct way for outside the Mac App Store? If I don't use group. prefix Xcode display the identifier in red like something is wrong.

And for the Mac App Store version, is it now recommended to use iOS style groups from now on? Can the recommendation on this topic be simplified to always use the iOS style app group (group prefix not team id prefix) and only use team id prefix for historical reasons if you already have a deployed app using the old style? Or am I misunderstanding something? Thanks a lot.