iOS Interview Questions for Senior
Developers in 2020

TLDR: main Swift features - static typing, protocols, reference types, value types, optionals, generics.

Swift is a strongly typed language, which might be its biggest feature, advantage and disadvantage at the same time. Static typing allows protocols, generics, and optionals to exist and aids you in development. Static typing gives you a lot of compile-time warnings and compilation errors, but provides greater runtime safety and determinism (optionals, var/let, generic or concrete types, etc.). This is one of the biggest advantages that the language provides. It is the most helpful to have strict type safety in the following scenarios:

• when you’re building a client application and you need more strict explicitness rather than dynamism and flexibility
• when you’re working in an environment where you want to restrict less experienced developers (beginners and juniors) from having too much power and shooting themselves in the foot
• when you need to refactor your code and the compiler serves as an aid to writing your code properly and correctly

All of those happen to be the majority of customer facing applications iOS developers build.

At the same time static typing could be too restrictive when you’re building something that requires more flexibility such as building a library or a framework. Objective-C could be a better choice in that regard as it allows better meta-programming capabilities than Swift. (Although arguably at this point Objective-C becoming obsolete and all the development for Apple platforms should be done in Swift)

We might think the apps we build are something special because they cover a unique use case. But your typical iOS application is just a giant, glorified run loop. It waits for user input and gets interrupted by external signals such as phone calls, push notifications, home gestures/button presses, and other app life cycle events. The only difference is that instead of being just a simple main loop function that gets launched every time the user taps on your app icon, it has a higher level of abstraction, UIApplication, AppDelegate, and SceneDelegate that developers work with.

The rest of the code you write to implement the business logic of your app is placed somewhere in the “trigger points” delegated by that main loop to our app via AppDelegate or SceneDelegate. Before iOS 13 AppDelegate was responsible for receiving all external events for your application and spinning up the UI; but starting with iOS 13 all UI-related logic was moved to SceneDelegate.

That’s it. Simple. The code you write for your app can be as simple as a method/function call, or as complex as VIPER architecture. It’s your choice.

Swift uses Automatic Reference Counting (ARC). This is conceptually the same thing in Swift as it is in Objective-C. ARC keeps track of strong references to instances of classes and increases or decreases their reference count accordingly when you assign or unassign instances of classes (reference types) to constants, properties, and variables. It deallocates memory used by objects whose reference count dropped to zero. ARC does not increase or decrease the reference count of value types because, when assigned, these are copied. By default, if you don’t specify otherwise, all the references will be strong references.

MVC stands for Model View Controller. It is a software design pattern Apple chose as the main approach to iOS application development. Models represent application data; views draw things on the screen; controllers manage data flow between model and view. Model and view never communicate with each other directly and rely on a controller to coordinate the communication. This design pattern is morphed by Apple into something else from its original SmallTalk implementation.

A typical representation of each Apple MVC layer in an iOS application would be:

• UIView subclasses (Cocoa Touch or custom) are views
• UIViewControllers and their subclasses are controllers
• any data objects, NSManagedObject subclasses and similar are models

MVC is a great general purpose design pattern, but as a senior developer you should know that it is just a design pattern for the view layer and using it alone limits your architecture and often leads to the notorious “Massive View Controller” problem.

Massive View Controller is the state of a codebase where a lot of logic and responsibility was shoved into View Controllers that doesn’t belong there. That practice makes your code rigid, bloated, and hard to change. There are other design patterns that can help you remedy this, such as MVVM, MVP, and Coordinator. And there are archictures such as VIPER and RIBs that were made specifically for the purpose of scaling iOS code and avoiding Massive View Controller problem.

Even though Apple keeps telling us that MVC is everything, know better and stick to SOLID principles.

Singleton is a class that returns only one and the same instance no matter how many times you request it.

Singletons are sometimes considered to be an anti-pattern. There are multiple disadvantages to using singletons. The main ones are global state, object life-cycle, and dependency injection. When you have only one instance of something, it’s very tempting to reference and use it everywhere directly instead of injecting it into your objects. That leads to unnecessary coupling of concrete implementation in your code instead of working with an interface abstraction.

Another malicious side effect of “convenient” singletons is the global state. Often singletons enable global state sharing and play the role of a “public bag” that every object uses to store state. That leads to unpredictable results and bugs or crashes when this uncontrolled state gets overridden or removed by someone.

Both are ways to have relationships between objects. Delegation is a one-to-one relationship where one object implements a delegate protocol; another sends messages to it, using methods defined by the protocol. KVO is a many-to-many relationship where one object broadcasts a message, and one or more other objects listen to it and react. KVO does not rely on protocols. KVO is the first step and the fundamental block of reactive programming (RxSwift, ReactiveCocoa, etc.)

