Why should I release (and therefore dealloc) objects just before application quit?

Question

There are plenty of objects in each iPhone app witch will live forever till app dies. They are: application delegate, window, main view controller, may be navigation or tab controller, all the objects within them. Why on Earth should I release them just before quit spending precious CPU cycles? As far as I understand, apps process will be terminated, so it's heap, consistent or not will be gone too.

So why should I release them? Apple's dev manuals insist on it like in code sample following (from iPhone Development Guide). It's just first place I've found searching by word dealloc in library.

@implementation HelloWorldAppDelegate
@synthesize window;

- (void)applicationDidFinishLaunching:(UIApplication *)application { 

    // Override point for customization after app launch
    MyView *view = [[MyView alloc] initWithFrame:[window frame]];
    [window addSubview:view];
    [view release];
    [window makeKeyAndVisible];
}
- (void)dealloc {
    [window release];
    [super dealloc];
}
@end

From Discussions section on NHObject-dealloc method:

Note that when an application terminates, objects may not be sent a dealloc message since the process’s memory is automatically cleared on exit—it is more efficient simply to allow the operating system to clean up resources than to invoke all the memory management methods. For this and other reasons, you should not manage scarce resources in dealloc

But dealloc method in sample above is called in current implementation if your application is fast enough to react to applicationWillTerminate within 15 seconds.

So again. Should I avoid writing dealloc method above for app exit speed or are there any problems with such approach?

Answer 1

Because you will know, Artem.

Let's play a little game called "what if".

What If, you develop a great app. A masterful app, really - and the public loves it! Your sales swell, birds sing your name awing in the sky!

But, you chose not to do anything in your AppDelegate dealloc. Just a few seconds of time, you decided not to bother with. What's the harm?

Oh at first you sleep easy atop the piles of money. But as sales grow and grow, a little twinge comes upon you. And then the dreams start.

Square shapes, indistinct at first. Days pass and they grow clearer, as you sleep less and less. Then finally, one day, you see.

They are blocks, Artem. Memory blocks. And what are they doing in your dreams? Well you see, not quite freed from existence before the application quits, they had to go somewhere. The app was gone, the phone had moved on.

So they moved into your HEAD. And every day, more arrive, leaving less room for YOURSELF.

I hope this has been informative... Artem.

Answer 2

I guess the only answer that makes any sense to me is, "consistency". No, you may not always need to implement dealloc, but if you always do it, you won't forget to do it when it does matter. And besides, it's not like it costs you more than 30 seconds to write two lines of code that might not get called.

You're also very unlikely to waste your precious CPU cycles (which cycles, by the way, are not so precious that you would ever notice a difference. Those iPhone animations exist mainly to buy your app time to start up/shut down) because when the application terminates, it usually doesn't bother to dealloc objects because, as you say, that heap's memory allocating days are behind it.

So, yeah, dealloc is unlikely to ever be called on a UIApplicationDelegate, but does it cost you anything to do it anyway? Not really.

Answer 3

The best reason is reuse. There's a chance you may move an object from one place to another or repurpose it. If you do that it's best to make sure all your i's are dotted and t's crossed.

It's also just good habit. If you remember to do it there, you'll do it everywhere.