Is Object Releasing on Program Exit Really Needed?

It's not necessary. But if you're using valgrind or a similar tool, you'll soon discover that leaving all of your memory dangling swamps you with false warnings.

On the Linux side of things, the heap is grown using the sbrk system call. This grows the overall processor memory space by a large block at a time (so only one sbrk is needed to provide enough space for many mallocs). When the process goes away, the kernel reclaims all of the memory allocated by sbrk. This is why you're safe. The kernel will also close any file descriptors opened by that one process.

There are a few problems that can come up. If your process ever forks at an inopportune moment, any open file descriptors will be duplicated. I have seen this manifest itself as a TCP connection mysteriously hanging alive after the original process died, which is nasty. In addition, there are other resources that are just not process-scoped, so they won't be reclaimed when the process dies. This includes shared memory segments, temporary files, named pipes and UNIX sockets, and probably a slew of other IPC mechanisms.

In summary? Memory is fine. File descriptors are usually fine. Some of the more esoteric IPC features will be horribly broken if not cleaned up.

On the iPhone, you don't need to, and as far as I am aware, you can't. After receiving applicationWillTerminate: you have a few seconds to save your state and then the OS kills your process. Build one of the sample apps and put a breakpoint in one of the dealloc methods. They never get hit.

Here is a huge argument about it: link text

Note: Objective C dealloc is not the same thing as a C++ Deconstructor. In a Deconstructor you can close files, handles, etc. In Objective C dealloc is just for releasing memory. You must close your other resources earlier since dealloc may never get called.