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?

Where do Apple's manuals insist on it? I've read most of their documentation at one time or another and don't recall that — in fact, I recall reading the opposite in several places, that not deallocing is better for efficiency. — Chuck
Apple also states that there is no guarantee that you would get a dealloc call on some of these classes when it is quitting. Thus placing code to save in your dealloc routine would be a bad thing. — mahboudz
@Chuck I've not found any optimization tips you've mentioned. I'd appreciated you to post one of them as answer to this question. — Artem Tikhomirov
The principle being applied is that all classes should have a -dealloc in case you reuse them. (For example, you might want to write unit tests.) Ensuing that every object is released when you quit is not a good idea, and is not encouraged by Apple. It’s a waste of time and power. (In fact, in Mac OS X 10.6, there’s an API to let the system instantly kill your app without saving anything in order to save time and power. I expect this will be in iPhone 4.0.) — Jens Ayton

Kendall Helmstetter Gelner Kendall Helmstetter Gelner · Accepted Answer · 2009-10-08T03:40:48

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.

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

5 Answers