How to Use Automatic Reference Counting (ARC) for Your iOS App

By Jesse Feiler

You may want to use ARC for your iOS app. Automatic reference counting (ARC) is a compiler-level feature that simplifies the process of managing the lifetimes of Objective-C objects. Instead of you having to remember when to retain or release an object, ARC evaluates the lifetime requirements of your objects and automatically synthesizes the appropriate method calls at compile time.

It isn’t a new runtime memory model — and it isn’t a garbage collector. All the action takes place in the compiler.ARC takes care of the process of retaining and releasing objects by taking advantage of (and having the compiler enforce) naming conventions. It also relies on new object pointer ownership qualifiers.

Lest you worry, ARC is actually much faster (has better performance) than doing memory management on your own.

ARC doesn’t automate malloc() and free() (C functions) and doesn’t automate (CF) or (CG).

To be able to manage memory for you, ARC imposes some restrictions — primarily enforcing some best practices and disallowing some other practices. You won’t have to worry about most of this in an app that was created to use ARC.

Here are the rules that you have to follow to use ARC in your app.

  • Rule 1: Don’t call the retain, release, or autorelease methods. In addition, you can’t implement custom or methods.

    If you’re new to Objective-C programming, this rule won’t mean anything to you because it isn’t something you’ll have been doing in your existing apps. The only reason you’ll need to know about this rule is to understand what non-ARC code is doing to manage memory. If you’re an old hand, you’ll have been using these methods, and you’ll be happy to be told not to use them.

    You can provide a custom implementation of dealloc if you need to manage other resources.

  • Rule 2: Don’t store object pointers in C structures. Because the compiler must know when references come and go, you can’t store object pointers in structs. For most readers, that won’t be a problem because you’ll be using objects rather than C structures.

  • Rule 3: Inform the compiler about ownership when using Core Foundation–style objects. In iOS apps, you often use the CoreFoundation framework.

    CoreFoundation objects are anything beginning with a CF— things like the address book functions, for example. A CoreFoundation object would look like this:

    AudioServicesCreateSystemSoundID( (__bridge CFURLRef)burnRubberURL, burnRubberSoundID);

    ARC doesn’t automatically manage the lifetimes of CoreFoundation types, and there are CoreFoundation memory management rules and functions you can use, such as CFRetain and CFRelease (or the corresponding type-specific variants).

    Most of the time, you don’t have to worry about memory management because you usually will be casting an Objective-C object to a CoreFoundation type object, or vice versa — with the result that you end up with no CoreFoundation memory management in your code. You still have to let the compiler know about any memory management implications, though.

    You simply tell ARC not to worry by using a _bridge cast.

    If you do have CoreFoundation memory management, macros such as CFBridgingRetain or CFBridgingRelease will transfer ownership between ARC and CoreFoundation.

  • Rule 4: Use the @autoreleasepool keyword to mark the start of an autorelease block. This isn’t something you’ll be concerned about — or will ever do, for that matter. But it’s a rule nonetheless.

  • Rule 5: Follow the naming conventions. The compiler knows whether to retain an object based on what gets returned. Sometimes the object being returned by a method is retained, and sometimes it’s autoreleased later. If the object is going to be autoreleased, the object needs to be retained. If it’s already retained, you don’t want the compiler to do anything.

    The only way the compiler knows whether an object has been retained when it’s returned is through certain naming conventions. Under ARC, these naming conventions are now part of the language, and you must follow them.

    The compiler knows that a retained object has been returned when the first word in the first part of the selector (the method name) is alloc, new, copy, muteable copy, or init. These methods transfer ownership — where transferred ownership means that the object has been retained for you. An example is the NSString initWithFormat: method. (Remember that “ownership” is not exclusive ownership: Several objects may simultaneously own a single object.)

    In addition, you can’t give a property a name that begins with .

  • Rule 6:Just follow the rules. That’s it — no retaining releasing or autoreleasing. Just follow the rules and code to your heart’s content without worrying about memory management.

    Except, of course, in some situations, you’ll need to explicitly tell the compiler about what you want to do. In those cases, you’ll have to tell the compiler explicitly about an object’s lifetime.