Presented views with Bindings used within Forms / Lists introduces a retain cycle.

[timbueno]

Description

When presenting a view that contains a Form or List, and within that form a binding is used to the view’s ObservedObject. The ObservedObject is not released when the view is dismissed. If the view is presented again, and dismissed again, the first ObservedObject is then finally released.

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

The ObservedObject is released when the view is dismissed.

Actual behavior

The ObservedObject is not released. Subsequent presentation / dismissal cycles shows that the "deinit" is being run as expected.

Steps to reproduce

Sample project here:

https://github.com/timbueno/RetainApp

The apps 'WindowGroup' contains two views.

1. ContentView: This view works as expected and is vanilla SwiftUI
2. BuggedContentView: This view uses the library and exhibits the bugged behavior.

Run the app with the BuggedContentView enabled. Press the button and dismiss the view. The presented views ViewModel should deinitialize and print to the console. It does not. Presenting and dismissing the view again will show that the deinitilization runs on subsequent attempts.

Commenting out the TextField with the binding in the BuggedSheetView and redoing the steps above will show that the retain cycle no longer happens.

SwiftUI Navigation version information

0.7.1

Destination operating system

iOS 16.4

Xcode version information

14.3

Swift Compiler version information

swift-driver version: 1.75.2 Apple Swift version 5.8 (swiftlang-5.8.0.124.2 clang-1403.0.22.11.100)
Target: arm64-apple-macosx13.0

[mbrandonw]

Hi @timbueno, it's worth mentioning that this isn't really a retain cycle or even a memory leak, but more of a delayed release. If you re-open the sheet you will see that the previous model object is released.

It's also worth mentioning that this is reproducible in vanilla SwiftUI. I don't have the code sample immediately available right now, but we found that binding transformation methods seem to cause the issue for some reason. I will try to post a repro later.

[timbueno]

I'm not sure this is exactly the case. The first model seems to never release. I updated my example app with an id property. Make note of the id and notice that on subsequent opening / closing of the sheet - only the latest model is released. The first model is never released.

[tgrapperon]

Hey @timbueno. Running the app on iOS behaves as you describe, but running the app on macOS shows all models being released. Because the code is the same on our side, we can deduce that the behavior arises from SwiftUI's side.
Furthermore, if we snapshot the memory graph hierarchy, we can see that the model in question is singly referenced by a environmental PresentationMode (through the Binding that this type holds apparently).
So this is not a leak per-se, but rather SwiftUI that holds the value for reasons that are out of our reach (and likely a bug). We should probably file a FB.

[stephencelis]

@timbueno I believe we saw the first model eventually release after presenting and dismissing over and over, but we're not sure the condition for this to happen. At the very least it is not a memory leak that balloons memory over time, though we agree it's not a very nice bug.

Here's a version of "bugged content view" that you can drop into your project that shows how the bug manifests in vanilla SwiftUI: https://gist.github.com/stephencelis/28924ef5100a377718271696402fc1a7#file-buggedcontentview-swift-L54-L70

Basically, the act of capturing the original binding in a new binding via a transformation operation causes the model to be retained too long.

Here's a simpler feedback we just filed if you want to dupe:

https://gist.github.com/stephencelis/5d39ccb1cfb38b0f779bec43751df979

In the meantime, you can work around the bug if you depend on the object being deinitialized by creating a binding from scratch and avoiding binding transformations.

I'm going to convert this to a discussion since it's not really a bug with the library.

[jacobwallstrom]

I've been struggling with this leak as well. I agree that it is bug in Swift UI. Still I'm sharing my results here in case someone else is having this issue.

I discovered that the behaviour is different across IOS versions. So for example on IOS 16.0 simulator the code from the feedback https://gist.github.com/stephencelis/5d39ccb1cfb38b0f779bec43751df979 is not leaking with or without the identity transform.

But on 16.2 simulator it is leaking, but only when using the identity transform, so that is a regression from 16.0 and correspond to the behaviour described in the link.

On 17.0.1 simulator and 17.1.1 device it leaks both with or without the transform so that's a further regression.

Then on simulator 17.2 from Xcode beta 2 there's an improvement: the leak only happen with the transform.

There's a similar situation with the other modal API:s fullScreenCover(isPresented:) and fullScreenCover(item:)

[Namedix]

Can't we add appropriate methods that will create Binding without transformation while this bug exists on the SwiftUI side? Maybe someone already did a fork? As @jacobwallstrom mentioned, it is not limited only to forms and lists but also to normal navigations APIs such as full screen/sheet etc.

[stephencelis]

@Namedix If anyone comes up with a clever way to create a binding that works around the bug, we'd be happy to look into employing them in the library, but as this is a bug in SwiftUI, we're not sure there's much to be done aside from duping feedback and reaching out to Apple.