Advanced iOS developer interview questions and answers

CoreData is used as a framework for managing object graphs. It helps manage a graph of object instances that is potentially very large. This allows the app to use a graph that would not completely fit in the memory, by bringing objects in and out of the memory when needed. CoreData also helps in managing the limitations on properties and relationships and in maintaining the integrity of references. This means that when objects are added to or removed from a relationship, the forward and backward links remain consistent. Therefore, CoreData is considered to be the perfect framework for creating the “model” of an MVC architecture.

CoreData uses SQLite for disk storage to implement graph management. It is possible to implement graph management using some other relational database or even a non-relational database like CouchDB. CoreData is more of an API that abstracts from the actual datastore than a database engine. Therefore you can tell how CoreData must store itself - as a plist, an SQLite database, a binary file, or a custom data store type.

Giving a detailed answer to an iOS interview question like this is good, but your answer can become great if you can add your perspective as well to the answer.

Generally, retaining an object increases its retain count by one. This helps retain the object in memory instead of being blown away. Therefore, if you only have the retained version of an object, you will share that copy of the same with whoever sent it to you.

Copying an object, on the other hand, creates an extra copy or a duplicate version of the object. While you share the original with the person who sent the object to you, you do not share the copied or duplicate version with the sender.

A signed application helps the system to know who signed the application and also to determine that no changes were made to the application after it was signed. This is a necessary step to submit the application to the App Store for iOS and Mac. There is a signature verification process in OS X and iOS to confirm that the applications do not run with invalid signatures. This builds trust for the users who know that the application is signed by a verified Apple Source and no changes were made to it since signing.

During the build process, your digital identity is used by Xcode to sign your application. The digital identity comprises a public-private key pair and a certificate. The cryptographic functions use the private key to create the signature. Apple issues the certificate that contains the public key and helps identify you as the key pair owner.

The signature protects the executable code of the application because as soon as the executable code in the application changes even slightly, the signature becomes invalid. However, changes to images or nib files do not invalidate the signatures as these resources are not signed.

The signature of an application can be removed and a different digital identity can be used to re-sign the application. For example, all applications on App Store are re-signed by Apple when they are sold.

For an iOS interview question of this type, it may be good to add if you have any prior experience of a project with similar requirements, code-signing for iOS apps in this case.

There are five app states in iOS. While the app state is managed by the OS, the important tasks are managed by the app itself so that transitions between states happen smoothly. The iOS programming guide lists the five iOS app states as follows:

• Non-running - When the app is not in the running state.
• Inactive - When the app runs in the foreground but does not receive any events. This can happen with an iOS app when a call or SMS is received or some other function takes precedence.
• Active - This is the state when the app runs in the foreground and receives events.
• Background - When the app runs in the background and executes code at the same time.
• Suspended - When the app runs in the background but does not execute any code at that time.

iOS interview questions like the above where you need to talk about multiple states or steps are popular in iOS interviews

The main features of Swift are as follows:

• Generics
• Optionals
• Reference types
• Value types
• Static typing
• Protocols

The biggest feature of Swift is that it is a strongly-typed language. Being a strongly-typed language is an advantage as well as a disadvantage. Development in Swift is easy because of protocols, generics, and optionals which exist because of static typing. While static timing throws several compilation errors and compile-time warnings, it also offers more security at runtime and helps in determinism for optionals, generics, etc. This is, therefore, a big advantage of Swift. The security offered by strict type is most useful under the following circumstances:

• When creating a client application requires more strict clarity than flexibility and dynamism
• When you don’t want inexperienced developers to have excessive power and cause damage to themselves or their work and thus, need to add restrictions
• When your code needs refactoring and using the compiler can help in writing proper and correct code

All the above are scenariOS where developers build customer-facing iOS applications. The disadvantage of Swift is that it can be too restrictive, especially when the app you are building needs flexibility. For example, when you build a library or a framework, it needs to be flexible and dynamic. In such a case, Objective-C which offers meta-programming capabilities can be a better choice than Swift, though presently, Objective-C seems to be going obsolete.

