Memory Management in Objective-C

06 Apr 2011

Memory management is something you have to account for on any platform. Memory management on a mobile platform is especially important because of the constrained resources inherent to the platform and is a big part of writing performant code. iOS does not have any sort of garbage collection available to a developer to use. Some see this as a flaw. However, following just a few guidelines and conventions will keep you out of a vast majority of memory problems and you won’t have any need or desire for something to clean up after you.

This post will attempt to explain to those not familiar with the memory management model in Objective-C on the Mac and iOS platforms how it works, and illustrate some guidelines for good memory management.

The Basics

Memory management in Objective-C is a reference counted model. Each object has a retain count associated with it which is at 1 immediately following allocation. Other objects can express interest in an object and cause the reference count to be incremented. Once they are through, they express that they are done with the object and the retain count is decremented. When the retain count changes from 1 to 0, the object is destroyed and the space in memory it occupied is returned back to the system. It’s important for objects to properly express interest/disinterest so that A) memory is not leaked, and B) references to deallocated objects are not left to linger.

To express interest in an object you call the retain selector on it.

	[foo retain];

This will cause foo’s retain count to be incremented. You now have ownership of this object. It will not be deallocated until you have expressed that you no longer need it. It is your responsibility to make sure that happens.

You express that you are done with an object by calling the release selector on it.

	[foo release];

This will cause foo’s retain count to be decremented. You no longer own this object and generally you should set foo to nil, or ensure that no messages are sent to foo after release is called, or both.

The Rules

The general rule is that if you create an object by calling a method whose name begins with “alloc”, “new”, “copy”, or “mutableCopy”, or if you explicitly send that object a retain message, you are responsible for calling “release” or “autorelease”. If you’re storing the object in question in an instance variable, typically you will release it in your objects dealloc method.

This works well in many cases. But let’s say you wanted to write a static method on a class that takes some parameter and passes back an instance of itself initialized with the passed in parameter? You’re required to call alloc to create the object, but if you call release on the object before returning it, it will be deallocated. If you don’t call release on it, it will be leaked because you won’t have a chance to call release on it ever again after returning. This is what “autorelease” was designed to solve. The static method I just described would be implemented like this:

	+ (FooClass *)fooWithBar:(BarClass *)bar {
		FooClass *returnFoo = [[self alloc] initWithBar:bar];
		return [returnFoo autorelease];
	}

Autorelease causes release to be called on returnFoo at “some point in the future”. Typically this is at the end of the current run loop. This gives a chance for the object calling “fooWithBar” to call retain on the object passed back before the retain count drops to zero, but still balances the “alloc” in the static method with a release. This is a simple but powerful concept and opens the door for many convenient design patterns.

A common gotcha for many newcomers to Objective-C in regards to memory management is properties and the “@synthesize” directive. Often, novices do not know what “@synthesize” actually generates or how it relates to memory management, so my next post will be explaining that very subject.

Memory Management in Objective-C

The Basics

The Rules

Further Reading