Automatic Reference Counting


Automatic Reference Counting is a memory management feature of the Clang compiler providing automatic reference counting for the Objective-C and Swift programming languages. At compile time, it inserts into the object code messages retain and release which increase and decrease the reference count at run time, marking for deallocation those objects when the number of references to them reaches zero.
ARC differs from tracing garbage collection in that there is no background process that deallocates the objects asynchronously at runtime. Unlike tracing garbage collection, ARC does not handle reference cycles automatically. This means that as long as there are "strong" references to an object, it will not be deallocated. Strong cross-references can accordingly create deadlocks and memory leaks. It is up to the developer to break cycles by using weak references.
Apple Inc. deploys ARC in their operating systems, such as macOS and iOS. Limited support has been available since Snow Leopard and iOS 4, with complete support following in Mac OS X Snow Leopard| Lion and iOS 5. Garbage collection was declared deprecated in Mountain Lion, in favor of ARC, and removed from the Objective-C runtime library in macOS Sierra.

Objective-C

The following rules are enforced by the compiler when ARC is turned on:
// Without ARC
- dealloc
// With ARC
- dealloc

// Without ARC
- giveMeAString
// With ARC
- giveMeAString

// Without ARC
- loopThroughArray:array
// With ARC
- loopThroughArray:array

ARC introduces some new property declaration attributes, some of which replace the old attributes.

Zeroing weak references

Zeroing weak references is a feature in Objective-C ARC that automatically clears weak-reference local variables, instance variables, and declared properties immediately before the object being pointed to starts deallocating. This ensures that the pointer goes to either a valid object or nil, and avoids dangling pointers. Prior to the introduction of this feature, "weak references" referred to references that were not retaining, but were not set to nil when the object they pointed to was deallocated, thus possibly leading to a dangling pointer. The programmer typically had to ensure that all possible weak references to an object were set to nil manually when it was being deallocated. Zeroing weak references obviates the need to do this.
Zeroing weak references are indicated by using the [|declared property attribute] weak or by using the variable attribute __weak.
Zeroing weak references are only available in Mac OS X Lion or later and iOS 5 or later, because they require additional support from the Objective-C runtime. However, some OS X classes do not currently support weak references. Code that uses ARC but needs to support versions of the OS older than those above cannot use zeroing weak references, and therefore must use unsafe_unretained weak references. There exists a third-party library called PLWeakCompatibility that allows one to use zeroing weak references even on these older OS versions.

Converting to

4.2 or later provides a way to convert code to ARC. As of Xcode 4.5, it is found by choosing Edit > Refactor > Convert to Objective-C ARC... Although Xcode will automatically convert most code, some code may have to be converted manually. Xcode will inform the developer when more complex use cases arise, such as when a variable is declared inside an autorelease pool and used outside it or when two objects need to be toll-free bridged with special casts.

Swift

In Swift, references to objects are strong, unless they are declared weak or unowned. Swift requires explicit handling of nil with the Optional type: a value type that can either have a value or be nil. An Optional type must be handled by "unwrapping" it with a conditional statement, allowing safe usage of the value, if present. Conversely, any non-Optional type will always have a value and cannot be nil.

var myString: String // Can only be a string
var myOtherString: String? // Can be a string or nil
if let myString = myOtherString

Accordingly, a strong reference to an object cannot be of type Optional, as the object will be kept in the heap until the reference itself is deallocated. A weak reference is of type Optional, as the object can be deallocated and the reference be set to nil. Unowned references fall in-between; they are neither strong nor of type Optional. Instead, the compiler assumes that the object to which an unowned reference points is not deallocated as long the reference itself remains allocated. This is typically used in situations where the target object itself holds a reference to the object that holds the unowned reference.

var strongReference: MyClass // Strong reference, cannot be nil
weak var weakReference: MyClass? // Weak reference, can be nil
unowned var unownedReference: MyClass // Weak reference, cannot be nil

Swift also differs from Objective-C in its usage and encouragement of value types instead of reference types. Most types in the Swift standard library are value types and they are copied by value, whereas classes and closures are reference types and passed by reference. Because value types are copied when passed around, they are deallocated automatically with the reference that created them.