To ARC or not to ARC? What are the pros and cons? [closed]

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 id as a void*. Things like C-arrays of id can take a little more thinking about to do correctly. Fancy handling of ObjC va_args can 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 id in a struct. 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.)

__weak pointers do not work correctly on iOS 4 or Mac OS X 10.6, which is a shame, but fairly easy to work around. __weak pointers 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().

---

Better, more technical answers than mine will come, but here goes:

ARC != garbage collection. There is no run time penalty, it is done at compile time.

ARC also != just auto releasing everything, as you suggest in your comment. Read the docs

It's awesome once you realise how much manual reference management you were doing

Use it!

One drawback - maintaining old, non-arc code suddenly becomes very tedious.

---

How much benefit can ARC bring to a project?

The benefit is a significant degree of protection from common memory management mistakes. Leaks caused by failing to release an object and crashes due to failing to retain or prematurely releasing an object should be significantly decreased. You still need to understand the reference counted memory model so that you can classify your references as strong or weak, avoid retain cycles, and so on.

How much does garbage collection really 'cost'?

There is no garbage collection in iOS. ARC is similar to GC in that you don't have to manually retain or release objects. It's unlike GC in that there's no garbage collector. The retain/release model still applies, it's just that the compiler inserts the appropriate memory management calls into your code for you at compile time.

Have you been using ARC and if so, how have you found it so far?

It's a little disconcerting if you're used to reference counting, but that's just a matter of getting used to it and learning to trust that the compiler really will do the right thing. It feels like a continuation of the change to properties that came with Objective-C 2.0, which was another big step toward simplifying memory management. Without the manual memory management calls, your code becomes a little shorter and easier to read.

The only issue with ARC is that it's not supported in older versions of iOS, so you need to take that into account before you decide to adopt it.

---

I think ARC is a great idea. Compared to GC, you can have your cake and eat it too. I tend to believe that MRC imposes an invaluable 'discipline' towards memory management that everyone would benefit from having. But I also agree that the real issue to be aware of is Object Ownership and Object Graphs (as many have pointed out), and not low-level reference counts per se.

To conclude: ARC is NOT a free pass to be mindless about memory; it is a tool to help humans avoid repetitive tasks, that cause stress and are prone to error, therefore better delegated to a machine (the compiler, in this case).

That said, I'm personally kind of a craftsman and haven't made the transition yet. I just started using Git...

UPDATE: So I migrated my whole game, gl library included, and no problems so far (except with the migration assistant in Xcode 4.2). If you are starting a new project, go for it.

---

I've used it in a couple of (admittedly small) projects, and I have only good experiences, both performance- and reliability wise.

One minor note of caution is that you need to learn the do:s and don't:s of weak references not to cause any reference loops if you're coding your UI by yourself, the designer tends to do a good job of it automatically if you set up your GUI using it.

---

The only downside I have encountered is if you use a library with a lot of CoreFoundation functions and data. In MRC you didn't need to worry about using a CFStringRef instead of an NSString*. In ARC, you have to specify how the two interact (basic bridge? release the CoreFoundation object and move it to ARC? Make a Cocoa object as a +1 CoreFoundation retained object?) Also, on OS X, it's only available on 64-bit code (Although I do have a header that works around that…).

---