WidgetKit with SwiftData on macOS

Developer Tools & Services Xcode
tomato-paste OP
Created Oct ’24
Replies 5
Boosts 0
Views 1k
Participants 2

Xcode: 16.1 macOS: Sequoia

When I run widget preview, I got the following errors

CoreData: error: Store failed to load.  <NSPersistentStoreDescription: 0x156237310> (type: SQLite, url: file:///Users/user/Library/Group%20Containers/group.com.app.name/Library/Application%20Support/default.store) with error = Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo={reason=Unknown failure to access file: 1} with userInfo {
    reason = "Unknown failure to access file: 1";
}

Unresolved error loading container Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." UserInfo={reason=Unknown failure to access file: 1}

with this code

let sharedModelContainer: ModelContainer = {
            let schema = Schema([Company.self, Person.self])
            do {
                return try ModelContainer(for: schema, configurations: [.init(isStoredInMemoryOnly: false)])
            } catch {
                fatalError("error:  \(error)")
            }
        }()

Does anyone know why this happens and how to fix this?

Replies  5
Boosts  0
Views  1k
Participants  2
DTS Engineer OP
Apple
Nov ’24

Does the issue only occur on preview, or does it occur when you run the widget as well? Can you reproduce the issue with the SwiftData version of the following sample? If yes, please share how you do that, and I'd take a closer look.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

0
tomato-paste OP
Nov ’24

Thanks for the response. Yes, it could reproduce it with Thread 1: Fatal error: Failed to create the model container: SwiftDataError(_error: SwiftData.SwiftDataError._Error.loadIssueModelContainer, _explanation: nil) error in DataModel.swift.

macOS: 15.1 (24B83)

Xcode: 16.1 (16B40)

0
DTS Engineer OP
Apple
Nov ’24
Accepted Answer
Recommended

Thanks for your following up. This is indeed an issue happening on macOS 15 Sequoia. Specifically, the widget doesn't have the access to the App Group container on macOS Sequoia because the container is iOS-styled (A), as mentioned in the System Integrity Protection section of the macOS Sequoia 15 Release Notes:

" ... This restriction also applies to app extensions, although in that case the system won’t prompt the user for consent but will instead just deny the access. "

This topic is discussed in App Groups: macOS vs iOS: Fight!, but long story short:

  1. The access failure isn't supposed to happen in the production environment, assuming that the iOS-style App Group container is correctly added to the App Group entitlements (com.apple.security.application-groups) in your macOS app and extension targets.

  2. To work around the access failure in the development phase, you can use a macOS-style App Group container (B) during development, and switch to the iOS-style App Group container for production.

  3. If your iOS app doesn't support Mac Catalyst or iOS Apps on Mac, and so doesn't share the same App Group container with your macOS app, you can choose to have your macOS app / extensions use a macOS-style App Group container, and your iOS app / extensions use an iOS-style container.

To use a different .entitlements file for your macOS app / extension in a universal target, use CODE_SIGN_ENTITLEMENTS to conditionalize the entitlements file build setting. Taking the TripsWidget target in the SampleTrips project as an example:

  1. Duplicate the existing TripsWidgetExtension.entitlements, name it TripsWidgetExtensionMacOS.entitlements, and add it to the project.

  2. Change to App Group container ID to from group.com.example.apple-samplecode.SampleTrips to <Your team ID>.com.example.apple-samplecode.SampleTrips

  3. Use the CODE_SIGN_ENTITLEMENTS build setting to conditionalize the entitlements file build, as shown in the attached screenshot.

(A) An iOS-style App Group container: A container with an ID that has a group. prefix.

(B) A macOS-style App Group container: A container with an ID that has a <TeamID>. prefix.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

1
tomato-paste OP
Nov ’24

Thank you for the response.

The app I am working on is a macOS app. Does that work with the workaround too?

Also, do you know when the bug will be fixed?

0
DTS Engineer OP
Apple
Nov ’24

"The app I am working on is a macOS app. Does that work with the workaround too?"

For a macOS app / widget to use an App Group container, you can simply change the prefix of your App Group container ID from group. to <TeamID>..

"Also, do you know when the bug will be fixed?"

To be very clear, this is not a bug on the system side. This is a system feature that you need to change your configuration to adapt.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

1
WidgetKit with SwiftData on macOS
First post date Last post date
 
 
Q