There is no downside. Use it. Do it today. It is faster than your old code. It is safer than your old code. It is easier than your old code. It is not garbage collection. It has no GC runtime overhead. The compiler inserts retains and releases in all the places you should have anyway. But it’s smarter than you and can optimize out the ones that aren’t actually needed (just like it can unroll loops, eliminate temporary variables, inline functions, etc.)
OK, now I will tell you about the small downsides:
-
If you’re a long-time ObjC developer, you will twitch for about a week when you see ARC code. You will very quickly get over this.
-
There are some (very) small complications in bridging to Core Foundation code. There are slightly more complications in dealing with anything that treats an
idas avoid*. Things like C-arrays ofidcan take a little more thinking about to do correctly. Fancy handling of ObjCva_argscan also cause trouble. Most things involving math on an ObjC pointer is trickier. You shouldn’t have much of this in any case. -
You cannot put an
idin astruct. This is fairly rare, but sometimes it’s used to pack data. -
If you did not follow correct KVC naming, and you intermix ARC and non-ARC code, you will have memory problems. ARC uses KVC naming to make decisions about memory management. If it’s all ARC code, then it doesn’t matter because it will do it the same “wrong” on both sides. But if it’s mixed ARC/non-ARC then there’s a mismatch.
-
ARC will leak memory during ObjC exception throws. An ObjC exception should be very close in time to the termination of your program. If you’re catching a significant number of ObjC exceptions, you’re using them incorrectly. This is fixable using
-fobjc-arc-exceptions, but it incurs the penalties discussed below: -
ARC will not leak memory during ObjC or C++ exception throws in ObjC++ code, but this is at the cost of both time and space performance. This is yet another in a long list of reasons to minimize your use of ObjC++.
-
ARC will not work at all on iPhoneOS 3 or Mac OS X 10.5 or earlier. (This precludes me from using ARC in many projects.)
-
__weakpointers do not work correctly on iOS 4 or Mac OS X 10.6, which is a shame, but fairly easy to work around.__weakpointers are great, but they’re not the #1 selling point of ARC.
For 95%+ of code out there, ARC is brilliant and there is no reason at all to avoid it (provided you can handle the OS version restrictions). For non-ARC code, you can pass -fno-objc-arc on a file-by-file basis. Xcode unfortunately makes this much harder than it should be to do in practice. You should probably move non-ARC code into a separate xcodeproj to simplify this.
In conclusion, switch to ARC as soon as you can and never look back.
EDIT
I’ve seen a couple of comments along the lines of “using ARC is no substitute for knowing the Cocoa memory management rules.” This is mostly true, but it’s important to understand why and why not. First, if all of your code uses ARC, and you violate the Three Magic Words all over the place, you’ll still have no problems. Shocking to say, but there you go. ARC might retain some things that you didn’t mean it to retain, but it’ll release them as well, so it’ll never matter. If I were teaching a new class in Cocoa today, I’d probably spend no more than five minutes on the actual memory management rules, and I’d probably only mention the memory management naming rules while discussing KVC naming. With ARC, I believe you could actually become a decent beginning programmer without learning the memory management rules at all.
But you couldn’t become a decent intermediate programmer. You need to know the rules in order to bridge correctly with Core Foundation, and every intermediate programmer needs to deal with CF at some point. And you need to know the rules for mixed-ARC/MRC code. And you need to know the rules when you start messing around with void* pointers to id (which you continue to need to perform KVO correctly). And blocks… well, block memory management is just weird.
So my point is that the underlying memory management is still important, but where I used to spend significant time stating and restating the rules for new programmers, with ARC it is becoming a more advanced topic. I’d rather get new developers thinking in terms of object graphs rather than fill their heads with the underlying calls to objc_retain().