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.
