There are four basic architectures: . They are mostly monolithic, while the last one is closest to modularity. MVC, MVP, MVVM, and Viper Of course, any project can be written with any of these architectures. No one excludes the absence of architecture or a unified approach to project development, either. But patterns are a powerful instrument to make development faster and easier, to help better understand your code. It is crucial for business value to develop fast and keep the code maintainable. This is not going to happen if you write 2-day projects on Viper, or 1000+ hour projects on MVC/MVP. The monolithic nature of the patterns contributes to numerous nuances. Let's break them down in detail. Common mobile architecture patterns 1. MVC MVC is the first approach we encounter when beginning iOS development. Here, View and Controller are a single object a developer has to describe. The major disadvantage of this method is the Massive View Controller: it means that all of the functionality has to be developed on the view level. Therefore, View Controller is completely unreadable, hard to maintain, and accumulates a whole heap of spaghetti code. 2. MVP I like to use this pattern in small projects. It provides a possibility to separate business logic with View Controller – to some extent. We can bring it to the level of our passive view. What bothered me is that I still had to create pseudo navigation for View Controller. Thus, I couldn't get rid of functional dependency and view. 3. MVVM This one has a higher popularity today. The pattern completely takes the business logic of our structural unit out into View Model. Therefore, it separates functionality from view. The model is easily covered with tests and allows allocating areas of responsibility. A small number of parts contributes to comfortable scaling. However, it lacks navigation as a separate structural unit. 4. Viper A Lean descendant, this pattern provides absolutely all structural units we need: View, Router, Presenter, Interactor. It allows us to completely break up business logic: separate work with navigation, work with models, etc. Yet, experience has shown that Viper clutters the structure of projects over time. Projects of 1000+ hours tend to change quickly. If a client wants a new feature, you basically need to remake the whole subsection. Router helps a little with some sort of splice, but it’s not enough. To conclude, Viper is the closest to modularity due to the possibility to connect structural units. MVC, MVP, and MVVM are on the monolithic side: we can write them once and then use them all the time. Let’s summarize the cons of these architectures. Cons of Monolithic Architectures Monolithic architectures make evolving projects hard to maintain. If a client wants to add new functionality, you will have to change an interdependent code. It is difficult to divide the work between two or more developers. Chaos in the repository is almost guaranteed. Navigation is a weak spot. Router & Coordinator are not convenient enough to implement, because they need changes every time a new structural unit is added. Areas of responsibility are not explicit, while functional testing affects many dependencies. The qualifications of the entire team affect the choice of architecture. It will be hard for Juniors to understand VIPER, and doing a 1000+ hour project on MVC is not the best idea. Modular Architecture vs. Monoliths It’s easy to understand the benefits of modular architecture compared to monolithic with this example. Monolith is like a large, non-rotatable, heavy painting that is difficult to carry from one corner of the house to another. By contrast, a modular pattern is like a puzzle. Having the same size, it’s much more convenient to move by dividing and then assembling pieces. Moreover, you could change the parts that are already outdated and require improvement. We examine modular architecture in detail in the next two parts of this Modular Architecture Overview. Learn how to work with modules, their pros & cons, and our experience. Stay tuned!
