This issue sadly generally affects instances of reference types stored as @State, even without using the new Observation API. It can therefore be considered an iOS 17 regression since storing simple reference types as @State without @ObservableObject was possible without leaks on iOS 16 (I can also confirm that the issue does not arise with @ObservableObject conformance). Though in general you likely want automatic observation, sometimes being able to store an instance of a non-observable reference type for the lifetime of a SwiftUI view is still useful and legitimate. This is for example how you might store an AVPlayer displaying its content in a VideoPlayer view, as show in this official code sample. I also reported this issue as FB13126425. Sample code is available here.

The issue has not been fixed in the iOS 17 RC published today. I guess there might be troubles ahead for early adopters of the new Observation API (but not only, see my previous comment) when the owning view is presented in a modal.

As written on a related thread, the issue has been fixed in iOS 17.2 beta 1.

Excellent news, the issue has been addressed in the iOS 17 beta 1 released yesterday. Thanks to everyone who made this important fix possible.

Hi Albert, Thank you very much for your quick answer. I was running Xcode 26 RC1 but I just updated to the final release (17A324). My iPhone 14 Pro is running iOS 26 final (23A341) and I can also reproduce the issue on another iPad Pro device running iPadOS 26 final as well. I updated my bug report with a video that shows that, in my case, I usually obtain: --> isEditing: true --> isEditing: false --> isEditing: true when dragging the slider knob once (the two last events being received when releasing the knob). Thanks again for your help. Best regards.