iOS App Architecture Best Practices – What We’ve Learned From Teaching Teams

At Essential Developer, we help individuals and teams achieve their best potential, and iOS App Architecture Best Practices is always a frequent topic in our work. As part of what we do, we often come to the rescue when teams are failing to deliver what the business expects. Over time we identified common patterns amongst dysfunctional teams where one of the most common problems we identified is the misunderstanding of software architecture and its goals.

As professional coaches, we pay attention to what the team has to say, and we value their input and experience over a doctrinal application of any good practice. In our experience, the team has much more insights about their domain than the author of good practice X or Y. With that said, we still believe good practices are great tools to help us avoid common mistakes and pitfalls by learning from other people’s experience.

Balancing Team Experience and iOS App Architecture Best Practices

Trying to balance the team experience with the use of best practices can be challenging, but by listening carefully to what the team has to say, we usually identify misconceptions and gaps in their knowledge that can be corrected. Our approach is never to undermine or to replace the team but to identify issues and collaborate with the team to solve business challenges, together. In our vision, a successful collaboration means the team is now able to operate optimally by themselves. 

A big problem we’re facing at the moment is that many developers have different opinions about iOS App Architecture Best Practices. For example, what is MVVM or VIPER? The answer typically depends on who you ask.

We spent many hours figuring out how to effectively teach software architecture to our students in a way they can clearly understand and leverage iOS App Architecture Best Practices effectively. One of the things we found to be highly beneficial to our classes was to create a clear separation where an architectural pattern is entirely different than software architecture, even though both have “architectur(e)” in the name.

In this mindset, MVVM, just like MVC, is just a UI architectural pattern and not a software architecture. As coaches, we look at MV* patterns as tools for structuring the UI layer, and we teach that an application can be formed of many other layers, not just the UI.

Focus on Solving the Problems

When teaching, we don’t consider MVVM a software architecture anymore. We found it not to be helpful to our students as many times developers get too attached to the semantics of the name and acronyms and forget the problems they are trying to solve. That does not mean we discard MVVM, MVP, and MVC from our arsenal of tools. It just means we look at them as something else than software architecture.

For example, we start by asking the students if they think it’s right to do networking and database calls in the UI. We usually get the answer “no.” Then we ask if it’s ok to do it in a ViewModel, and the answer is usually “yes.” Somehow many students don’t see the ViewModel as we see it, a component of the UI layer.

They correctly identify that it’s a good practice not to do network calls in the UI, but they don’t see ViewModel as something UI related, even though View is in the name. Many students get so attached to the semantics of the MVVM acronym that they end up trying to fit anything into a View, a ViewModel or a Model. As if everything in the app could be classified into those three types.

Establish a Shared Understanding of Software Architecture

Until we have a shared understanding with the students of what we mean by software architecture, it can be counterproductive to have a conversation about it. For us, an app can be sliced into several layers and we want to have the freedom to expand and contract the number of abstraction layers in our architecture as needed. For many students, things normally have to fit into a predefined and limited way of thinking, for example, a dogmatic application of VIPER where every feature must have a View, an Interactor, a Presenter, an Entity and a Router. And again, they don’t know where to put the database and the networking in a VIPER architecture.

The interesting thing is that the creators of such patterns don’t usually dogmatically approach software and it was never their intention for people to think of such patterns as a rigid structure.

Don’t Underestimate the Students

Although it can be tempting to oversimplify and limit the scope when teaching a subject, by explaining the in-depth concept of software architecture as layers of abstraction and its boundaries, without using acronyms, we’ve found a much better learning outcome amongst our students. As soon as they can separate concerns into groups or layers and how those layers communicate, they can easily find the answers on their own. For example, where MVC or MVVM would fit better – in the GUI or Presentation layer. They can also find out where to move the Networking and Database code to better solve their domain problems without trying to fit it in a limited way of thinking.

We are often surprised by how creative the students can be when given the right framework to think. Out of the best collaborations, we saw students coming back with better solutions than we would ever be able to provide for the business since they know the domain better than we do. That’s how powerful education can be for individuals and companies, and that’s the kind of transformation we’re looking for when we’re teaching.

Conclusion

We’re heartbroken every time we see teams wasting their great potential because of misconceptions and confusion generated by the lack of understanding on software architecture and iOS App Architecture Best Practices. The downsides of the lack of software architecture education come in many flavors where the most common one is the inevitable “we have to rewrite the app” talk with the boss.

Developers that identified the need for good software architecture skills are investing in their career transformation and are building up their competitive edge in the market against developers that don’t.

We've recently conducted a market research to help developers find a good path to direct their careers and develop a competitive edge. If you’re interested, we’ve compiled it in a free iOS Career Course.