Swift Memory Management

Memory Management is an important aspect when it comes to developing an App.

Memory Management in brief

There are 2 ways how an iPhone stores data — 1) The disk 2) RAM (Random Access Memory)

When your application is running a part of RAM is allocated, where all your instances are stored, this part is called the heap. This is the part of the memory which has to be managed. Managing the lifecycle of the objects on the heap and releasing them when they are no longer required.

How does Swift do it?

Swift uses the Automatic Reference Counting (ARC) for memory management. When a new object or instance of a class is created it allocates a chunk of memory for it. Each object has a property called the reference count which keeps a track of properties, objects and values that have a strong reference to it. (Check the link at the end to know more about ARC)

Every time a strong reference is created, the reference count of that object gets incremented by one. And whenever a reference goes out of scope, the reference count gets decremented by one.

class Person {
 var name : String 
 var home: Home?
 
 init(name: String, home: Home?) { 
    self.name = name
    self.home = home
    print("Person initialized")
 }
//called when deinitialized 
deinit { 
   print("Person deinitialised")
 }
}
class Home {
 var name: String
 var owner: Person?
 init(name: String, owner: Person?) {
    self.name = name
    self.owner = owner
    print("Home initialzed")
 }
//called when deinitialized
deinit {
   print("Home deinitialized")
 }
}
var myhome = Home(name: "sample", owner: nil)
var myperson = Person(name: "john", home: nil)
myperson?.home = home
myhome?.person = myperson

Now we have strong references to each other, that is the retain cycle. So the fix for this is making one of the variables weak:

weak var owner: Person?

Weak and Unowned

We can break retain cycles by making use of weak references.

By default, all references in swift are strong and increment the reference count by 1. But weak references don’t affect the reference count.

Also, weak references are always optional variables and when the reference count becomes zero, weak reference gets set to nil. (Voila!)

Just like weak references, unowned references do not impact the reference count of an object. But unlike a weak reference, unowned references are never optional. This means if you try to access an unowned property that points to an object that has already been deallocated, it is like forcefully unwrapping an optional value that is nil.

If you are sure that the object will get deallocated only then use the unowned reference. So does this mean that weak is the optional one and unowned is not and thats the only difference between them? NO.

By reference count, we refer to the strong reference count of the object. Swift maintains an unowned reference count and weak reference count for the object.

Now the weak reference points to something known as a side table rather than the object itself. This is why, when a weak reference goes out of scope the object can be de-initialized and deallocated. Since weak reference doesn’t point to the object at all. When the strong reference count reaches zero, the object gets deallocated, but if the unowned reference count is more than zero, it leaves behind a dangling pointer.

What’s a side table?

A separate chunk of memory that stores the object’s additional information. An object initially doesn’t have a side table entry, it is automatically created when a weak reference is created for the object.

For more about these check the documenation below:

1. https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html
2. https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html

That’s all folks!😊 Drop in your thoughts and suggestions in the comment section.