SwiftData changes made in widget via AppIntent are not reflected in main app until full relaunch

Question

Created Jul ’25

Replies 2

Boosts 0

Participants 2

Hi, I’m using SwiftData with an @Observable DatabaseManager class that is shared between my app and a widget. This class is located inside a Swift package and looks roughly like this:

public final class DatabaseManager {
    public static let shared = DatabaseManager()
    
    private init() {
        let groupID = "group.com.yourcompany.myApp"
        let config = ModelConfiguration(groupContainer: .identifier(groupID))
        let c = try! ModelContainer(for: MyModel.self, configurations: config)
        self.container = c
        self.modelContext = c.mainContext
    }

    public private(set) var container: ModelContainer
    public private(set) var modelContext: ModelContext
}

In the main app, I inject the container and context like this:

struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .modelContainer(DatabaseManager.shared.container)
                .modelContext(DatabaseManager.shared.modelContext)
        }
    }
}

Both the widget and the main app import the same package, and both use DatabaseManager.shared for reading and writing objects.

The problem: When the widget updates an object using an AppIntent, the change is not reflected in the main app unless I fully terminate and relaunch it. If I just bring the app back to the foreground, it still shows stale data.

Is there a recommended way to make the main app observe or reload SwiftData changes that were made in the widget (via the same shared app group and container)? I’m already using .modelContainer(...) and .modelContext(...) in the app, and everything else works fine — it’s just the syncing that doesn’t happen unless I force-relaunch the app.

Thanks!

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’25

Accepted Answer

Recommended

In SwiftData, there are local changes and remote changes. Local changes are made from the same model container (ModelContainer); remote changes are made from a different model container. This is covered in the WWDC25 session: SwiftData: Dive into inheritance and schema migration (starting at 13:54).

Your main app and its widget use different model containers (because they run in a different process). For your main app, a change made from your widget is remote, and isn't observable. If a view in your main app observes a SwiftData model, or a result set that you fetch from a SwiftData store, it won't get updated for any remote change.

If you use @Query, however, the query controller under the hood observes the remote changes, and so a query-back SwiftUI view is supposed to get updated for a remote change. This is clearly described in the mentioned WWDC25 session. If you see otherwise, I’d suggest that you file a feedback report with a reproducible case, and share your report ID here.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

1

Answer 2

MichaelBolt OP

Jul ’25

Thank you very much for the detailed answer — it really helped me understand the problem and find a working solution!

I’m not sure if this is a bug or just how @Query is designed to work, but here’s what I found:

In my case, I have three models: A, B, and C. Model A contains arrays of both B and C. Initially, I used @Query only to fetch model A, and then displayed the related B and C items from within it — but I did not fetch B and C directly with @Query:

@Query var a: [A]

var body: some View {
    ForEach(a) { item in
        item.B
        item.C
    }
}

After reading your explanation, I changed my code to fetch B and C directly using @Query, and then filtered them to include only those related to the specific A instance:

@Query var a: [A]
@Query var b: [B]
@Query var c: [C]

var body: some View {
    ForEach(a) { item in
        b.filter{$0.a == item}
        c.filter{$0.a == item}
    }
}

Now, when the widget updates a B or C object, the corresponding view in the app does update as expected — so your explanation about remote changes and @Query behavior was exactly what I needed.

Thanks again!

0