What are the advantages and disadvantages of using ARC?

Question

What are the advantages and disadvantages of using the new automatic reference counting (ARC) memory management style in an iOS project?

Can you choose not to use ARC when developing with the iOS 5.0 SDK?

Do you recommend ARC or manual reference counting (MRC) for a new project?

Will an application using ARC be able to run on older OS versions than iOS 5.0?

Solution 1

What are the advantages and disadvantages of using the new automatic reference counting (ARC) memory management style in an iOS project?

An ARC program's execution is nearly identical to well written MRC. That is, the behavioral differences are often undetectable because both the order of operations and performance are very close.

If you already know how to implement OS X or iOS apps with manual reference counting (MRC), ARC doesn't really add functionality -- it just allows you to remove reference counting operations from your sources.

If you don't want to learn MRC, then you may want to first try ARC. A lot of people struggle with, or try to ignore common practices of MRC (example: I've introduced a number of objc devs to the static analyzer). If you want to avoid those issues, ARC will allow you to postpone your understanding; you cannot write nontrivial objc programs without understanding reference counting and object lifetimes and relationships, whether MRC, ARC, or GC. ARC and GC simply remove the implementation from your sources and do the right thing in most cases. With ARC and GC, you will still need to give some guidance.

I've not measured this, but it may be worth mentioning that compiling ARC sources would take more time and resources.

If the program you're developing has rather loose usage of reference counting (e.g. a typical amount of autoreleases), switching to ARC could really improve your program's execution times and peak memory usage.

Can you choose not to use ARC when developing with the iOS 5.0 SDK?

Yes, using CLANG_ENABLE_OBJC_ARC. ARC is binary compatible, and all that really happens is that the compiler does its best to introduce the appropriate reference counting operations automatically for you, based on the declarations visible to the current translation (see my answer here as to why translation visibility is important). Therefore, you can also enable and disable it for some sources in a project and enable it for others.

Mixed mode (some MRC and some ARC sources) is however quite complicated, and subtly, notably wrt implementations which may be duplicated by the compiler (e.g. an inline function's body may be incorrect). Such mixed mode issues will be very difficult to isolate. ObjC++ programs and sources will be particularly difficult in this regard. Furthermore, the behavior may differ based on your optimizations settings (as one example); a program which works perfectly in a debug build may introduce a leak or zombie in release.

Do you recommend ARC or manual reference counting (MRC) for a new project?

Personally, I'll be sticking with MRC for some time. Even if ARC has been tested in real world usage, it's likely that there are a number issues remaining which show up in complex scenarios, which you will want to avoid being the first to know and debug. OS X's Garbage Collection is an example of why you may want to wait. As one example, the switch could alter when objects are destroyed -- your objects may be destroyed sooner and never be placed in autorelease pools. It could also change the order in which ivars are released, which could have some side effects.

I also have a large codebase that I don't want to lose a week testing this feature for at this time. Finally, backwards compatibility is still important for me.

Will an application using ARC be able to run on older OS versions than iOS 5.0?

If you develop with MRC, it will be backwards compatible. If you develop with ARC, it will not necessarily be compatible. In fact, it may not even compile without a little extra work. The requirements for the runtime are available in some earlier versions. See also this question. If you need backwards compatibility, ARC will not be an option for some OS versions.

Lastly, if you were to limit the choice to GC or ARC, I'd recommend ARC.

Solution 2

you an turn it off/on with CLANG_ENABLE_OBJC_ARC = NO advantage is you have to write less code and memory management is easier. Disadvantage is that you have to scratch everything you learned about memory management :) I prefer turn it off.

Comments

[Thomas K]

There can also be a small performance penalty if you use ARC

[Sulthan]

Really good comment. We discussed migrating our big enterprise project from MRC to ARC but we think it's better to use MRC on big projects or with complicated object models because we have control over it. In most cases, we don't even call retain/release manually. We have retain properties for everything and we autorelease at the time of allocation. But every now and then we find a situation when we need direct control over the memory.

[pchap10k]

Actually ARC is usually faster at runtime, mostly because the optimizer releases objects as soon as it can, and it relies on autorelease pools less.

[Catfish_Man]

It's more complex than that. ARC is both faster and slower, depending on the situation. Typical results are: more retains and releases (slower), less autoreleases (faster, less memory). The only way to know if it's faster or slower for your particular code is to measure.

[Nicolas Miari]

I spent not a week but two days migrating my OpenGL ES-based 2D library and I can tell you... If you access ivars directly all the time (to avoid overhead, and because you know what you're doing), you have lots of delegates spread around for which you forgot to add __unsafe_unretained, etc... You can end up with lots of retain cycles, implementing -dealloc just to add an NSLog to see if an object is deallocated, lots of headaches in my case. Add to that Xcode compatibility issues, bugs in the assistant, failed migrations...

[Nicolas Miari]

For the time being, I will adopt ARC but only for small, UIKit-based projects where I can afford to use self.this self.that all the time and everything fits in Apple's foreseen use cases.