Retain cycle in SwiftUINavigation when presenting a focused TextField?

[cabeca]

I think I’ve found a retain cycle problem in the SwiftUINavigation library. Find a sample project below.
I'm still using version 1.0.3 of the library (pre macros requirement) and using the .sheet(unwrapping:case:) because of it. The CasePathable .sheet(item:) works fine. Any suggestions other than reverting to plain swiftUI for sheet presentation?

// Create a new project and name it `TextFieldRetainCycle`. Paste the content of this file in `TextFieldRetainCycle.swift`
// The retain cycle only happens when:
//  * press SwiftUINavigation `Destination` button
//  * on the presented sheet, press `Input` button
//  * on navigated content and after focus is on TextField, dismiss the modal by swiping down.
//  * `FlowModel` is not deinited in this case. In all other cases it is properly deinited

import SwiftUI
import SwiftUINavigation

@main
struct TextFieldRetainCycleApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

@MainActor
public final class ContentModel: ObservableObject, Identifiable {
    enum Destination {
        case flow(FlowModel)
    }

    @Published var destination: Destination? {
        didSet {
            print("🤯 destination \(String(describing: destination))")
        }
    }

    func destinationButtonTapped() {
        destination = .flow(FlowModel())
    }

    @Published var presented: FlowModel? {
        didSet {
            print("🤯 presented \(String(describing: presented))")
        }
    }

    func presentButtonTapped() {
        presented = FlowModel()
    }
}

struct ContentView: View {
    @StateObject var model = ContentModel()
    var body: some View {
        VStack(spacing: 20) {
            Button("Destination") {
                model.destinationButtonTapped()
            }
            Button("Present") {
                model.presentButtonTapped()
            }
        }
        .padding()
        .sheet(
            unwrapping: $model.destination,
            case: /ContentModel.Destination.flow
        ) { $model in
            FlowView(model: model)
        }
        .sheet(item: $model.presented) { model in
            FlowView(model: model)
        }
    }
}

#Preview {
    ContentView()
}

@MainActor
public final class FlowModel: ObservableObject, Identifiable {

    enum Step: Hashable {
        case initial
        case idInput
        case final
    }

    @Published var path: [Step] = []
    @Published var idInput: String = ""

    init() {
        print("🤯 INIT FlowModel \(id)")
    }

    deinit {
        print("🤯 DEINIT FlowModel \(id)")
    }

    func idInputStepNextButtonTapped() {
        path.append(.final)
    }

}

struct FlowView: View {
    @ObservedObject var model: FlowModel
    @Environment(\.dismiss) var dismiss

    var body: some View {
        NavigationStack(path: $model.path) {
            EmptyView()
                .navigationDestination(for: FlowModel.Step.self) { step in
                    switch step {
                    case .initial:
                        Button("Input") {
                            model.path.append(.idInput)
                        }
                    case .idInput:
                        SecondView(
                            input: $model.idInput,
                            onClose: { dismiss() },
                            onNext: { model.idInputStepNextButtonTapped() }
                        )
                    case .final:
                        Color.green
                    }
                }
        }
        .onAppear(perform: { model.path = [.initial] })
        .onDisappear(perform: { model.path = [] })
    }
}

struct SecondView: View {
    typealias Action = () -> Void

    @FocusState private var isFocused: Bool
    @Binding var input: String
    let onClose: Action
    let onNext: Action

    var body: some View {
        VStack {
            TextField("Input", text: $input)
                .keyboardType(.numberPad)
                .focused($isFocused)

            Button("Next") {
                onNext()
            }
            .disabled(input.isEmpty)
        }
        .navigationTitle("Step 1")
        .navigationBarTitleDisplayMode(.inline)
        .toolbar {
            ToolbarItem(placement: .navigationBarTrailing) {
                Button("Close") {
                    onClose()
                }
            }
        }
        .navigationBarBackButtonHidden()
        .onAppear {
            isFocused = true
        }
    }
}

[cabeca]

