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"

you can't because if the View containing the FetchRequest is re-init (because of a recompute of the parent View's body) any changes made to the sort within onChange are lost.

make the MTKView a lazy var in the Coordinator class and set mtkView.delegate = self when returning it. Return context.coordinator.mtkView from makeUIView. You'll find this pattern in PaymentButton.swift in Apple's Fruta sample. Unfortunately engineers of other frameworks don't get it quite right, e.g. Coordinator(self) is wrong because anyone who knows SwiftUI knows the View struct is immediately discarded.

Excellent, thanks for taking the time to let me know about this! It works exactly as I wanted but sadly the way the picker view controller is shown is still very buggy so I likely will still use my own version using UIViewControllerRepresentable. Very strange it is missing from the documentation, I'm guessing its because the doc parser is not smart enough to process an extension of View in SwiftUI framework when working on the PhotosUI framework - submitted feedback FB11434717.

I think the async methods are just auto-generated by Swift, I don't think they actually coded anything. Also they don't support task cancellation so pretty useless for SwiftUI's task modifier.

Great tip, fixed my problem in development when changing from data to package and it was still being considered a folder by Finder and the app, even newly saved documents.

Because persistent history tracking transactions take up space on disk