Why is deinit not called on UITabBarController?

Question

I'm in the process of learning Swift. I wouldn't say I'm a novice, but I'm sure like many learning online I have missed a lot of fundamental steps to understanding what's really going on.

After getting pretty far with my app I am now seeing that my memory management is very poor. I am using SDWebImage caching which is definitely impacted by GIFS, but more to the point I am now learning about retain cycles and deinit.

Could someone please explain why a ViewController inside a UITabBarController deinit is never called?, why this isn't a bad thing? (unless it is) and just general advice/direction on memory management when using a tab bar controller. I have looked into retain cycles and why they are caused and fixed, but that doesn't seem to be my issue according to xCodes instrument tools.

Any advice would be much appreciated

Thanks.

Answer 1

Also, another reason an object may not be deinitialized is because of references. Since you are just starting Swift, I strongly suggest that you look up tutorials on Reference cycles, ARC (automatic reference counting) and memory leaks. They’ll teach you about
weak var And the proper time to use it. When starting, I’d say it’s not too important, but they are valuable later on when trying to get a job in software development.

Answer 2

A tab bar controller does not create and destroy the view controllers (tabs) it manages. It holds onto all of them so the user can switch between them as needed. Thus the view controllers from the tabs persist as long as the tab bar controller persists.

If your app's root view controller is a tab bar controller that never goes away, neither will the view controllers for the tabs.

If, instead, you create a tab bar controller and push it onto a nav stack, or present it modally, the tab bar controller will be released when it's popped/dismissed, and the view controllers will then be released as well.