We explore in a few paragraphs everything you need to know so that the next time you design an app you do it world class style. In addition, we analyze a key: the role of decision makers in a company.
Deciding the type of mobile architecture to implement when developing an app is the most critical moment in the whole project. It’s a make-it-or-break-it situation –it can either lead to success or make you throw months of work away and start all over again. This decision concerns not only the dev team but also people at the decision-making level in the organization.
What happens when the mobile architecture provided by Google and Apple falls short? What can devs do when they need to scale an app so that it can be used by millions of people? And what happens when you plan an app that will be developed by dozens of developers? In this article we’ll dig deeper into these and more questions, and discuss how software theories can be applied in mobile architecture.
A Short Review of Mobile Architecture Types
Both iOS and Android have an interesting history of mobile architecture development:
- MVC is one of the oldest models and stands for Model-View-Controller. The issue with it was that Apple and Google actually follow their own MVC patterns, so it ended up not being the best option.
- Then the MVVM model appeared, which stands for Model-View-ViewModel. In iOS this meant progress because the distribution pattern was better than that of previous architecture. In Android, the main issues arise when apps grow in complexity. The main problems with this type of architecture are a) that it focuses on showing the information and how it connects, instead of showing the logic of the app and the data that feed it; and b) that it doesn’t have business criteria –there’s no clarity about the organization of the components and the structure of their connections, which gets worse as the need to scale increases.
- Since MVVM proved to be unconvincing, a new model appeared: VIPER, which stands for View-Interactor-Presenter-Entity-Router. At first, it was mainly used in iOS, but it slowly pushed its way towards Android. Devs found this was a clean architecture approach which allowed to split the logic structure of the app in different layers or levels or responsibility (we’ll see more of this later on). Thanks to that, there are no dependence issues and the testing functionality is greater. Nevertheless, since this model isn’t very popular and it’s mainly used in iOS, it’s less suitable because it doesn’t allow to create a common architecture for both iOS and Android.
Software Theory Applied to Mobile Architecture
When we look at the mobile architecture provided by Google and Apple, it’s necessary to rethink how we plan projects, in order to understand from the beginning which options we have.
Like we said, although with Google’s and Apple’s mobile architectures we can develop simple apps in a short period of time, there comes a moment when they fall short. That being the case, the first thing to do when starting a project is to think how to create something that’s easy to use by anyone in those platforms, that can also scale to be used by millions of users in the future.
Marco Scabbiolo, mobile expert at redbee, told us about a few key theories to consider when starting a project. . One of them is DDD (Domain Driven Design).
“This theory states that first you need to organize by domain, product or business, and then by structure,” says Marco.
That is, you can split into structural elements such as “user domain”, “login domain”, “search domain”, and “payment domain”, which makes it easier to locate things when needed.
“You can set everything up separately in different modules that can be coupled together in any app, which gives you the flexibility to create other apps with those modules,” adds Marco, talking about the benefits of this theory.
Clean is another theory (we mentioned it earlier, and according to Marco, any good architecture should follow it). It states that the organization should be such that there’s no coupling, that is, the parts shouldn’t be connected to one another.
Hexagonal architecture derived from Clean theory. In this type of architecture, every part of the app needs to be replaceable at any time.
“There are three layers: Data –where to obtain the information from, Application –the functioning logic of the app, and Presentation –the interface shown to the user,” explains our guru.
Most apps follow this pattern, but there can be variants. The key is to make them replaceable and well-defined. It’s also essential to consider adopting this theory from the beginning, before it’s too late to do so.
How Can Hexagonal Architecture be implemented?
One redbee client, a Latin American retail company, wanted to create an app with different versions adapted for final users and vendors.
“They needed microproducts specific for each client or retail business, with different functionalities,” recalls Marco.
“Our approach was to build modules so that each client could get all the modules they needed, at a minimum technical cost, with the possibility to make specific marketing offerings for retail” he adds.
So, they implemented hexagonal architecture, which allowed to split between business parts and was flexible enough to be adapted as the app evolved, with uncoupled parts.
Who Decides About Mobile Architecture?
When it comes to choosing the theory and mobile architecture to implement, the client, the project leaders and the dev teams must be on the same page. If a decision is made to invest time and money in a simple, fast app that cannot scale in the future, it will mean a waste of time and money in the future.
“The idea is that the team can evolve as the app grows,” says Marco, reflecting on the challenge bigger companies face to build a solid in-house dev team.
“Otherwise, there’s going to be a gap between the organic growth that the team should have experienced and the level up to which the product can scale.”
The challenge is to think of the architecture beyond the platform.
“If you set up a baseline architecture that’s adaptable to any kind of technology, it’s easier to migrate to any other tech. When there’s one single architecture for both iOS and Android, it’s also easier to migrate from one to the other,” he explains.
In the End, Which Architecture is Better?
Our guru recommends MVVMSR (which stands for Model-View-ViewModel-Service- Repository) especially if the app needs to be scalable.
“It’s a review of traditional MVVM that incorporates DDD and Clean (hexagonal architecture),” explains Marco.
In this type of architecture, each domain is defined and has a specific responsibility, although they may be dependent on one another. In addition, they can be combined in order to create an app just with the required functions.
“Internally, domains incorporate a hexagonal architecture by dividing its components into Presentation (View, ViewModel), Application (Model-Service), and Data (Repository),” he explains.
This article sums up redbee’s working approach. We believe it’s necessary to support our clients in navigating challenging projects by implementing added-value technology, and most importantly, we want to ensure that not only our clients grow steadily, but also our teams.
