Memory Management – MRC vs ARC

Before diving into Memory Management, we need to know the basic definatioon

1) Value and Reference Types

Types in Swift fall into one of two categories:

1) “Value Types” -> where Each instance keeps a unique copy of its data. Usually defined by

  • structs (incl. arrays and dictionaries)
  • enumerations
  • tuple
  • basic data types (boolean, integer, float, etc.)

2) “Reference Types” -> where Instances share a single copy of the data, and the type is usually defined as a class.

Now we will explore the merits of value and reference types, and how to choose between them.

What’s the Difference?

Value Type  -> The most basic distinguishing feature of a Value Type is that copying — the effect of assignment, initialization, and argument passing — creates an independent instance with its own unique copy of its data:

// Value type example
struct S { 
      var data: Int = -1
var a = S()
var b = a				// a is copied to b = 42				// Changes a, not b
println("\(, \(")	// prints "42, -1" 
Reference Type -> Copying a reference, on the other hand, implicitly creates a shared instance. After a copy, two variables then refer to a single instance of the data, so modifying data in the second variable also affects the original, e.g.:
// Reference type example
class C { 
    var data: Int = -1 
var x = C()
var y = x		// x is copied to y = 42		// changes the instance referred to by x (and y)
println("\(, \(")	// prints "42, 42"

So use a value type when:

  • Comparing instance data with == makes sense
  • You want copies to have independent state
  • The data will be used in code across multiple threads

Use a reference type (e.g. use a class) when:

  • Comparing instance identity with === makes sense
  • You want to create shared, mutable state

2) Difference between Strong and weak in IOS


Anytime a pointer variable stores the address of an object, that object is a owner and will stay alive. This is known as a Strong reference. So it means that you want to “own” the object. Only when you set the property to nil will the object be  destroyed.

Why we use Strong

  1. Creates ownership between property and assigned value.
  2. This is default for object property in ARC.
    Weak : A variable can optionally not take ownership of an object it points to. A variable that does not take ownership of an object is known as a weak reference.

    So a Weak property means you don’t want to have control over the objects lifecycle. The object only lives on while another objects has a strong reference to it. If there are no strong references to the object then it will be destroyed. The most common scenario for a weak property is for subviews of a view controllers view. Because these subviews are already strongly held by the view controllers view.

    Why we use Weak

    1. Creates non-ownerships between property and assigned value.
    2. Strong is used on parent object and weak is used on child object when parent is released then child object reference is also set to nil
    3. It helps to prevents retain cycles.
    4. Weak is essentially assigned, unretain property.                                                                                                                                                                                                                                                                                                                                                                                                                                        A weak reference is useful for an unusual situation called a retain cycle. A retain cycle occurs when two or more objects have strong references to each other. This is bad news. When two objects own each other, they will never be destroyed by ARC. Even if every other object in the application releases ownership of these objects, these objects (and any objects that they own) will continue to exist by virtue of those two strong references.Thus, a retain cycle is a memory leak that ARC needs your help to fix. You fix it by making one of the references weak.


Now, How Manual Memory Management works in Objective C?

We will cover explanation of: retain, release, autorelease, alloc, dealloc, copy, and NSAutoreleasePool.

You can mostly avoid Manual Reference Counting(MRC) by turning on Automatic Reference Counting (ARC) or garbage collection.Its up to you, but Apple pushes developers to use ARC.

We will be covering:

