Perfect, thank you very much for your help!

Hi Travis, Thank you very much for your answer and for considering this feedback. A few remarks: The issue affects iOS 27, not iOS 26. On iOS 26 no specific code is needed. The issue still affects iOS 27 beta 8. You might have access to internal builds which resolved this issue but the latest developer beta we have access to is still affected. The workaround you propose is helpful, thanks. Note you also usually need a way to observe object property changes as well (e.g. via onReceive on a Published property publisher, if you are still using ObservableObject) so that the local @State can be updated accordingly. Otherwise changes made outside the menu will not be correctly reflected in the menu UI.

Seems fixed in iOS 27 beta 5. I only have access to a single iOS 27 test device. Maybe other people who reported this issue can confirm? Thanks in advance!

Thanks for your answer. You are right, I opened this issue more than a year ago, but since I never got any feedback in Feedback Assistant and the issue status was never updated I assumed discussing it here could help move things forward a bit.

Hi! I am not sure it was fixed in beta 1 (I remember I tested it and found it was still an issue) but it is actually fixed in beta 3. I have commented the feedback report yesterday and will continue monitoring this behavior in upcoming betas. Thank you very much for the update.

This issue has been resolved in tvOS 27 beta 3. Thanks to all people involved in fixing this leak.

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.

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

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

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.

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.