I found very useful the idea of thinking that @State is telling SwiftUI who owns that object. I'll never forget that, thank you so much!

Thank you for this video. The reason why an object can sometimes be a let and not a var has puzzled me, but thanks to your video I now understand why.

This was very useful. Thanks.

Lovely video overview, although your use of "we" and "you" when describing ownership and what's acting on what in comparing the differences was a bit confusing in places. I'm not yet using @Observable myself, more because of the brutal hit to compile time with macros, but I also want a shared observation publisher setup in a couple of places, which (as you mentioned near the end) Observable doesn't have anything to help with.

Hey, nice video 🎉 should i use @observationIgnored property wrapper for non tracked properties in observable macro object ? Is observable macro handles itself ?

Thank you so much for this video, Donny! I have a question. You said we should use @State if the view owns the @Observable object. However, the following code works perfectly fine, even tough it was not marked with @State: @Observable class MyCounter { var count = 0 } struct ContentView: View { private let counter = MyCounter() var body: some View { VStack { Button(action: { counter.count += 1 }, label: { Text("Increment") }) Text("The counter is \(counter.count)") } } } You gave a great and clear explanation about the fact that we use @State if the object is within a view that is itself a subview, and we want to persist its value if the parent view updates. But let’s suppose we are sure the view from the example above won’t be a nested view. We also know that this view owns the object. But given the fact that everything works normally without using @State, is there really a good reason to use it besides the case when the object is in a subview and we don’t want to lose its value if a parent view updates? And thank you again for your video, it helps a lot.