Pragmatic iOS Development: The MVA approach

Updated Mar 6, 2023 • 6 min read

In our previous article from the Pragmatic iOS Development series, we discussed the Model View Controller pattern and why (in my opinion, unrightfully) it is criticised within the community. I also mentioned two things about selecting perfect architecture for your project. The first thing was that there’s no happy medium that fits all of the use cases. Secondly, in the last sentence of the article, I gave a sneak peek of the architecture you’re going to fall love with, MVA. But there’s one thing I lied about: that there’s no architectural approach you can fit to any project you can think of. The truth is, such approach exists. And hey, good news: we’re going to focus on it today, and I’m going to tell you how to take advantage of this approach.

MVC, MVP, MVVM… MVA?

So here we go again. We’re living in a world full of… architectural patterns? Well, you know, there’s a lot to choose from when laying the foundation for your future mobile application. You can write your personal project with MVC and maintain it. We've already agreed that MVC is not that bad. If you’re an Android developer, why not go for MVP which is basically the platform's standard? MVVM is also great, especially when combined with Reactive Extensions to provide more obvious composition in your medium-sized app. VIPER is even more than that: it extends over the GUI layer and fits large, difficult to maintain projects – this is the reason why it was invented. I’m sure you know how important it is to select the right tool for your job. I’m also sure that you would use a hammer to drive a nail into a wall if you would like to hang a cool picture in your living room. You could use pliers to do that as well, but it doesn’t sound as good as a hammer. Does it mean pliers are a bad tool? No, they’re also a perfect fit but just for a different job. It’s exactly the same when it comes to planning your architecture. You should select your tool, and this tool is MVA. Because MVA is not a pattern – it’s an approach.

Minimum Viable Architecture

Minimum Viable Architecture is an architecture which is good enough to match the requirements and allow the product to grow in the future without any significant problems. It’s also about making sure that you don't implement something you won't need. In some way, it definitely comes with experience, of course, but, most importantly, it comes with reasoning. Reasoning is key when you are implementing your application with MVA. That’s why you should never let yourself be influenced by opinions that you don’t find reasonable. It can be dangerous, usually for developers who don’t find themselves confident enough to design entire system from the ground up and especially juniors. This is why it is so important to remember that there’s nothing wrong in asking for help, but you should never listen to people who try to persuade you without any solid arguments that you can agree with. “MVC is bad and VIPER’s not” is a great example of such behaviour, because MVC can be a hammer where VIPER is pliers. Blind trust in seniority is another dangerous area. If your mentor wants to you to use tool A over tool B due to their so-called “experience” but doesn’t give you an obvious explanation why, they are probably a wrong mentor, and you should seek help somewhere else. MVA can be either MVC, MVP, MVVM or VIPER. It can also be Flux, Redux, or any other tool you can think of. What’s up to you is, again, to make sure that you’re choosing the right tool for the job. VIPER can be too much boilerplate in use cases where MVVM fits perfectly. But MVVM can be too broad for cases where VIPER will actually do the job.

How to choose my tool?

Choosing your tool is a difficult part, and it takes time, understanding, and communication. First of all, you really need to know your product. Talk to the client and understand the functional and non-functional requirements. Make sure that the product can be delivered within the specified time frame. Ask about the expected amount of users of the product. Is the architecture of your choice able to handle these numbers efficiently? Don’t throw yourself in at the deep end. Instead, focus on the current iteration but keep in mind: is it a good choice to scale the product over time? After all, we’re agile. Stay in touch with the product owner. Make sure that you understand the requirements exactly the same way. Allow as little space for interpretation or misunderstanding as possible. Keep in mind that the requirements and the product can change over time. Make sure your architecture will be ready for that. After all, again, we’re agile. Always do your best, but don’t strive for perfectionism. Is there such thing as a perfect product? You probably do care if the code you’re going to write is beautiful, well-organised, and adjusted to the latest trends. But users do not – all they care about is the product. The product has to match the requirements and to be delivered on time. What’s the point of writing the next big architectural thing, when there is a risk that we can miss the deadline? Do the 80-20 analysis (also known as the Pareto principle). In other words, 20% of the time spent architecting a product will translate into 80% of the results. That’s the time spent on planning, understanding your requirements, reasoning, and talking to your product owner. Make sure this is quality time, because it naturally leads to MVA, and MVA is the right way to deliver a quality product. So, to summarise:

Learn about the available architectures and know your options 💡
Don’t be afraid to ask for help but don’t forget about solid argumentation 🙋
Learn about the product – its technical and non-technical requirements 📚
Be in constant touch with the product owner and adapt to changes as they occur 💬
Do your best, but remember that delivery is more important than technical excellence 🚚
Make sure that you choose the right tool for the job 🔨