Architecture (MVC, VIPER, MVVM, TCA, REDUX), again ?

What architecture do you prefer?

I think most of us have either been asked this kind of question or have asked it in interviews. Let’s try to find a way to answer it. We are all familiar with this diagram.

MVC: the first architecture we faced when we started learning iOS development. We were creating applications and feeling proud of ourselves - we could finally build something more than “Hello World” 💪. We are not yet very experienced engineers and continue using MVC by default, but we keep developing ourselves - reading articles, watching videos (any educational content), and then “figured out” that we had a Massive View Controller problem in our project. We cried a little, started to hate MVC, and began looking for something “better” 🕵️‍♀️.

During our search for a new architecture, we heard the word VIPER (from a colleague or at a conference) 🤔. We learned about VIPER and began implementing it in our project. We were happy with it - everything was clear and definitely better than MVC. Life became better 🥳

From then on, VIPER was our favourite. At some point, you change team (or company) and join a new project with a different architecture. You argue with your new teammates that their architecture is worse than what you used on your previous project and try to push them to rewrite the project, convinced that your architecture is better suited for it. You get rejected, and from then on you’re fighting inside yourself - with them 😉

After studying the project architecture more closely, you discovered a new acronym: MVVM 🤔. After some time, you realized that this architecture works perfectly for this project and isn’t as bad as you thought at the beginning 💡

Or even more interesting - my own case: a new team, a project almost finished, and… 🥁 TCA architecture and SwiftUI (not stable enough yet). We can’t avoid such situations and definitely can’t panic. We just sit down, open the project, learn it a bit, and try to deliver features quickly and reliably (and, of course, don’t hesitate to ask a colleague for help when needed).

What I’m trying to say by describing these cases is that there is no silver-bullet architecture that we can use in every project.

Let’s be honest, there is no problem with the MVC architecture if we need to develop a simple application. It will meet all our needs and save us from over-engineering - trying to solve problems of the future that may not even exist.

There is also no problem with VIPER if we are part of a team with strict rules and automation, where modules are generated. We can easily extend the team or add a junior developer who can quickly make a positive impact on the project.

MVVM is also a good choice if you are using SwiftUI or if it fits the project’s needs for any other reason.

No one can prohibit you from using TCA or REDUX either.

The project can be structured into packages or independent modules, and each part can have its own architecture inside.

To answer the question from the beginning of the article, make a quick note before you start thinking out loud.

It depends on the project

After that, ask additional questions. For example:

• Can you please describe project a bit? It will help you to understand possible size of the project and (at least) how difficult navigation will be (e.g. navigation somewhere deeper in that app from push notification)

• What list of features from described (in answer on first question) you would like to have in first version (MVP)? In most of the cases (or even in all of them) answer will be: this is whole list we want to have in first release, but reality is a bit different and we can find mid point to deliver core functionality of the idea, test it and add more features in next releases.

• What is the team structure? If there is junior developer and us, then we need to understand his/her experience (familiar architectures). At this point we trying to understand possible technical blockers in our team and minimize (possibly) time required to launch the project.

• // more questions here

Once the questions above are answered, you can propose architecture that may align with the described requirements and the details discussed.

Try to think a bit wider - it will help you come across as an engineer, not just a coder, and as someone who thinks about the product first.

Wishing you stable releases and greater revenue from your projects 🚀