ARC differs from tracing garbage collection in that there is no background process that deallocates the objects asynchronously at runtime.[3] 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.[4]
The following rules are enforced by the compiler when ARC is turned on:
retain, release, retainCount, autorelease or dealloc cannot be sent to objects. Instead, the compiler inserts these messages at compile time automatically, including [super dealloc] when dealloc is overridden.[9]
// Without ARC-(void)dealloc{[[NSNotificationCenterdefaultCenter]removeObserver:self];[superdealloc];}// With ARC-(void)dealloc{[[NSNotificationCenterdefaultCenter]removeObserver:self];// [super dealloc] is called automatically}
Programs cannot cast directly between id and void *.[9] This includes casting between Foundation objects and Core Foundation objects. Programs must use special casts, or calls to special functions, to tell the compiler more information about an object's lifetime.
// Without ARC-(NSString*)giveMeAString{CFStringRefmyString=[selfsomeMethodThatCreatesACFString];NSString*newString=(NSString*)myString;return[newStringautorelease];}// With ARC-(NSString*)giveMeAString{CFStringRefmyString=[selfsomeMethodThatCreatesACFString];// retain count is 1NSString*newString=(__bridge_transferNSString*)myString;// the ownership has now been transferred into ARCreturnnewString;}
An autorelease pool can be used to allocate objects temporarily and retain them in memory until the pool is "drained". Without ARC, an NSAutoreleasePool object can be created for this purpose. ARC uses @autoreleasepool blocks instead, which encapsulate the allocation of the temporary objects and deallocates them when the end of the block is reached.[9]
// Without ARC-(void)loopThroughArray:(NSArray*)array{for(idobjectinarray){NSAutoreleasePool*pool=[[NSAutoreleasePoolalloc]init];// Create a lot of temporary objects[pooldrain];}}// With ARC-(void)loopThroughArray:(NSArray*)array{for(idobjectinarray){@autoreleasepool{// Create a lot of temporary objects}}}
Programs cannot call the functions NSAllocateObject and NSDeallocateObject[9]
Programs cannot use object pointers in C structures (structs)[9]
To properly cooperate with non-ARC code, programs must use no method or declared property (unless explicitly choosing a different getter) that starts with new.[9]
Property declarations
ARC introduces some new property declaration attributes, some of which replace the old attributes.
^ARCLite is ARC but without zeroing weak references (used when deploying to a less-capable operating environment than ARC requires).
Zeroing weak references
Zeroing weak references is a feature in Objective-C ARC that automatically clears (sets to nil) 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 (equivalent to unsafe_unretained in ARC), 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 attributeweak or by using the variable attribute __weak.
Zeroing weak references are only available in Mac OS X Lion (10.7) 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.[9] 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 [1] that allows one to use zeroing weak references even on these older OS versions.
Converting to
Xcode 4.2 or later provides a way to convert code to ARC.[10] 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.
varmyString:String// Can only be a stringvarmyOtherString:String?// Can be a string or nilifletmyString=myOtherString{// Unwrap the Optionalprint(myString)// Print the string, if present}
Accordingly, a strong reference to an object can be of both Optional and non-Optional type (optionality and reference strength are different, albeit related, concepts). A weak reference is always of type Optional, as the object can be deallocated and the reference automatically be set to nil. Unowned references are like weak references but are not set to nil automatically by ARC. They can be either non-Optional or Optional. An unowned reference is expected to always have a value, so accessing the value of an unowned reference after the referenced instance has been deallocated, will result in a runtime error.[11]
varstrongReference:MyClass// Strong non-Optional reference, cannot be nilvarstrongOptionalReference:MyClass?// Strong Optional reference, can be nil (manually)weakvarweakReference:MyClass?// Weak reference, always Optional, can be nil (automatically or manually)unownedvarunownedReference:MyClass// Unowned non-Optional 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 when the program leaves the scope that contains them.[11][12]
^Sakamoto, Kazuki (2012). Pro Multithreading and Memory Management for iOS and OS X with ARC, Grand Central Dispatch and Blocks. Apress. pp. xii. ISBN978-1430241164.