Typical commonly used patterns when building iOS applications are those that Apple advocates in their Cocoa, Cocoa Touch, Objective-C, and Swift documentation. These are the patterns that every iOS developer learns. Apple refers to them as “core competencies” design patterns. They include MVC, Singleton, Delegate, and Observer.

Besides commonly used MVC, Singleton, Delegate, and Observer patterns, there are many others that are perfectly applicable in iOS applications: Factory Method, Adapter,Decorator, Command, and Template.

Factory Method is used to replace class constructors, to abstract and hide objects initialization so that the type can be determined at runtime, and to hide and contain switch/if statements that determine the type of object to be instantiated.

Adapter is a design pattern that helps you, as the name suggests, adapt the interface of one object to the interface of another. This pattern is often used when you try to adapt third-party code that you can’t change to your code, or when you need to use something that has an inconvenient or incompatible API.

Decorator is a wrapper around another class that enhances its capabilities. It wraps around something that you want to decorate, implements its interface, and delegates messages sent to it to the underlying object or enhances them or provides its own implementation.

Command is a design pattern where you’d implement an object that represents an operation that you would like to execute. That operation can have its own state and logic to perform the task it does. The main advantages of this design pattern are that you can hide internal implementation of the operation from the users, you can add undo/redo capabilities to it, and you can execute operations at a later point in time (or not at all) instead of right away where the operation was created.

Template is a design pattern where the main concept is to have a base class that outlines the algorithm of what needs to be done. The base class has several abstract methods that are required to be implemented by its concrete subclasses. These methods are called hook methods. Users of the Template Method classes only interact using the base class that implements the algorithm steps; concrete implementations of those steps are supplied by subclasses.

SOLID stands for Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. These principles feed into and support each other and are one of the best general design approaches you could take for your code. Let’s go through each of them.

The Single Responsibility Principle (SRP) is the most important principle of the group. It states that every module should have only one responsibility and reason to change. SRP starts with small concrete and specific cases such as a class and/or an object having only one purpose and being used only for only one thing.

The Open/Closed Principle (OCP) states that your modules should be open for extension but closed for modification. It’s one of those things that sounds easy enough but is kind of hard to wrap your head around when you start to think about what it means. Effectively it means that when writing your code you should be able to extend the behavior of your objects through inheritance, polymorphism, and composition by implementing them using interfaces, abstractions, and dependency injection.

The Liskov Substitution Principle (LSP) states that objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. What that means is that when you inherit from a class or an abstract class or implement an interface (protocol), your objects should be replaceable and injectable wherever that interface or class that you subclassed from was used. This principle is often referred to as design by contract or, as of late in the Swift community, referred to as protocol-oriented programming. The main message of this principle is that you should not violate the contract that your interfaces you subclass from promise to fulfill, and that by subclassing, those subclasses could be used anywhere that the superclass was previously used.

The Interface Segregation Principle (ISP) says many client-specific interfaces are better than one general-purpose interface. It also states that no client should be forced to depend on and implemented methods it does not use. What that means is that when you create interfaces (protocols) that your classes implement, you should strive for and depend on abstraction over specificity, but not until it becomes a waste where you have to implement a bunch of methods your new class doesn’t even use.

The Dependency Inversion Principle (DIP) states, “depend on abstractions, not concretions.” The best example that showcases this principle is the Dependency Injection (DI) technique. With the Dependency Injection technique, when you create an object, you supply and inject all of its dependencies upon its initialization or configuration rather than let the object create or fetch/find its dependencies for itself.

In-memory arrays, dictionaries, sets, and other data structures are perfectly fine for storing data intermediately or if it doesn’t have to be persisted.

NSUserDefaults/Keychain are simple key-value stores. One is insecure and the other is secure, respectively.

File/disk storage is a way of writing data (serialized or not) to/from a disk using NSFileManager.

Core Data and Realm are frameworks that simplify work with databases.

SQLite is a relational database and is good when you need to implement complex querying mechanics and Core Data or Realm won’t cut it.

In iOS there are several options to implement HTTP networking. You can go with good old NSURLSession, but unless you abstract it out well enough, it can be daunting to work with. Another option would be to use a wrapper library around it. The most popular solution on iOS is Alamofire.

In general, if you have a small team you likely want to rely on open sourced solutions such as Alamofire that abstract a lot of boilerplate code out for you; but if you’re in a big team and can spare resources you’d want have more control over how data is passed to/from your server and implement it yourself using NSURLSession.

Senior developers should keep in mind that building the networking layer in iOS applications means not only dealing with HTTP requests but implementing the whole set of tasks your code does related to that: HTTP networking, data serialization, and data mapping.

