Take the 2-minute tour ×
    [[NSNotificationCenter defaultCenter] removeObserver:self name:LASTUPDATEDLOCATION object:nil];
    [self setHeaderViewofWholeTable:nil];
    [self setFooterViewofWholeTable:nil];
    [self setHeaderActivityIndicator:nil];
    [self setFooterActivityIndicator:nil];
    [self setLastUpdated:nil];
    [self setLblPullDowntoRefresh:nil];
    [self setRefreshArrow:nil];
    [self setContainerForFormerHeader:nil];
    [self setFooterContainer:nil];
    [super viewDidUnload];

I thought viewDidLoad is called the view itself goes nil. When we set the view to nil, wouldn't all those things automatically become nil?

What am I misunderstanding?

share|improve this question
i think that's because need to avoid memory leak. –  Jeff Robert Dagala Oct 25 '12 at 3:09

4 Answers 4

up vote 2 down vote accepted

Some of the other answers cover some of this but there is more to this. A view controller will have its viewDidLoad method called. Typically this results in IBOutlets being retained and possibly lots of other views and objects being allocated and retained. If all goes well, eventually the view controller is deallocated and all of those retained objects need to be released.

That's the simple, happy path. Under low memory conditions, in iOS 5 and earlier, it is possible that a view controller's view will be unloaded. The viewDidUnload method was a chance for you to clean up all of the other objects that were retained as part of the viewDidLoad process. And here's the main reason - at some point, viewDidLoad may be called again to redisplay the view controller's view.

Most people write their viewDidLoad method like it will only ever be called once. And this is OK if the viewDidUnload method properly clears up objects. If it doesn't, the next call to viewDidLoad will result in a bunch of memory leaks.

ARC pretty much eliminated the issue with the memory leaks if you didn't clean things up properly in viewDidUnload. But viewDidUnload was still helpful for cleaning up memory when needed.

As was mentioned, as of iOS 6, a view controller's view in never unloaded in low memory conditions and the viewDidUnload (and viewWillUnload) methods have been deprecated.

If your app still supports iOS 5 along with iOS 6, you still need to make proper use of viewDidUnload. But if you want to free up memory when needed, use didReceiveMemoryWarning.

share|improve this answer
Under ARC setting those to nil won't do anything because the viewController itself will be gone soon and so is anything it refer. That's the main issue. +1 –  Anonymous White Oct 25 '12 at 5:29
And well most comprehensive answer. –  Anonymous White Oct 25 '12 at 5:29
@HaryantoCiu: It is not true that "the viewController itself will be gone soon" after viewDidUnload. A view can be loaded and unloaded multiple times in the lifetime of the view controller. But this does not create a memory leak with ARC because if you re-create objects in viewDidLoad, the old ones will be released automatically. But even with ARC it makes sense to release these objects to free memory in a low-memory situation, as maddy correctly said. (Everything in this comment is related to iOS <= 5 only.) –  Martin R Oct 25 '12 at 7:19
You mean after unloaded the viewController is still up there? Now this is what I want to know. Ah the only time viewDidload is called for me is when the viewController is about to be destroyed. I see. It's not always the case. –  Anonymous White Oct 25 '12 at 7:32
@HaryantoCiu: Yes, only the view is unloaded in low-memory situations (on iOS <= 5), not the view controller. You can check that in the Simulator with "Hardware -> Simulate Memory Warning" while your view is loaded but currently not visible. –  Martin R Oct 25 '12 at 8:50

Before ARC you needed to manually release objects that you allocated. Setting a property that is marked retain to nil does the releasing. This is no longer necessary when you use the Automatic Reference Counting (ARC) feature, which is on by default in the compiler that comes with recent versions of Xcode.

share|improve this answer
I know. The thing is the code snippet of setting those to nil is still generated even after ARC. –  Anonymous White Oct 25 '12 at 3:35

Good news. As of iOS 6, viewDidUnload has been deprecated. In iOS 5 and earlier, when memory was low there was a chance that your view might have been unloaded (and to make sure there were no memory leaks, you released IBOutlets in this method). But this is no longer called in iOS 6, and thus, no longer a requirement.

Now if there is a issue with memory, your view controller can override:

- (void)didReceiveMemoryWarning
    [super didReceiveMemoryWarning];
    // Dispose of any resources that can be recreated.
share|improve this answer
This is actually a better answer though a bit off topic. Well you need the point more. –  Anonymous White Oct 25 '12 at 3:35

We set so many things to nil to free up as much memory we can and reduce processor strain and increase battery life, not all objects automatically remove themselves from the queue.

share|improve this answer
+1 for everyone. This one is obvious actually. What I am asking is why we bother given that even without it memory will be released anyway. –  Anonymous White Oct 25 '12 at 3:36
I think we use ( used? ) the ViewDidUnload method, because you can know with so much certainty that any objects associated with that particular view can be safely and efficiently unallocated at the same time as the view. –  hillsons Oct 25 '12 at 4:02
@HaryantoCiu - Memory is not released unless we choose to release it. viewDidLoad might be called more than once. If viewDidUnload didn't release everything properly, you would have lots of memory leaks. It would not be released anyway. Of course ARC and iOS 6 make this less true now than in the past. –  rmaddy Oct 25 '12 at 4:06

Your Answer


