Cocoa Naming Conventions for Memory Allocation

There is a lot to learn for somebody new to the developing for the iPhone. This learning curve is even steeper for somebody who did not previously develop for Cocoa on the Mac. One of the key concepts to grasp is memory management, or more precisely when to free up memory. The original iPhone devices only have 128MB of RAM a lot of which is taken up by the system. With no garbage collection, swapping or virtual memory tricks to help you out if you mess up you quickly get low memory warnings followed by a crash.

The basic rule of memory management is to only release memory that you actually own. This rule is deceptively simple but a lot of the confusion comes from not correctly understanding when you own memory and are hence responsible for releasing it. The Memory Management Programming Guide for Cocoa clarifies the issue of ownership:

You take ownership of an object if you create it using a method whose name begins with “alloc” or “new” or contains “copy” (for example, alloc, newObject, or mutableCopy), or if you send it a retain message. You are responsible for relinquishing ownership of objects you own using release or autorelease. Any other time you receive an object, you must not release it.

If you remember this rule when calling framework methods or third-party libraries you will not go far wrong. Just as important though is to follow this naming convention in your own code. Even if you are a one person iPhone developer and you are sure nobody else will ever see your code you should still follow this convention. In six months time when you have long forgotten that your method returns an object to the receiver you will use it again, forget to release and create a leak.

Still not convinced? Consider the following example of a method that allocates and returns an array of some objects:

- (NSMutableArray *)getListOfStuff {
  NSMutableArray *newList = [[NSArray alloc] initWithObjects:@"one",
                                                             @"two",
                                                             nil];
  return newList;
}

There is nothing technically wrong with this code and as long as I remember to release the array that it returns in my calling code there is no memory leak. However if I use the Build and Analyze option in Xcode it throws up a warning (or three):

Potential leak of an object allocated on line 25 and stored into 'newList';

1. Method returns an Objective-C object with a +1 retain count
   (owning reference)
2. Object returned to caller as an owning reference (single retain count
   transferred to caller)
3. Object allocated on line 25 and stored into 'newList' is returned from
   a method whose name ('getListOfStuff') does not contain 'copy'; or
   otherwise starts with 'new' or 'alloc'.  This violates the naming
   convention rules given in the Memory Management Guide for Cocoa
   (object leaked)

The offending code is graphically displayed in all its horror as follows:

Now you can just decide that this is a false alarm, ignore it and carry on regardless. That would be a mistake in my very humble opinion. If you follow the conventions Xcode will help you when in six months time you call the method again and forget to release it. It also costs you nothing to follow the conventions and get this safety net for free. In this case I just need to choose a sensible name for the method such as newListOfStuff and the warning goes away.

Never miss a post!

iOS Size Classes Cheat Sheet

Subscribe and get my free iOS Size Classes Cheat Sheet

Success! Now check your email to confirm your subscription and download your free guide to iOS Size Classes.

There was an error submitting your subscription. Please try again.

Unsubscribe at any time.
No time to watch WWDC videos?

Sign up to get my iOS posts direct to your inbox and I will send you a free PDF of my iOS Size Classes Cheat Sheet.

OK! Check your inbox (or spam folder) for an email to confirm your details and download your free guide to iOS Size Classes.

There was an error submitting your subscription. Please try again.

Unsubscribe at any time.
Archives Categories