There are two most common scenarios where you’d need to serialize and map data in iOS applications: receiving or sending data in the networking layer (such as JSON or XML or something else), and persisting or retrieving models in the storage layer (NSData, NSManagedObject).

Every time you receive JSON or XML or any other response type of response from a backend API, you most likely get it in a JSON or binary or other “inconvenient” format. The first thing you need to do to work with the data you’ve received is to serialize it in something your app understands. At the most simplest and basic level that would be a dictionary or an array of objects containing other dictionaries, arrays, and primitives from that response. NSJSONSerialization takes care of that. The next step is to map that data into domain models of your application. Those would be the model objects or structs for the rest of your application to use. You can either do it manually or use Codable protocol provided by Apple or use a library such as Mantle or SwiftyJSON. The flow of data and serialization/mapping is: binary data -> json -> NSDictionary/NSArray -> your domain model objects.

Similarly, in the storage layer, you will need to serialize and map your data to and from your custom domain model objects to the format your storage understands. The “mapping” chain for reading data: db -> raw data format -> custom domain models; and for writing: custom domain models -> raw data format -> db. You’d use the NSManagedObject or NSCoding or Codable protocol here to achieve that.

Go-to options for laying out views on the screen are good old CGRect Frames and AutoLayout. Frames, along with auto-resizing masks, were used in the past before iOS 6 and are not a preferred option today. Frames are too error-prone and difficult to use because it’s hard to calculate precise coordinates and view sizes for various devices.

Since iOS 6 we have AutoLayout, which is the go-to solution these days and which Apple prefers. AutoLayout is a technology that helps you define relationships between views, called constraints, in a declarative way, letting the framework calculate precise frames and positions of UI elements instead.

With iOS 13, Apple introduced a new approach for laying out views - SwiftUI, which is a declarative approach that supports FRP (functional-reactive programming) data bindings with Combine. FRP and declarative UI are not new concepts, but SwiftUI and Combine are new frameworks from Apple that support it. The declarative nature of SwiftUI allows you to declare your UI elements very concisely and then later through data bindings declare what parts of the UI, such as text labels for example, to update upon what data model changes. In effect, it allows you to do what was already possible with RxSwift before, but now with Apple frameworks.

There are other options for laying out views, such as ASDK (Texture), ComponentKit, and LayoutKit, and some of them are more or less inspired by React and others solve layout Asynchronicity differently. These alternatives are good in certain scenarios when, for example, you need to build highly dynamic and fast table views and collection views. AutoLayout is not always perfect for that and knowing there are other options is always good.

NOTE: we’ll see how SwiftUI proves itself solving complex UI problems and complex async UI layout problems in the future, it’s a very new technology as of the time of this writing.

Scrolling performance is a big issue with UITableViews and quite often can be very hard to get right. The main difficulty is cell height calculation. When the user scrolls, every next cell needs to calculate its content and then height before it can be displayed. If you do manual Frame view layouts then it is more performant but the challenge is to get the height and size calculations just right. If you use AutoLayout then the challenge is to set all the constraints right. But even AutoLayout itself could take some time to compute cell heights, and your scrolling performance will suffer.

Potential solutions for scrolling performance issues could be:

• calculate cell height yourself
• keep a prototype cell you fill with content and use it to calculate cell height

Alternatively, you could take a completely radical approach, which is to use different technology like ASDK (Texture). ASDK (Texture) is made specifically for list views with dynamic content size and is optimized to calculate cell heights in a background thread, which makes it super performant.

These days on iOS your go-to solutions for async tasks are NSOperations and GCD blocks. Grand Central Dispatch is a technology that was made to work with multiple background queues that in turn figure out which background thread handles the work. The main thing is that this is abstracted out from you so that you don’t have to worry about it. NSOperation is an OOP abstraction on top of GCD that allows you to do more sophisticated async operations, but everything you could achieve with NSOperations you could do with GCD. Many Cocoa frameworks use GCD and/or NSOperations under the hood (NSURLSession for example).

There are alternative ways of handling async work using third-party libraries’ help. The most notable are Promises (PromiseKit), RxSwift, and ReactiveCocoa. RxSwift and ReactiveCocoa are especially good at modeling the asynchronous nature of time and work that needs to be done in the background and coordinated among threads.

So far the most dominant and robust one is CocoaPods. I was built in the spirit of the Ruby Bundler gem and is a Ruby gem itself. The way it works is you install the gem, create Podfile in the root directory of your project, declare the pods (libraries) you want to use, and run pod install. That’s it.

With Carthage, you create a dependencies declaration file called Cartfile but unlike Cocoapods you’d need to do Xcode project setup to make it work.