The example project has an example in plain SwiftUI with just ObservedObject models, where the issue is not present.

The main difference seems to be this:

• .sheet(unwrapping:case:) passes a binding to the model to the content closure
• plain SwiftUI and CasePathable .sheet(item:) passes the plain model to the content closure

    .sheet(
        unwrapping: $model.destination,
        case: /ContentModel.Destination.flow
    ) { $model in
        FlowView(model: model)
    }
    .sheet(item: $model.presented) { model in
        FlowView(model: model)
    }

If using a binding to the model, there seems to be a retain cycle, but only in the case where the TextField gains focus.

[mbrandonw]

Hi @cabeca, we dug into this a bit today, and there's a bit of a conundrum.

First of all, if you simply present and dismiss right away, you will see that only the first model never deinits. If you present/dismiss again, that model will be deallocated correctly. Second, somehow focusing a text field changes this behavior. If you present/focus/dismiss, then the model is never deallocated.

These problems seem to stem from our Binding(unwrapping:) helper, which powers these tools. If you switch to vanilla SwiftUI's version of this initializer, Binding<V?>(_:), then the leak goes away. However, the whole reason we introduced our Binding(unwrapping:) is because we saw crashes in SwiftUI's initializer. Some of the crashes have been fixed in later versions of iOS, but we're not 100% certain it is fully crash free.

So there doesn't seem to be a good option here. We can keep Binding(unwrapping:) and accept that some objects will leak (and we believe that SwiftUI does have some responsibility in this), or we can move to SwiftUI's Binding<?>(_:) and open up the possibility of crashes.

[mbrandonw]

Hi @cabeca, sorry I think the reason you are seeing slightly different results is because we reduced your project quite a bit to get at the true root of the problem. Here is a minimal project that shows the problem:

import SwiftUI
import SwiftUINavigation

@main
struct TextFieldRetainCycleApp: App {
  var body: some Scene {
    WindowGroup {
      ContentView()
    }
  }
}

@MainActor
public final class ContentModel: ObservableObject, Identifiable {
  @Published var presented: FlowModel? {
    didSet {
      print("🤯 presented \(String(describing: presented))")
    }
  }
  func presentButtonTapped() {
    presented = FlowModel()
  }
}

struct ContentView: View {
  @StateObject var model = ContentModel()
  var body: some View {
    Button("Present") {
      model.presentButtonTapped()
    }
    .sheet(item: $model.presented) { $model in
      FlowView(model: model)
    }
  }
}

@MainActor
public final class FlowModel: ObservableObject, Identifiable {
  @Published var idInput: String = ""
  init() {
    print("🤯 INIT FlowModel \(id)")
  }
  deinit {
    print("🤯 DEINIT FlowModel \(id)")
  }
}

struct FlowView: View {
  @ObservedObject var model: FlowModel

  var body: some View {
    TextField("Text", text: $model.idInput)
  }
}

This shows that it has nothing to do with navigation stacks or any of that stuff. All it takes is to present a sheet that displays a UI component that takes a binding (not even focusing the text field).

When I run this in a 17.5 simulator and I do a present/dismiss twice, I get the following logs:

🤯 INIT FlowModel ObjectIdentifier(0x0000600000c783f0)
🤯 presented Optional(CaseStudies.FlowModel)
🤯 presented nil
🤯 INIT FlowModel ObjectIdentifier(0x0000600000c7c180)
🤯 presented Optional(CaseStudies.FlowModel)
🤯 presented nil
🤯 DEINIT FlowModel ObjectIdentifier(0x0000600000c7c180)

Notice that the first FlowModel did not deinit, but the second does (as would the third, forth, etc.).

However, if I run this in an iOS 18 simulator I get the following logs:

🤯 INIT FlowModel ObjectIdentifier(0x0000600000c80390)
🤯 presented Optional(CaseStudies.FlowModel)
🤯 presented nil
🤯 DEINIT FlowModel ObjectIdentifier(0x0000600000c80390)
🤯 INIT FlowModel ObjectIdentifier(0x0000600000c84b40)
🤯 presented Optional(CaseStudies.FlowModel)
🤯 presented nil
🤯 DEINIT FlowModel ObjectIdentifier(0x0000600000c84b40)

