Concur on the BG music.. or at the least make it far quieter.

I second this comment as well. BG music is super distracting. That said, awesome video and keep them coming. Thanks for doing this. Please lower or remove background music on future videos

Thanks! I've uploaded a new video with the bg music far lower, it's the most recent one on the channel so feel free to take a look. The reason I've included it is because to me narration with complete silence is rather boring and lots of channels I watch do have very mild music playing in the background. I might end up removing it in future videos but I want to give it a few tries to see if there's a sweet spot.

agreed. The background music is just obnoxious. Without it the video would be 10x better

Thanks!

You do if that view creates/owns the state. Otherwise every time a new struct instance is made a new instance of the Observable is made.

Unfortunately you can't

Thanks! I'll definitely try and improve that for the next one(s)

@@DonnyWalsdev and if possible, move mic away from keyboard too. Bit difficult to focus on what's being said.

You can start "playing" the canvas from the previews UI and that should make it interactive

Thanks!

Thanks! i do like to have some sound in the background instead of pure silence so in my latest video I brought the volume down by a lot. It's an ongoing experiment for the moment

Probably because reference semantics are needed to ensure that you can actually observe a specific instance instead of having multiple separate copies that would get out of sync.

That's true for the observation part. But if you want the observable model's state to correctly be persisted you need @State to prevent SwiftUI from making a new instance every time your view struct is initialized. Note that this is only the case if you _own_ the observable in the view. Views that receive the instance in their init can indeed use a plain let/var

What about it? Is there something specific from that video you think I should look at?

I'll probably do a re-record of this video at some point without the bg music. It's a shame that it's not possible to "update" a video without a full reupload

If I understood it correctly from another source, it seems like before there was a memory leak with using @state with a class but now with iOS 17 that has been fixed and it's now recommended to use @state instead. However I'm not 100% sure so please double check yourself as well :)

@StateObject should be used for instances of ObservableObjects that you create in the view. So if a view creates an ObservableObject instance that you want to observe, you use @StateObject. When you're using the new @Observable macro, the SwiftUI view will observe your object no matter what. You use @State in order to make sure that the Observable instance you create persists when SwiftUI makes new instances of your view in response to model changes. Without @State you'd end up with fresh instances of your Observable every time a new view struct instance is created (which can be quite often)

No, an environment object is an object that conforms to ObservableObject and lives in the environment. An @Bindable property allows you to bind to properties of an Observable instance because without it yu can't bind at all. The environment and @Bindable both solve very different problems so you can't replace one with the other