Deinit not called on a UIViewController, but Dealloc is
Solution 1
TLDR:
Breakpoints will only work in deinit
if there is an executable line of code ahead of them.
- If you place a breakpoint on a line of executable code, then it will work.
- The executable line of code must belong to the
deinit
method.
Thanks to Adam for pointing me in the right direction. I didn't do extensive tests, but it looks like breakpoints behave differently in deinit
than everywhere else in your code.
I will show you several examples where I added a breakpoint on each line number. Those that will work (e.g. pause execution or perform their action such as logging a message) will be indicated via the ➤ symbol.
Normally breakpoints are hit liberally, even if a method does nothing:
➤ 1
➤ 2 func doNothing() {
➤ 3
➤ 4 }
5
However, in a blank deinit
method, NO breakpoints will ever get hit:
1
2 deinit {
3
4 }
5
By adding more lines of code, we can see that it depends on if there is an executable line of code following the breakpoint:
➤ 1
➤ 2 deinit {
➤ 3 //
➤ 4 doNothing()
➤ 5 //
➤ 6 foo = "abc"
7 //
8 }
9
In particular, play close attention to lines 7 and 8, since this differs significantly from how doNothing()
behaved!
If you got used to this behavior of how the breakpoint on line 4 worked in doNothing()
, you may incorrectly deduce that your code is not executing if you only had a breakpoint on line 5 (or even 4) in this example:
➤ 1
➤ 2 deinit {
➤ 3 number++
4 // incrementNumber()
5 }
6
Note: for breakpoints that pause execution on the same line, they are hit in the order that they were created. To test their order, I set a breakpoint to Log Message and Automatically continue after evaluating actions.
Note: In my testing there was also another potential pitfall that might get you: If you use print("test")
, it will pop up the Debug Area to show you the message (the message appears in bold). However, if you add a breakpoint and tell it to Log Message, it will log it in regular text and not pop open the Debug Area. You have to manually open up the Debug Area to see the output.
Note: This was all tested in Xcode 7.1.1
Solution 2
I haven't tried it yet but I did find this for you:
It seems the function won't be called unless some code is put inside the deinit (weird) must be part of swift's optimisation stage.
Try putting a print statement inside your deinit as suggested and report your findings
Related videos on Youtube
Senseful
Updated on July 09, 2022Comments
-
Senseful almost 2 years
It seems like the Swift equivalent of
dealloc
isdeinit
. However, when you attempt to define the method on a UIViewController, it doesn't behave as you would expect...Setup
- Create a new Single View project using Xcode 7.0, in either Swift or Objective-C.
- Add a "dismiss" button on the view controller that was created with the storyboard (I'll refer to this view controller as VC2; its class is ViewController).
- Add a new view controller and set it to be the initial view controller (VC1, class is nil).
- Add a "present" button to VC1 with a "Present Modally" segue to VC2.
- In VC2's code, put a breakpoint in
deinit
(Swift) ordealloc
(Objective-C). -
In VC2, make the "dismiss" button's action do the following:
// Swift: presentingViewController?.dismissViewControllerAnimated(true, completion: nil) // Objective-C: [self.presentingViewController dismissViewControllerAnimated:YES completion:nil];
- Run the app and tap both buttons to first present VC2 and then dismiss it.
Notice how in Objective-C, the
dealloc
breakpoint is hit.In Swift, on the other hand, the
deinit
breakpoint is never hit.Why is
deinit
never called? Is this a bug or by design?If this is by design, where should I put clean up code to free up resources when the view controller will no longer be needed? (It can't be in
viewDidUnload
since that method is deprecated. It can't be inviewDidDisappear
because something else might be holding a reference to it and will eventually show it again.)
Note: If you attempt to define a
dealloc
method in Swift, you get the following error:Method 'dealloc()' with Objective-C selector 'dealloc' conflicts with deinitializer with the same Objective-C selector.
If you have the Swift view controller inherit from an Objective-C controller, and you put a breakpoint in the Objective-C dealloc method, you will get the same buggy behavior defined above: the
deinit
will not be called, but thedealloc
will be called.If you attempt to use Allocations to view the number of instances of the class in memory, both versions show the same thing: The
# Persistent
is always 1, and the# Transient
increases each time you show the second view controller.Given the above setup, there should be no strong reference cycle holding on to the view controller.
-
Senseful over 8 yearsThis is a partially correct solution. I will add a new answer with my findings. Thanks for steering me in the correct direction, though!
-
Senseful over 8 yearsPlease see stackoverflow.com/a/33788952/35690 for a more thorough explanation!
-
DivineDesert about 8 yearsThis is not the case. Dont know what is the scenario. I have added executable lines, yet neither break point is working nor log is printed. (Tested in xcode 7.3)
-
Senseful about 8 years@DivineDesert: Are you sure your view controller is being deallocated?
-
iPP almost 8 yearsThank you. This had screwed up half my day.