MVC stands for Model View Controller. It is Apple’s main software design pattern for developing iOS apps. Models represent the data for the application. Views bring things to the screen. Controllers are used to manage the flow of data between model and view. There is no direct communication between model and view, all communication is taken care of by the controller.

As a senior developer, one must know that while MVC is good for general-purpose design, it can be used only for the view layer. Therefore, using only MVC will restrict the architecture of the application and could also lead to the “Massive View Controller” problem.

Massive View Controller refers to that state of the codebase when excessive logic and responsibility are given to View Controllers that are not supposed to shoulder that responsibility. As a result, the code may become rigid, bloated, and difficult to alter. As a remedy, one can use design patterns such as Coordinator, MVP, and MVVM. For scaling the iOS code and avoiding this type of problem, architectures like VIPER and RIBs can be used.

Both, delegate and KVO, create relationships between objects. Delegation creates a one-to-one relationship in which the delegate protocol is implemented by one object, and the other object uses protocol-defined methods to send messages to the first object. KVO, on the other hand, creates a many-to-many relationship in which the message is broadcast by one object, and one or more objects receive the message and react to it. KVO is not protocol-dependent.

When preparing for your iOS interview, ensure that you go through all such concepts where you could be asked to differentiate between two things.

Apart from MVC, Singleton, Observer, and Delegate patterns that are commonly used, there are other patterns too that could be used for developing iOS applications:

• Factory Method: With the Factory Method, one can replace class constructors for abstracting and hiding initialization of objects so that the type is determined when the application is run. This method also helps to hide and contain the switch/if statements that help identify which objects to create instances for.
• Adapter: With the help of the Adapter design pattern one can adapt one object’s interface to that of the other. It is useful when a third-party code cannot be changed to one’s own code or when something with an inconvenient or incompatible API needs to be used.
• Decorator: The Decorator is a wrapper that can be wrapped around different classes to enhance their capabilities. One can wrap it around things one wants to decorate. Once wrapped, it implements the interface and delegates the messages that were sent to it to the underlying objects, or it changes and improves objects or gives its own implementation to them.
• Command: The Command design pattern allows you to implement an object representing an operation that you want to perform. The operation you want to execute may have its own state and logic for performing the task. As an advantage, you can hide the operation’s internal implementation from the users, add undo/redo capabilities to it, and even execute operations later instead of at the time of operation creation.
• Template: The Template design pattern has a base class outlining the algorithm for what is required to be done. There are several abstract methods of the base class. These abstract methods must be implemented by the concrete subclasses of the base class. These abstract methods are also referred to as hook methods. The interaction of the Template Method class users happens through the base class that implements the algorithm steps. The subclasses supply the concrete implementations for those steps.

Outlined below are the ways to store data in simple to complex order:

• For intermediate data storage or for storage that doesn’t need to last long, we can use in-memory arrays, dictionaries, sets, and other data structures.
• For simple key-value storage, we can use NSUserDefaults/Keychain. Here, one thing is insecure, and the other is secure, respectively.
• For writing data to or from a disk, we can take the help of NSFileManager, whether the data is serialized or not, we can use File or Disk storage.
• When trying to simplify working with databases, frameworks like Core Data and Realm are useful.
• When your requirements include implementing complex querying mechanics, the SQLite relational database is what you should use.

The above iOS interview question is an example of questions where you can use the traditional answer outline above and be safe, but if you add examples of having implemented each or any of the options above, you may earn the interviewer’s attention.

When you work with Structs or Enums, ARC doesn’t manage these memory types. Thus, there isn’t any need to worry about specifying whether you are using weak or unowned references for the constants or variables there. In hierarchical relationships, where the parent references the child but the reverse does not occur, you can use strong references. In most cases, anyway, strong references are apt. However, where the relationship of two instances is optional, you must ensure that one instance is weakly referenced to the other.
When one instance is linked to another in a way that it cannot exist in the other’s absence, there is a mandatory dependency of one variable on the other. In such a case, the instance that has mandatory dependence on the other must hold an unowned reference to the other.