Now the models are correctly being deallocated. This seems to point to the fact that it is definitely a SwiftUI bug.

But also if you then do a present/focus/dismiss you get a different init/deinit pattern. And again, the fact that focusing is even affecting any of this really just points to more SwiftUI bugs, and I'm not sure there is much we can do about it. If there is a fix we'd happily accept a PR, but right now it's hard to see how our tools are causing this.

[cabeca]

Hello again,

I was really confused for a moment while trying your streamlined example until I realized a very subtle difference:

    // This is the SwiftUINavigation version passing in a binding to the model `$model in`
    .sheet(item: $model.presented) { $model in 
      FlowView(model: model)
    }

    // This is the vanilla SwiftUI version  passing in a plain model `model in`
    .sheet(item: $model.presented) { model in 
      FlowView(model: model)
    }

The first is the one that shows all the leak problems, while the second one is what I used as an example of plain SwiftUI that does not have any leaks. But they are definitely not the same.

I tried replacing the Binding(unwrapping:) with SwiftUI Binding(_ base:) and I got the same leak patterns, so indeed, it seems that the library is not doing anything wrong, just propagating the underlying SwiftUI bugs.

Let's hope that iOS 18 fixes the underlying SwiftUI leaks.

For now, I will use the plain SwiftUI version for my specific case as a workaround, as I cannot have this particular flow, leak memory.

Thank you for the time you spent on this, and thank you for all the work you do for the community!

[stephencelis]

@cabeca We will caution you that Swift's Binding(_ base:) has been known to cause crashes. Some are fixed in more recent OSes, but depending on your platform support, you may deploy code that causes your app to crash.

What in particular prevents you from allowing this leak to occur? SwiftUI is already known to capture models for longer than a view's lifecycle, so your code should ideally be resilient to leaks like this. If you're depending on a deinit hook we'd recommend moving that logic into an onDisappear instead. If you have another reason you think this flow cannot leak I'd definitely be interested to know what it is!

All that is to say at the library level we think a leaked object is more acceptable than a crash, and so I would think that would hold true for your case as well

[cabeca]

Hello again!

Just to be clear, I only tried using Binding(_ base:) to verify that I got the same leaking behavior as Binding(unwrapping:). I am not using Binding(_ base:) anywhere in production.

What I ended up using was a workaround was the vanilla SwiftUI .sheet(item:) that takes a closure where the plain model is passed in, in substitution to the .sheet(unwrapping:case:) that takes a closure where the binding to the model is passed in. The vanilla SwiftUI .sheet(item:) does not have any leaks.

Your second paragraph is news to me and quite frankly, surprising! The majority (if not all) of my models have this type of code in them:

// In ObservableObjects:
enum Destination {
  case flow(FlowModel)
  case drill(DetailModel)
  case overview(OverviewModel)
}

@Published var destination: Destination?

func presentFlowButtonTapped() {
  let model = FlowModel()
  destination = .flow(model)
}
// similar for the other cases

// In SwiftUI Views:
.sheet(unwrapping:...) { $model in
  FlowView(model: model)
}

I always assumed that the lifecycle of these Model's was tied to the destination variable. And most importantly, that when you assigned nil or any other case to the destination, the Model associated with the outgoing case would be deallocated at that point.

SwiftUI is already known to capture models for longer than a view's lifecycle, so your code should ideally be resilient to leaks like this.

As I said, this is news to me and contrary to my understanding of how SwiftUI works. But now I've learned.

If you have another reason you think this flow cannot leak I'd definitely be interested to know what it is!

In my case the flow was a complex product registration flow with several steps, where one of the steps is a QRCode scanner step that uses the camera, and wraps UIKit's DataScannerViewController, in addition to other resource intensive steps that get pushed to a navigation stack. I was counting on the flow model to be deallocated to perform cleanup of the whole thing, but with it leaking I got all sorts of problems. I have since moved to perform cleanups on SwiftUI .onDisappear instead of the model dealloc, but still, it feels wrong to let the leak happen.

