Where do they recommend doing that? In the App struct (which is only init once) @State doesn't seem any different behavior from let container = ModelContainer.create() In a View struct @State will leak the initialValue object every time the View is init. Maybe they mean use @StateObject?

StKiril, that example is from the model data section of the documentation so irrelevant to this discussion. The basics are: View data = View structs, State, Bindings, computed vars, .task Model data = Observable, ObservableObject

@erdeszbalazs read that link closely, it says "in your data model type", it isn't for view data, that is what View structs are designed for. Also at 20:50 in Data Essentials in SwiftUI WWDC 2020 they say "Views are very cheap, we encourage you to make them your primary encapsulation mechanism".

Rebooting the simulator fixed the issue for me. They wanted a sysdiagnose which I wasn't able to provide because couldnt recreate the problem so I just closed the feedback.

ToDosApp.body.getter shouldn't be initing any objects

Sorry I wrote this a long time ago. Now I would recommend removing the object the completely and using .task for async/await.

You shouldn't do @State private var vm = ViewModel() because your ViewModel is a class. You would be better using the View as the view model and declaring @State for your data, e.g. @State var showDetails: Bool = false. You could group related state vars into a struct if you like but not a class. You can use mutating func for logic related to the vars.

I have the same bug and I'm adding the first region before I start the event loop. The blue location arrow appears in the task bar and the simulated location is in the region, yet no even update happens and state remains as unknown.

Task.detached is a bad idea

When it detects a change in data, SwiftUI makes new View structs and diffs then with the previous ones. That difference is used to drive initing/updating/deallocing UIKit objects. Hopefully that helps you understand View structs are the view model.

If it doesn't make sense the first thing to learn (and Apple don't do a great job of explaining this) that the View struct hierarchy with its dependency tracking and diffing is the view model already. If you ignore that and use your own view model objects then you'll likely have the same consistency bugs that SwiftUIs implementation using structs was designed to eliminate. It's very tempting to use familiar objects but it really is worth putting the effort in and learning to use View structs.

edit: regarding the last question, sorry in my testing View was still Equatable. Once I removed that, the object's == was called and if I had 2 objects and switched them but made the == make them look equal then body wasn't called. ContentView2(object: ((counter % 2 == 0) ? object1 : object2), x: counter2). This probably isn't too useful for ObservedObject but for standard objects that are designed to be immutable, like NSURL or NSManagedObjectID then I suppose this behaviour is useful.

I tried this but I receive a strange compilation error error: Invalid Swift parseable output message (malformed JSON): 1``

If I set the min deployment to macOS 14 then the shortcut will run. I can't run the app though because my version of macOS is 13.5.

In Under the Radar - WWDC2023 at 24:37 Josh Shaffer says "you don't even have to write @Relationship, we detect the relationships"