Introduction to iOS App Architectures
Architecture
What is architecture? What does the word actually mean? If you look in the dictionary you have two main definitions.
The art or practice of designing and constructing buildings.
The complex or carefully designed structure of something.
The first definition is the one most of us are probably familiar with, it’s designing a building (or any other kind of structure). Before you can actually build a house, for example, you have to design how it’s going to be built. You have to design how it’s going to look, how it’s going to work, which doors will lead into which rooms, where support beams will be, etc.
This leads us to the second definition: The complex or carefully designed structure of something. This takes the same idea as before and applies it in a more general sense. It is the thoughtfully designed structure of something. The something we are going to talk about here is Software.
It is inconceivable that someone would start building a house without a blueprint, without any kind of plan or design. It’s obvious that before you start building a house you need to have a well thought out, designed blueprint that follows standard industry patterns, amongst other things. One of the many reasons for this is because after the house is built (or half-way built) it is going to be hard, if not impossible, to go back and change the basic structure of the house. Also, if you have no blueprint or design I can only imagine the mess of a house it would be, with inconsistencies and surprises at every corner.
Well the same applies to software. We should design our system so we have an idea of what high-level structures we will have, what are going to be the relationships between them, and what will be the inputs/outputs of each structure. This will make our system easy to reason about and understand. Change in a software system will inevitably come, so if we have a solid architecture, changing out specific modules of a software system should be simple without having to change the overall high-level structure.
Software architecture is about making fundamental structural choices which are costly to change once implemented.
iOS App Architecture
So how does this all apply to iOS Applications? So let’s start with the basics. We couldn’t talk about iOS architecture without talking about Model View Controller (MVC).
MVC is was invented at Xeroc Parc in the 70’s and it first appeared in the programming language Smalltalk-80. It’s a really simple architecture which separates all objects in a software system into three buckets. These may be a little different depending on the domain you are working on, but for iOS these can be described like so:
- Model: Anything that deals with storing data, transmitting data, and the data itself.
- View: Any user visible object which displays something on screen and handles user input.
- Controller: The mediator between the Model and the View. The controller updates the Model, and the Model notifies the controller that there is new data. Then the controller updates the View, and the View sends all user action
There is no way around MVC in iOS. All subclasses of UIView, which can be shown on screen, are your Views, and all subclasses of UIViewController which control control and own those UIView’s are controllers. And basically everything else is the model. So in a way MVC is the “official” Apple way to handle architecture in iOS/macOS/tvOS/watchOS apps.
If something in the last paragraph sounded a little off, you might be onto something. The sentence, “basically everything else is the model”, is true in many cases. The other objects, in a simple app at least, will be data models, database or server/API access objects, and those are the Model. But herein lies the problem with MVC. It’s too simplistic to assume that everything will be either Model or View or Controller and that’s it. There is no place for other kinds of objects with other kinds of responsibilities.
This is where other architectures come in. I don’t think any of these other architectures are meant to competely replace MVC, because as I said before, MVC is the “only” way to build Apple software because that is the way the Cocoa frameworks are designed. I think of these architectures as a way to expand/redesign/rename/improve MVC to properly account for all the kinds of objects a complex modern app can have.
Beyond MVC
There is no way I could metion all architectures that exist for iOS development since this is something that changes in the community, as people explore and design new ways to architect iOS apps. But the ones I’m going to briefly introduce are the ones I consider to be the most important, and which can be used as a base to build and design our own architectures.
MVVM
Model-View-ViewModel is one of the most common post-MVC architectures in the iOS community. It was originally coined by Microsoft in 2005 to be used in their Silveright software.
What it technically implies can vary depending on your domain or technology. But in the iOS world it is basically an expansion of MVC. The Model is still the Model. The View is still the View, but it now also includes the controller (UIViewController subclasses) inside the View umbrella, since it’s so tightly coupled with it anyways. And finally, it introduces a new concept, the ViewModel.
The ViewModel can be thought of as an improvement of the controller concept. It is the mediator between the Model and the View. You can think of this as basically splitting the controller part in MVC into two parts. One is the UIViewController subclasses which now belong inside the View, and the other is the ViewModel.
This can seem like a really simple change but it’s incredibly powerfull. It makes ViewController’s extremelly simple because now all they have to worry about is controlling the UIView and reacting to events, and all of the complicated bussiness logic now goes in the ViewModel. This decouples our ViewModel’s from Apple’s frameworks and makes them much easier to test.
FlowCoordinator
FlowCoordinators or just Coordinators as they are usually referred to, are also a simple concept. Usually in our iOS apps the ViewController’s handle the navigation. What I mean by this is that when a user clicks on a button in our apps the ViewController (or the storyboard which is even worse!) is responsible for deciding what should happen next, what ViewController I need to instantiate and present or push onto the navigation stack.
This may be ok in a simple application. But this makes for really coupled code in a complex application and makes ViewController’s really hard to re-use. The idea is to move all of the high-level navigation logic up into a Coordinator. This makes ViewController’s much more re-usable as they only need to inform the coordinator that something happened, and they are free of any other responsibility.
The coordinator then is responsible for knowing which ViewController’s to instantiate, to either present or push them, and to inject any dependencies the controller might need. This last point is one of the biggest benefits of using coordinators. Without using coordinators, passing along dependencies (which is a recommended practice!) is a hassle. This leads to having to pass a dependency to multiple controllers just to get it to the controller that needs it. Or, even worse in some cases, having to use (or abuse) Singletons.
VIPER
VIPER is one of the most complete iOS architectures out there. Instead of focusing on only a specific part or problem of an architecture it aims to create a completely new architecture from the ground up. I have not used VIPER before not because I don’t like it but because I think architecting your iOS app should be more of an art, and it should be built for your the specific needs of your app, and VIPER is so complete that it really leaves no space for you to create your own.
VIPER is the whole package and I personally prefer the approach of creating a custom architecture that fits your app, obviously basing it on top of and borrowing from other architectures. That is why I think it’s important to mention VIPER and read about it, because it is a great example of how a complete architecture can look. And as you’ll see, most of the parts of VIPER already exist in other architectures just under different names. So it’s a really useful example to learn more about iOS architecture.
VIPER is split into these parts:
- View: The same View we know and love.
- Interactor: All different modules of Business logic your app can have. (Similar to ViewModel)
- Presenter: Prepares content for display. Interacts with View and Interactor. (Also similar to ViewModel)
- Entity: The plain data-Model objects. (Model)
- Routing: Logic for displaying screens and navigating. (Similar to coordinator)
Conclusion
This article is meant as a very high level introduction of what iOS app architecture is, why it’s important, and to introduce some of the basic concepts of the different architectures out there. This is in no way a complete look at all of this subject, I recommend you use this as an introduction to the subject and keep learning about this. I will include some links below.
This article is also meant as an introduction of a series of architecture blog posts I wrote detailing my own implementation of the MVVM-C (Model-View-ViewModel-Coordinator) architecture. This is obviously not an architecture I invented, it’s out there, but I think it’s interesting to share my own specific implementation that I am using in a big production app I am working on.
There is no universal guide to iOS architectures so all we can count on in the iOS community is blog posts and sample code from other developers to learn more about this subject, so this is my contribution.
Sources, Further Reading
