Deinit not called when using UIImagePickerController in SwiftUI - swift

Question

The deinit block inside Custom is not called. I also tried the onDismiss variant instead of the isPresent Binding, but both do not run the deinit block for type Custom.
To reproduce my problem either clone the app and run it, or check out the code below. The deinit block is called when directly subclassing UIViewController, but it goes wrong for UIImagePickerController.
Clone: https://github.com/Jasperav/MemoryLeak
Code:
import Combine
import SwiftUI
struct ContentView: View {
#State var present = false
var body: some View {
Button("click me") {
present = true
}
.sheet(isPresented: $present) {
MediaPickerViewWrapperTest(isPresented: $present)
}
}
}
class Custom: UIImagePickerController {
deinit {
print("DEINIT")
}
}
struct MediaPickerViewWrapperTest: UIViewControllerRepresentable {
let isPresented: Binding<Bool>
func makeUIViewController(context: Context) -> Custom {
let c = Custom()
c.delegate = context.coordinator
return c
}
func updateUIViewController(_: Custom, context _: Context) {}
func makeCoordinator() -> Coordinator {
Coordinator(
isPresented: isPresented
)
}
}
final class Coordinator: NSObject, UINavigationControllerDelegate,
UIImagePickerControllerDelegate
{
#Binding var isPresented: Bool
init(
isPresented: Binding<Bool>
) {
_isPresented = isPresented
}
func imagePickerController(
_: UIImagePickerController,
didFinishPickingMediaWithInfo _: [
UIImagePickerController
.InfoKey: Any
]
) {
isPresented = false
}
func imagePickerControllerDidCancel(_: UIImagePickerController) {
isPresented = false
}
}

Answer 1

A possible workaround is to use view representable instead.
Tested with Xcode 13.2 / iOS 15.2
Below is modified part only, everything else is the same:
struct MediaPickerViewWrapperTest: UIViewRepresentable {
let isPresented: Binding<Bool>
func makeUIView(context: Context) -> UIView {
let c = Custom()
c.delegate = context.coordinator
return c.view
}
func updateUIView(_: UIView, context _: Context) {}
func makeCoordinator() -> Coordinator {
Coordinator(
isPresented: isPresented
)
}
}

Answer 2

When do de-initializers run? When the reference of the object reaches zero.
Thus, you expect the reference count to become zero when the picker is dismissed or is removed from the UI hierarchy. And while that might well happen, it's not guaranteed to.
Reference counting is not that simple, especially once you've handed your object to another framework (UIKit in this case). Once you do it, you no longer have full control over the lifecycle of that object. The internal implementation details of the other framework can keep the object alive more than you assume it would, thus the deinit code might not be called with the timing you expect.
Recommeding to instead rely on UIViewController's didMove(toParent:) method, and write the cleanup logic there.
And even if you're not handing your custom class instance to another framework, relying on the object's lifecycle for other side effects is not always reliable, as the object can end up being retained by unexpected new owners.
Bottom line - deinit should be used to clean up stuff related to that particular object.