What are the advantages and disadvantages of using

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?

Answer 1

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.

Answer 2

I am using Lion and xcode 4.3. I had the same problem.

To fix it I turned the "Build Settings->Objective-C Automatic Reference Co" to "No".

In order to see that it was set to "Yes" I had to also enable the "All" and "Levels" options on the toolbar that is just below the "Build Settings" toolbar.

Once those options were enabled I could see that my project had that option set to "Yes". It took me a while to figure that out as the default setting was "No", which is what displayed until I enabled the "Levels" option.

Answer 3

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.

Answer 4

You can turn on ARC through "Edit->Refactor->Convert to Objective C Arc", this will refactor your code entirely (get rid of all the memory management calls and such). There is no inverse operation so make sure you've got things under source control if you're having second thoughts. This post shows you how to disable it for specific files. I don't think there is too much argument to be made for not turning to it apart from the fact that it hurts to see all this effort put into good memory management go down the drain and that we will have to stop jumping to the ceiling every time we see init, new, copy without a corresponding release/autorelease (and that will take some getting used to). Perhaps it could be argued that in some circumstances manual memory management results in really noticeable performance/memory footprint improvements, if so I'd also be interested.