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.

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.

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.

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 )-:

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.

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 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.