Things You Should Definitely Know as an iOS Developer (Part 1)

In my past years of iOS Development and interviewing different iOS candidates, I have realized that there are certain topics in iOS that everyone should know about. I will like to go through them briefly in this article:

• Memory Management (ARC, how does ARC work?)
• Retain Cycle
• Design patterns being used on an everyday basis
• Different property attributes and how do they work (Objc specific)

Note: I will go through each of the above section in brief, it is possible that I might miss some points as well. The general idea here is to help new iOS developers in the market know what are the things that they should definitely know about before they start iOS Development.

Memory Management

Photo by Fredy Jacob on Unsplash

Everyone in iOS Development would have heard about the term ARC(Automatic Reference Counting). Now let’s try to understand how does this work. Let’s first understand what does reference counting mean. Reference counting is a simple concept where every object is given a count. If you want to keep an object alive, then the reference counter is incremented. If you don’t want to keep the object alive, the reference counter is decremented. Now the word Automatic came along with ARC, where you don’t need to manually maintain the count of objects, iOS will automatically take care of it using some basic conventions. For example, any object starting with “new” means the owner wants to keep a reference to that object and ARC would automatically increment the counter behind the scenes. Before ARC was introduced, one had to manually maintain the count of an object using functions like retain, release.

Takeaway: There are many articles out there on ARC that you can refer to understand in detail. Here is a WWDC video on ARC explaining in detail how it works.

Retain cycle

Retain cycle or strong reference cycle is a term commonly used in iOS to describe a situation where all the objects participating in the cycle keep each other alive and have a strong reference to each other. This situation is also known as a memory leak (Tip: Use leaks instrument provided by XCode to detect such cycles).

In the image above, you can see Object A has a reference to Object C, Object C has a reference to Object B and Object B has a reference to Object A. Assuming all of the references are strong reference, even if all the references to these objects are destroyed this cycle won’t be broken and would be considered as a memory leak. In order to break this cycle one of the references above needs to be a weak reference, this will make sure if all the references to the weak object are gone, then it would automatically be turned to nil.

Design Patterns

Photo by William Felker on Unsplash

Some of the most common design patterns that come to my mind are as follows:

• MVC — Model View Controller is the most commonly used pattern iOS. As the name suggests, it has 3 main parts. The model is responsible for keeping, processing, and manipulating the data. The view is used to represent the model’s data in a UX-friendly fashion. The controller is used for interaction between a model and a view. In iOS, however, the functions of view and controller are performed by a view controller (which then leads to massive view controllers, a totally different topic to discuss :) ). Detailed article by Apple Developer.
• Delegate Pattern — Delegate pattern is also one of the most common patterns used in iOS. The idea is basically to delegate or handover the job of an object to someone else. UICollectionViewDelegate is one of the most common examples of delegate patterns. For example:

// Collection view tells the self object here to perform some tasks on its behalf.
collectionView.delegate = self;

• Notification Pattern — Notification pattern can be used in iOS to broadcast information to all the objects. iOS provides NSNotifications to do the same tasks. You should also know when would you choose the notification pattern over a delegate pattern. Usually, you would delegate pattern for a one-one communication.
• KVO — Key-Value Observing can be used to observe changes in the value of a particular key/property of an object.
• Singelton — Singelton pattern is used to create a global state of an object. Once you create it, it makes sure that you always get back the same instance throughout your app session. It also comes with a disadvantage that you will have objects created throughout the session of your app, so this should be used with caution. The most common way of using a Singelton pattern is as follows:

Property Attributes (Obj-C specific)

• Strong — The strong attribute is used to tell that a declared property has a strong reference and is owned by the object. The value is retained by the object.
• Nonatomic — Nonatomic usually means that no locking is used and hence it's not thread-safe. Multiple threads can access the variable.
• Atomic — Atomic means that its thread-safe and only one thread can access the variable at a time. But this comes with a cost in performance.
• Weak — A weak reference is not owned by an object and the reference count is not increased. When the object holding its reference is destroyed, it is automatically assigned nil value.
• Assign — Assign is similar to weak, the only difference being that it is not nilled out.
• Copy — Copy has a similar owning relationship as strong, the only difference being that the value being passed is copied instead of retaining it.

Check out Part 2 here.