Open Nuts and Bolts of Memory Management in iOS : Swift Part 2

Photo by Tekton on Unsplash

Continuing part 1, we have few more things to bath into. I recommend you to read Part 1 first if you haven’t, so that you can get full insight.

Strong, Weak and Unowned in terms of memory

Default type of reference in Swift is strong, that is needed to keep an object alive. It keeps a firm hold on the instance and does not allow it to be deallocated for as long as that strong reference remains.

class Student {
    var name: String
    var dept: Department
    init(name: String, dept: Department) {
        self.name = name
        self.dept = dept
    }
}
class Department {
     var faculty: String
     var id: String
     init(faculty: String, id: String){
        self.faculty = faculty
        self.id = id
     }
}

In above example, Student holds strong reference to Department.

var dept1 = Department(faculty: "Maths", id: "101")
var student1 = Student(name: "Varun", dept: dept1) //ref count = 1
var student2 = student1 // ref count = 2
var student3 = student2 // ref count = 3
student2 = nil // ref count = 2
student1 = nil // ref count = 1
student3 = nil // ref count = 0, now memory would get free

It is worth noting that objects in Swift conceptually have several counters: strong, weak, and unowned references. These counters are stored either inline or in a side table. We will understand side table later in this article. Here is a Student class with two properties. The next image represents “student1” object in memory. Let’s say we have only single strong reference to it as shown below :

Want to read this story later? Save it in Journal.

Now suppose a student1 is also referred by one weak reference.After some time, a strong counter comes to zero while the weak count is still non-zero, as shown in image below:

As strong reference is 0, the object is tried to be deleted from memory by ARC. Despite this fact causes the object’s deinitialisation, its memory is not deallocated as weak counter remains there. This weak reference only get decremented when another object accesses the destroyed student1 by a weak reference. When a weak counter reaches zero, memory is finally deallocated. It means that our student1 becomes a zombie object that may occupy memory for a long time.

Important Note : The above mentioned behaviour of weak references is before Swift 4. Swift 4 onwards things get changed and new concept of side table is introduced. Let’s discuss how weak reference behaves now using side table.

Weak Reference Side Table diagram

Side table holds additional information for object. Initially an object doesn’t have a side table, it only created when the object is pointed by weak reference. Both the object and side table have a pointer to each other. Another important thing is that weak references now point directly to the Side Table, whereas strong and unowned ones still point directly to the object. This allows the object’s memory to be fully deallocated. This Side Table approach make things better than the approach followed prior Swift 4.

Weak references point to Side Table, which in turn points to the object, this makes weak reference safely zero out, since it does not directly point to an object, it is no longer subject to any race conditions.

On the other hand, Unowned and Strong references point directly to an object.

One more important thing left for this article is “strong reference cycle” 🚵 . If explained here, this article may get stretched. Retain cycle is very well explained in Swift Docs. I suggest you to please go through this here.

Thanks for reading this🙏🙏. Any feedback in the comment section would be appreciated. If you enjoyed reading this post, please share and give some claps.

You can follow me for fresh articles.

📝 Save this story in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.