Swift Package Manager is the future of dependency management for any Swift project but it only supports libraries and frameworks and cannot be used to generate iOS targets, although iOS targets can depend on modules built by SPM.

There’s always NSLogging and printing in iOS apps. There are breakpoints you can set using Xcode. For performance of individual pieces of code, you could use XCTest’s measureBlock.

You can do more advanced debugging and profiling using Instruments. Instruments is a profiling tool that helps you profile your app and find memory leaks and performance issues at runtime.

TDD is a technique and a discipline where you write failing tests first before you write production code that makes them pass. The tests drive implementation and design of your production code, helping you write only the code necessary to pass the tests implementation, no more, no less. The discipline could be daunting at first and you don’t see payoff of that approach immediately, but if you stick to it, it helps you move faster in the long run. It is especially effective at helping you with refactoring and code changes because at any given time you have the safety net of your tests to tell you if something broke or if everything is still working fine as you change things.

Recently Apple made improvements to XCTest frameworks to make testing easier for us. They also made a lot of improvements with UI testing in Xcode (XCUITest), so now we have a nice programmatic interface to interact with our apps and query things we see on the screen. Alternatively you could go with frameworks like KIF, iOSSnapshotTestCase, EarlGrey.

In regards to unit testing, there are several options as well, but the two most popular ones are XCTest and Quick and Nimble.

XCTest is a xUnit like testing framework built by Apple. This is what they recommend to use, and it has the best integration with Xcode.

Quick is a RSpec-like BDD framework that helps you describe your specs/tests in terms of behavior rather than “tests.” Fans of RSpec like it a lot.

Nimble is a matcher library that can be used with XCTest or Quick to assert expectations in your tests/specs.

There are various ways different people call and categorize test objects but most commonly test objects can be categorized in the following way: fakes, stubs, and mocks.

Fakes is the general umbrella term for any kind of mock, fake, stub, double, etc. On their own, they typically have no implementation and only fulfill the interface API requirements of the types they are substituting.

Stubs are fakes that do some meaningful work that’s necessary for the objects involved in a test to operate, but not used for anything more than that. They can’t be used in place of real production objects but can return stubbed values. They can’t be asserted on.

Mocks are fakes that can be asserted on. Mocks are used in place of other objects just like a fake, but they themselves record some data such as the number of method calls or variables passed for your test to assert on later.

Pair programming is a practice where two developers work on the same task together on the same machine (hopefully not sharing the same screen and keyboard and having two sets of their own). The goal is to facilitate collaboration, discussion, code review, and QA right where the code gets produced. This process makes knowledge transfer and architectural discussions a common day-to-day thing, preventing people from siloing and becoming “an expert” in a certain part of the code (what happens when that person leaves or gets sick?). It also improves code quality because two sets of eyes are looking at the code as it’s written. This process happens for two developers at the same time and is sometimes called synchronous.

Pair programming is not for everyone and could be an exhausting process if people’s personalities do not match. But nevertheless it is one of the most efficient collaboration techniques in software development.

Code review is a similar process of collaboration and knowledge transfer, but unlike pair programming, it doesn’t happen at the same time, and therefore it is asynchronous. With code review, after a developer writes a piece of code or a feature, someone else on the team has a look at it. The reviewer checks if the code makes sense and suggests changes and refactorings to be done to improve it. That opens up an online or offline discussion about the code, which is great. That transfers knowledge about that piece of code to other teammates and helps catch bugs and design smells early on.

Code reviews are a less-involved type of collaboration that achieves much of the same results as pair programming does. It also is an exercise in empathy where you’re giving feedback to others on their work.

Functional Reactive Programming (FRP) is a declarative programming paradigm that combines functional programming and reactive (async dataflow programming) paradigms. It is a declarative style of programming where you declare what your code does rather than state how it does it. The reactive component of FRP allows us to introduce and describe the concept of time, which is hard to work with in pure functional programming. FRP helps us deal with user input and the asynchronous nature of iOS applications in general; user input happens at some point in time, networking will finish some time in the future, etc.

FP and FRP rely on higher-order functions such as map, reduce, and filter that take functions as arguments and return other functions, which makes them highly composable.

Swift doesn’t have native support for FRP, but there are two excellent libraries that implement functional reactive programming concepts and make them easily available to us: ReactiveCocoa and RxSwift.

In iOS 13, Apple also announced a new FRP framework built into iOS called Combine. Combine is effectively an FRP framework implementation similar to RxSwift. The two advantages it has: it’s integrated with SwiftUI allowing it to bind UI elements to data changes, and it’s built-in and supported by Apple. Disadvanges are: it’s less mature than RxSwift and Apple will be slow to make changes and additions to it.