WHITEPAPER How to choose the best iOS architectural pattern for your app Introduction: As software developers there projects they plan to start. is a moment when we have to Moreover, it is important to decide how to build a system. understand that architectural In this context, architectural patterns are not the solution to patterns are important all problems. to create a verifiable and compatible code structure They only solve and delineate that all developers can easily some of the essential cohesive understand. elements of a software architecture. Needless to say, it is difficult to choose the correct pattern to To make a fair comparison, we follow, in order to build a good will define three main features structured code that everyone that a good architecture must can work with. have, and we will evaluate the patterns based on this: In this article we will discuss three popular patterns for 1. Balanced distribution of iOS, how they work, and responsibilities among entities some of their advantages and with strict roles. disadvantages. 2. Testability of code. This will help iOS developers 3. Ease of use and a low choose the correct pattern for maintenance cost. page 2 www.belatrixsf.com | belatrixsf.com/blog We will examine: • Classic Model View Controller • Apple’s Model View Controller • Massive View Controller • Model View Presenter • Model View ViewModel page 3 www.belatrixsf.com | belatrixsf.com/blog Classic Model View Controller Let’s first discuss the classic Model View Controller (MVC) in a close way to the original interpretation. MVC appeared in the software world in the late 70’s and since then, there have been many different interpretations of it. MVC presents a clear division between responsibilities by constructing three components, Model, View and Controller. The Model is a representation of the information, it is responsible for managing the database and the business entities. It will usually authorize reading or writing requests that arrive from the Controller. Nevertheless, in classical MVC, the View has direct reading access to the Model. The View takes care of displaying everything in a correct format to the system’s user, like interfaces of mobile or web apps. The View should not directly change the state of the Model. And finally, the Controller that responds to external stimuli to perform some logic, including the change of the state of page 4 www.belatrixsf.com | belatrixsf.com/blog the Model and what the View should display. Figure 1. iOS Architecture Patterns by Bohdan Orlov In classical MVC, all three entities are tightly coupled, each entity knows about the other two. This reduces the reusability of each of them and it is hard to test. Apple encourages its users to use MVC as an architectural pattern. The files that manage the logic in xcode are called ViewControllers. Furthermore, many Cocoa technologies are based on MVC and require that your custom objects play one of the MVC roles. page 5 www.belatrixsf.com | belatrixsf.com/blog Apple’s Model View Controller In the Cocoa and CocoaTouch frameworks, the Controller is a mediator between the View and the Model, so the Model doesn’t know anything about the View. Figure 2. iOS Architecture Patterns by Bohdan Orlov This means that changes to one module don’t heavily impact other modules. This requirement is very important when it comes to testing because it allows you to test each component individually, with unit tests. The View handles events that are part of its logic, such as touch events or display data for the user. Then, it sends the action to the Controller to receive a response and perform the next action. page 6 www.belatrixsf.com | belatrixsf.com/blog The Controller processes the action, and, if necessary, changes the state of the Model and updates the data. If the state of the Model is changed, the Controller will be notified, and it has to decide how to handle these changes. Since the Controller is aware of the new values from the Model, it will perform some transformations of the data if required, and sends the new values to the View. page 7 www.belatrixsf.com | belatrixsf.com/blog Massive View Controller It is called Massive View Controller because, in Cocoa MVC, the View and the Controllers are strongly coupled. They are so involved in the Viewing life cycle that it’s hard to treat them as separate components. All the responsibility of the View is to send actions to the Controller. However, the View Controller ends up being a delegate and a data source of everything, and is usually responsible for dispatching and cancelling network requests. Figure 3. iOS Architecture Patterns by Bohdan Orlov page 8 www.belatrixsf.com | belatrixsf.com/blog Advantages • Support for asynchronous requests. MVC supports an asynchronous technique, which helps developers to develop an application that loads very fast. • Modification does not affect the entire model because the model part does not depend on the views part. Therefore, any changes in the Model will not affect the entire architecture. Disadvantages • The controller contains a part of the state of the view and almost all the logic of the view what makes it strongly coupled. • Since the controller is tightly coupled with the view, it becomes difficult to test. Features • Distribution . The View and the Model are separated, but the View and the Controller are tightly coupled. • Testability. It has a bad distribution, so it will be hard to test. • Ease of use . Requires the least amount of code among other patterns and it’s easily maintained. page 9 www.belatrixsf.com | belatrixsf.com/blog Model View Presenter MVP was introduced in the early 90’s and it is an extension of the classic MVC. They both have three main components, but the Controller is replaced by the Presenter in MVP. The view is responsible for rendering the user interface and reacting to user events. In the case of iOS, the view will consist of a Protocol that exposes the methods of the user’s events and a ViewController that is responsible for the view logic. In MVC, the View is tightly coupled with the Controller, while in MVP, the Presenter has nothing to do with the life cycle of the view controller, but it is responsible for updating the View with data and state. The Presenter works as a mediator, contains the UI business logic for the View and can change the state of a Model. Figure 4. iOS Architecture Patterns by Bohdan Orlov page 10 www.belatrixsf.com | belatrixsf.com/blog In this way, conducting the unit tests is easier than in MVC, since the Presenter can be tested separately from the view logic. MVP distributes responsibility well and makes unit tests less tedious. However, it reduces the speed of development, since the implementation of the Presenter and the link through the layers brings some additional work. Advantages • Because the View and the Presenter are separated, it’s easier to test. • Makes it easier to verify the correct functioning of each piece of software with unit test. • MVP is typically easier to learn than MVVM, which we examine later in this article. Disadvantages • Complex views may have multiple presenters. • Excess of code to communicate components. Features • Distribution . Most of the responsibilities are divided between the Presenter and the Model. • Testability . Most of the business logic can be easily tested due to the decoupling of page 11 www.belatrixsf.com | belatrixsf.com/blog components. • Ease of use . The amount of code is double compared to the MVC pattern. page 12 www.belatrixsf.com | belatrixsf.com/blog Model View ViewModel Model View ViewModel was created by John Gossman, one of Microsoft’s architects, in 2005. The purpose of the pattern is the separation of the user interface and business logic development. Each View on the screen will be backed by a View Model that represents the data for the view. This architectural pattern also consists of 3 components: Model, View, and ViewModel. In this case, the Model is essentially the same as it is in MVC, which means it represents the information and is composed of databases. and business entities. The View layer is composed of the view logic and the ViewController, and is responsible for everything the user is capable of seeing. The ViewModel is the mediator between the View and the Model and is responsible for processing the presentation logic. It also knows about the Model and can change its state. Furthermore, the ViewModel can transform the data from the Model into a format which is more convenient for the View. However, the ViewModel doesn’t know about the page 13 www.belatrixsf.com | belatrixsf.com/blog View and can interact with View only through the Data Binding mechanism. Figure 5. iOS Architecture Patterns by Bohdan Orlov There are many approaches to connect a view model to a view. The purpose is that the view must have a view model assigned to its DataContext property. We have two main options: • Use one of the KVO (Key-Value Observing) based binding libraries like SwiftBond, which provides a mechanism that allows objects to be notified of changes to specific properties of other objects. • Use one of the functional reactive programming frameworks: ReactiveCocoa, RxSwift or PromiseKit. Advantages • Reduces the amount of code for synchronizing the View with the ViewModel. • The ViewModel layer is completely independent of the View which means much easier testing and DataBinding page 14 www.belatrixsf.com | belatrixsf.com/blog usage. Disadvantages • It may require significant memory resources in DataBinding mechanisms. • It can be difficult to connect ViewModels to Views. Features • Distribution .