Which brings me to the following point: When using the .sheet(unwrapping:case:) I always grab the binding that is passed in $model in and pass a plain model to the view FlowView(model: model). So, in reality I really don't need the binding, only the model. I understand that having bindings passed into the closure is useful if using value type models, but if I'm only using reference type models, should there be a .sheet(unwrapping:case:) that passes the plain model to the closure, just like the vanilla SwiftUI one, and thus avoiding potential leaks?

[cabeca]

I realized that I can easily use the vanilla SwiftUI sheet presentation APIs, by following the advice on your latest video about deriving binding with computed properties. I will do that for this case.

[cabeca]

I'm sorry to get back at you again, but I have another example that I cannot quite explain. I used your streamlined example and modified it slightly to include an enum Destination, as that is my most used pattern.

I then used plain SwiftUI .sheet(item:) that passes in a plain model to the content closure. No SwiftUINavigation involved at all.
I then tried 4 alternatives to present the plain SwiftUI .sheet

• The first using $model.destination.case(/ContentModel.Destination.flow). This one leaks as discussed.
• The second one using a model computed property to derive a binding. This one does not leak.
• The third one using just $model.destination and switching on the enum. This one did not leak.
• The fourth one using a custom binding flowBinding. This one did not leak.

I cannot explain this behavior. Could this be a problem with the .case Binding helper?

import SwiftUI
import SwiftUINavigation

@main
struct TextFieldRetainCycleApp: App {
  var body: some Scene {
    WindowGroup {
      ContentView()
    }
  }
}

@MainActor
public final class ContentModel: ObservableObject, Identifiable {
    enum Destination: Identifiable {
        var id: ObjectIdentifier {
            switch self {
            case .flow(let model): model.id
            }
        }

        case flow(FlowModel)
    }
  @Published var destination: Destination? {
    didSet {
      print("🤯 destination \(String(describing: destination))")
    }
  }
  func presentButtonTapped() {
      destination = .flow(FlowModel())
  }

  var flowModel: FlowModel? {
    get { (/ContentModel.Destination.flow).extract(from: destination) }
    set { destination = newValue.map { (/ContentModel.Destination.flow).embed($0) } }
  }

}

struct ContentView: View {
    @StateObject var model = ContentModel()
    var body: some View {
        Button("Present") {
            model.presentButtonTapped()
        }
//        // This one leaks
//        .sheet(item: $model.destination.case(/ContentModel.Destination.flow)) { model in
//            FlowView(model: model)
//        }
//        // This one does not leak
//        .sheet(item: $model.flowModel) { model in
//            FlowView(model: model)
//        }
//        // This one does not leak
//        .sheet(item: $model.destination) { destination in
//            switch destination {
//            case .flow(let model):
//                FlowView(model: model)
//            }
//        }
//        // This one does not leak
//        .sheet(item: flowBinding) { model in
//            FlowView(model: model)
//        }
    }

    var flowBinding: Binding<FlowModel?> {
        Binding(
            get: {
                switch model.destination {
                case .flow(let model): model
                default: nil
                }
            },
            set: { incoming in
                if let incoming {
                    model.destination = .flow(incoming)
                } else {
                    model.destination = nil
                }
            }
        )
    }

}

@MainActor
public final class FlowModel: ObservableObject, Identifiable {
  @Published var idInput: String = ""
  init() {
    print("🤯 INIT FlowModel \(id)")
  }
  deinit {
    print("🤯 DEINIT FlowModel \(id)")
  }
}

struct FlowView: View {
  @ObservedObject var model: FlowModel

  var body: some View {
    TextField("Text", text: $model.idInput)
  }
}

[cabeca]

The findings above are interesting @mbrandonw @stephencelis but I'll go ahead and close this discussion, as most of it is probably related to SwiftUI bugs and not the library itself.