UIViewController variables persist after deallocation - ios

Question

I am attempting to write tests to check for retain cycles but came across this odd behavior. A UIViewController's properties do not get deallocated when setting the view controller to nil. Take this mock object for example:
class BasicViewController: UIViewController {
var someObject = NSObject()
.....
}
All it has is a variable. You would assume that when calling basicViewController = nil would cause someObject to be nil, but its not.
it("releases someObject") {
var controller: MockController? = MockController()
weak var something = controller?.something
expect(controller).toNot(beNil())
controller = nil
expect(controller).to(beNil())
expect(something).to(beNil())
}
it("doesn't release someObject") {
var controller: MockController? = MockController()
weak var something = controller?.something
expect(controller).toNot(beNil())
_ = controller?.view
controller = nil
expect(controller).to(beNil())
expect(something).toNot(beNil())
}
When calling vc.view this invokes loadView as well as the UIViewController's life cycle functions - viewDidLoad, viewDidAppear and viewWillAppear. My question is why? Why is it that when I reference a UIViewController's view property, that all objects the UIViewController owns persists, even after setting the UIViewController to nil.
FWIW, I am using Quick and Nimble for testing, as well as Swift 3.1

Answer 1

Short answer:
Add an autoreleasepool, which will dictate precisely when objects are drained from the pool, and it works as you would have expected.
Long answer:
I'm experiencing the same behavior that you describe. But the problem isn't the properties of the view controller. It's the view controller itself.
In your examples, you're setting controller to nil and appear using the fact that it is now nil to infer whether the controller has been deallocated or not. But that's only testing whether that particular reference to the view controller is nil, but the view controller itself might not yet be deallocated. But you can use your weak var test with the view controller itself. Consider this view controller:
class BasicViewController: UIViewController {
// this is intentionally blank
}
I can write tests where the view controller manifests the behavior that you describe, where that XCTAssertNil test after loading the view fails:
class MyApp2Tests: XCTestCase {
func testWithoutView() {
var controller: BasicViewController? = BasicViewController()
weak var weakController = controller
XCTAssertNotNil(weakController)
controller = nil
XCTAssertNil(weakController) // this succeeds
}
func testWithView() {
var controller: BasicViewController? = BasicViewController()
weak var weakController = controller
XCTAssertNotNil(weakController)
controller?.loadViewIfNeeded()
controller = nil
XCTAssertNil(weakController) // this fails
}
}
But when I added an autoreleasepool to explicitly control when the pool is drained, it worked as expected:
func testWithViewAndAutoreleasePool() {
weak var weakController: BasicViewController?
autoreleasepool {
var controller: BasicViewController? = BasicViewController()
weakController = controller
XCTAssertNotNil(weakController)
controller?.loadViewIfNeeded()
controller = nil
}
XCTAssertNil(weakController) // this succeeds
}
BTW, if you're looking for additional confirmation on the timing of the deallocation of the view controller, itself, add a print statement in deinit (as well as where you set controller = nil) and you'll see that the timing of deinit changes in the presence of doing anything that loads the view.
I can't explain this behavior. Why should doing something with the view affect the view controller lifecycle? BTW, I also performed the above tests with properties of the view controller, like in your question, and I see the exact same behavior (but IMHO, that's unsurprising because it's just because the view controller itself hasn't been deallocated).
At least we can explicitly control the autorelease pool lifecycle timing with autoreleasepool.