  • Coming From C/C++ ->  In C/C++, you can create objects as local (a.k.a stack-allocated) variables, where allocation and deallocation is handled for you automatically. You don’t have this luxury in Objective-C. In Objective-C all objects are allocated on the heap. It is the equivalent of always using new to create objects in C++. As a result, all object variables are pointers.                                                                                                                                    In C++, an allocated bit of memory usually has a single owner. The owner deallocates the memory when appropriate. This is also slightly different in Objective-C. Objects can have multiple owners by default. You can’t say “deallocate this now.” Instead, you say “I’m not using this anymore” and the deallocation of an object happens automatically once all owners have said they are no longer using the object.
  • Coming From a Garbage Collected Language (Java, Python, C#, etc.) ->  In a garbage collected language, you create new objects whenever you want. Then, when you’re finished with the objects you just stop using them and forget about them. The garbage collector will magically come along and free up the memory that the objects were occupying. This is not so, in Objective-C.                                                                                                                                        In Objective-C, when you create a new object you are responsible for freeing up (a.k.a. deallocating) the memory once you’re done with it. If you forget this, then the object stays in memory until the program exits. This is called a memory leak. If you keep leaking memory, you will see that the program will crash.                                                                                                                                                                                                             Conversely, you also have to be careful that you don’t use an object that has been deallocated. If an object gets deallocated, but if you still points a variable pointing to that object, your app will crash. This is called a dangling pointer.
  • What Is Reference Counting? -> Every object in Objective-C uses reference counting to manage its lifecycle.Reference counting allows a single object to have multiple “owners”, and ensures that the object will stay alive as long as there is at least one owner. Once the last owner is gone, the object deallocates itself.Reference counting is very simple, and works like this:
    • Every object has a “reference count”, which is just an integer.
    • The reference count starts with 1 when the object is created, and whoever created the object automatically has ownership of it.
    • If you want to take ownership of an object, you increase the reference count of the object by one.
    • When you release ownership of an object because you don’t need it any more, you decrease the reference count by one.
    • When the reference count of an object reaches zero that means nobody is using it, so it is safe to be deallocated.Let’s look at an example of correct usage, using a reference counted television object.
      Action Change Reference Count
      Jerry wants to watch Seinfeld, so he creates a TV object. Creating the object makes him the only owner. 1
      Elaine wants to watch the same TV object as Jerry, so she also takes ownership of the object. +1 2
      Jerry gets bored of the Seinfeld episode he is watching and decides to leave, so he releases ownership of the TV object. -1 1
      The episode of Seinfeld finishes, so Elaine releases ownership of the TV object and leaves. -1 0

      Now let’s look at an incorrect usage, which causes a memory leak:

      Action Change Reference Count
      Ned wants to watch Game of Thrones, so he creates a TV object. Creating the object makes him the only owner. 1
      Joffrey wants to watch the TV with Ned, so he also takes ownership. +1 2
      Joffrey beheads Ned. 2
      Joffrey leaves, and releases ownership of the object. -1 1
      The TV object is never deallocated because the reference count will stay at one forever. 1

      This memory leak occurs because Ned forgot to release ownership of the object before he was beheaded.

      Now let’s look at another incorrect usage that causes a dangling pointer:

      Action Change Reference Count
      Simon wants to watch Grandma’s House, so he creates a TV object. Creating the object makes him the only owner. 1
      Adam starts watching too, but doesn’t bother taking ownership. 1
      Simon releases ownership and leaves. -1 0
      The reference count has hit zero, so the TV object deallocates itself.
      Adam tries to keep watching, but the TV object is gone so the universe explodes.
  • How Does Reference Counting Work In Objective-C?  ->  Memory management in Objective-C involves four basic rules. If you follow these rules, then you will not leak memory or cause dangling pointers.  

    Rule 1. If you create an object using a method that starts with “alloc”, “copy” or “new”, then you own it.

    This is where you have created a new object with a retain count of one, which automatically makes you the owner.


    NSString* iOwnThis1 = [[NSString alloc] initWithString:@"hello"];
    NSString* iOwnThis2 = [someOtherString copy];
    NSMutableString* iOwnThis3 = [someOtherString mutableCopy];
    NSString* iOwnThis4 = [NSString new];
    [iOwnThis1 release];
    [iOwnThis2 release];
    [iOwnThis3 release];
    [iOwnThis4 release];


    Rule 2. If you retain an object, then you own it.

    This is where you call retain on an object, which increases the retain count by one.


    [donkey retain];
    [eagle retain];
    [eagle retain];
    [eagle retain];
    [donkey release];
    [eagle release];
    [eagle release];
    [eagle release];

    Note that you can take ownership of an object more than once. If you own the object three times, then you have to release it three times.

    Rule 3. If you own it, you must release it.

    This is where you call the release method on an object, which decreases the retain count by one. When you call release and the retain count reaches zero, the object will deallocate itself by calling dealloc. This means you should never call dealloc directly. Just release the object correctly, and it will handle everything itself.


    NSString* iMadeThis = [[NSString alloc] init]; // Rule 1
    [iMadeThis release];
    [imSharingThis retain]; // Rule 2
    [imSharingThis release];
    //can own the same object many times
    Pidgeon* pidgeon = [[Pidgeon alloc] init]; // Rule 1
    [pidgeon retain]; // Rule 2
    [pidgeon release];
    [pidgeon release];


    Rule 4. If you keep a pointer to an object, then you must own the object (with some rare exceptions).

    Basically, if you own an object, then you know it is definitely safe to use. If you don’t own it, then it is sometimes safe to use temporarily (discussed in the autorelease section). If you want to keep an object to use later, such as storing it in an ivar or a global, you must retain it. Otherwise, it might be deallocated and you will be left with a dangling pointer.

    One exception is the use of strings you type directly into the code (string literals). String literals are never deallocated, and retain and release don’t do anything to them.

  • NSAutoreleasePool And autorelease
  • Common Mistakes

So Apple developers had to manually manage memory while writing Objective-C code called the Manual Retain-Release model, and is exactly what developers have been doing all this while for C/C++.
But managing memory manually has always been painful and error prone, and takes up valuable time of application developers, which could instead be used for building useful features.

Enter ARC, acronym for Automatic Reference Counting.

Apple introduced ARC in 2011 along with Max OS X Lion and iOS 5.

With ARC, Apple has tried to make the compiler mimic what disciplined C/C++ developers would do. They would manually track the memory they are allocating for their code, and then ensure they release that memory whenever the objects go out of scope, and their memory is no longer required. So instead of the developers, now the compiler is doing all the hard work.

Its not like ARC was entirely Apple’s creation, Reference Counting has been around for a long time, and is one technique of implementing Garbage Collection.

How is ARC different from a Garbage Collector?

Garbage Collector:

— Is part of the runtime infrastructure – i.e. part of CLR, JVM, and the runtime is responsible for running and monitoring the Garbage Collector (GC)

— Is indeterministic, so objects stick around until the GC runs, and therefore are not released as soon as they go out of scope

— Affects application performance when it runs, as other threads are paused, while it is runnning

— Is able to clear entire Object graphs, as it is able to figure out the application root object references while the application is running

— Is less prone to memory leaks



— It is not part of the runtime

— Instead the compiler injects reference tracking and clean-up code, similar to what a developer would do

— Deterministic reclamation of memory, at the time when the object goes out of scope

— Since there is no background or runtime processing, it requires less CPU and RAM, making it efficient on mobile devices

— Cannot cope with retain cycles/object graphs – gets stuck with an object graph, whereas a GC would look for an external reference to an object graph, and if not found would clear up the entire object graph

— Is more prone to memory leaks based on the quality of code written


Retain Cycles

A Retain Cycle is created when two or more objects are referencing each other in a circular fashion. For e.g. when we have a Parent – Child relationship between two objects, both instances would be referencing each other until they both go out of scope. This creates a circular reference and ARC is not able to figure out when to release these objects as it does not do a stack walk which a GC would do to find external references to these objects, instead ARC just tracks the count of the references to a particular object.

To solve this issue, Apple came out with Strong and Weak references. The Parent object creates a Strong reference to the Child object, which means that until the Parent object is deallocated, the Child object needs to remain alive. And the Child object creates a Weak reference to the Parent object, which breaks the circular reference cycle, and now the Parent object can be cleared whenever it goes out of scope, which in turn will also clear the Child object.

However, for the scenario above, developers need to handle missing or nil Parent objects in the Child object implementation, for when the Parent object gets deallocated and before the Child object is cleared, Child object code might be executed.


There is a concept of unowned references as well to prevent retain cycles, which I left out for now.

LLVM and Clang

Apple has used the LLVM compiler toolset to implement ARC.
“The LLVM Project is a collection of modular and reusable compiler and toolchain technologies”

The aim of LLVM is to provide a common backend compiler infrastructure to different compiler front-ends for different languages.

At a high level LLVM accepts code in an Intermediate Form and then is able to emit machine code based on the target architecture.
Ultimately we should be able to write code in different programming languages, run it through LLVM to generate native code for different platforms.


Apple developed the Clang frontend for C, C++, Objective-C and now Swift to use with LLVM. Clang is where the ARC magic happens.

Earlier Apple was using the GCC compiler for Objective-C and XCode, however as GCC is old and has a massive codebase to allow easy addition of new features and advancement, Apple decided to switch to the LLVM toolset. GCC also uses the GPL license, which would have forced Apple to GPL XCode’s source whereas LLVM uses the more lenient BSD license to protect proprietary software.

The modular nature of LLVM has helped Apple create Swift, implement ARC, improve XCode to easily target different platforms like Mac OS X and iOS. Seems they are also using components of LLVM to optimise Javascript bytecode in the WebKit browser engine.

This was a short introduction to how iOS uses ARC to manage its memory, and about the tools that are used for ARC, do send in your feedback via comments. In future, I am planning to write a post on the tools which are available with XCode, which help diagnose memory related issues.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s