Usually you don't need Task.detached. To get a background thread simply move the code to a nonisolated async func in the View struct or move it to a struct that is not MainActor.

Usually you don't need Task.detached. To get a background thread simply move the code to a nonisolated async func in the View struct or move it to a struct that is not MainActor.

Since SwiftUI already is a view model you would be better off learning State & Binding instead of trying to build a custom layer of MVVM objects on top of it. That will likely cause the same kind of consistency errors that SwiftUI's use of View structs was designed to eliminate. Try breaking your view data up into View structs, put State in a shared common parent, pass down as let for read only or Binding var for read/write. The body will be called in all cases when the data changes.

delete

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.