Yes, ARC is better. Objective-C is a superset of C. If you think about what it means to have a garbage-collected version of C for just a few minutes it should

Yes, ARC is better. Objective-C is a superset of C. If you think about what it means to have a garbage-collected version of C for just a few minutes it should become immediately clear why abandoning GC for Objective-C is necessary and appropriate. The GC can't always reliably detect a reference (pointer) so it has to be conservative. It also can't compact the heap, which means you don't get the nice "allocation is just advancing a pointer" behavior that makes allocations nearly instantaneous in managed languages. ARC is essentially just the old rules for manual reference counting (MRC), but the compiler analyzes your code and inserts the retain/release/autorelease calls automatically. This gives you similar deterministic behavior as MRC but while writing the code it feels like a garbage collected language because you mostly ignore management of memory and everything "just works". The downside to ARC is the inability to detect retain cycles and a slight performance hit compared to MRC in some scenarios. The performance is actually pretty good... What ARC loses compared to hand-coding it gains by using special runtime functions (not slower ObjC message sends) that elide unnecessary retain/release calls in many situations. objc_retainAutoreleaseReturnValue is inserted in a caller and callee (typically a property getter). It examines the return address on the stack to detect if the caller is going to invoke objc_retainAutoreleaseReturnValue on the returned value; if so it just does a retain and sets a flag the caller uses to skip doing retain+autorelease, leaving the caller's release only. Instead of the object staying alive until the next run loop iteration and getting autoreleased it can safely be released immediately, plus at least one extra pair of function calls can be eliminated.