The importance of modular architectures in mobile applications

Importance of technical architecture in mobile app development

When developing a mobile application, it is important to properly plan its technical architecture from the beginning. Often, many companies tend to focus solely on aspects such as user experience, usability, or design, but they tend to overlook code quality or concepts such as maintainability and scalability, among others.

The result is an application that initially meets the expectations of both the company itself and the end users, but in the long term it becomes something difficult to maintain, difficult to extend with new functionalities, and a project that no one wants to work on. In this article we will try to analyze these situations and how to try to avoid them.

What is the architecture of a mobile application?

An architecture is a set of elements and decisions that define how the internal structure of an application's code should be (and evolve). This concept is not specific to mobile applications but has been present in many software projects of any technology for many years.

In the specific case of iOS and Android apps, an architecture is the way in which the different views, the associated code, the graphic resources, the business logic, the data models, the communication with services and databases, and data persistence, among others, are structured. It also describes how the different elements that are part of an application's structure need to communicate with each other.

It is quite common for mobile applications not to pay as much attention to technical design but to prioritize other aspects. It is important not to overlook how a modular architecture can benefit a mobile application if the project is moderately large. In the case of smaller applications, the use of this type of architecture would be considered over-engineering.

Why is it important to consider architecture from the beginning?

To understand it, the best thing is to use an example from everyday life: imagine that you have just acquired a plot of land and you want to build a house on it. Nowadays there is a wide variety of options: prefabricated houses, modular houses, traditional construction, etc.

When one is about to build a house or buy one that is already built, they pay attention to various aspects such as: type of materials to be used, quality of the materials, cost they represent for the overall work, durability, and other topics of greater or lesser interest.

According to the choices we make, the house we build will be a luxury house or a normal house, it will last 10 years or it will last 200, etc. This doesn't mean that one is better than the other, but we must take into account the number of years we want to live in it or if we plan to completely renovate it over time. We have to make sure that the project meets our expectations.

If we only focus on making it look nice and be functional but we do not take into account key elements such as the foundations, the quality of the walls, and so on, we will surely have serious problems as we spend time living in that home: dampness, external noises, leaks... and a host of other issues.

Can you imagine a house where the toilet is in the kitchen and the bathroom has an oven? Surely you wouldn't live in that house or at least you couldn't call it home. But with a code we are not able to see these things if we don't have technical knowledge; surely in your application you have an oven in the bathroom.

We can have an application that looks nice and works well for its launch, but the code inside may not be optimal and may have many tightly coupled functionalities. In this scenario, extending that same code with new functions or maintaining it and looking for its errors to solve them becomes an increasingly difficult task. Following the previous example, relocating the toilet in the bathroom and the oven in the kitchen is not as simple as moving the elements around, but rather requires changing a large part of the installation.

It is a factor that not only impacts the project but also the turnover of technical staff.

The impact of rotation on projects

That architectures are not well thought out from the beginning not only causes problems for developers, but also for the companies themselves. When a project has not been well planned from the start and someone is asked to continue extending its functionality, it ends up generating frustration because things are getting worse. It is very difficult to structure something that was initially poorly planned, no matter how many hours are dedicated to refactoring code and rewriting certain parts.

This frustration often leads to problems among team members (usually between technical and non-technical people), due to the inability to convey and make stakeholders understand that the application architecture was not well planned from the beginning. In the end, like everything in life when something doesn't work, it ends up breaking completely and people end up leaving. Every time a team member leaves, not only a resource leaves but also all the knowledge and experience of that person leaves.

It is common to think that with a more senior or experienced person we will solve the problem, as they will rewrite parts of the code that are not right and thus there will be no frustration. But usually the opposite effect is achieved: the more experience a professional has, the more easily they realize the structural problems of an application and they will probably end up abandoning the ship before a more junior profile, who will take longer to realize the situation.

It's a vicious circle, while end users continue to wait for updates with new features and bug fixes that never arrive.

What can we do to improve these situations?

The only possible solution involves completely rewriting the application, but changing the process. If you did not take into account the technical design when the project started, it is time to do so if you decide to start from scratch. If you try to rewrite parts or fix some small defects, the root of the problem will always be there. It is like trying to solve a coexistence problem without both parties acknowledging their mistakes sincerely, it will resurface again over time.

Nowadays there is a growing trend: modular architectures. They are not just a passing fad, because modular architectures come to solve two main problems: maintainability and scalability. Let's see how they do it.

What is a modular architecture?

A modular architecture is one that allows dividing an application into several modules. A module is a subset of an application that has:

• A single responsibility, only one
• A specific functional behavior and no more
• The ability to communicate with other modules but without fully knowing them
• The ability to change its interior without affecting the exterior

These types of architectures use a technique called divide and conquer, which involves dividing a very large problem (a large application) into very small and specific fragments. In this way, each time one of these modules is done, it is like starting a project from scratch: if something does not work well, you can do it again.

The main difference with a traditional architecture is that the different modules can be used and communicate with each other, but they should not know each other. In this way, it is relatively easy to replace a piece that is not working with another one, since the rest of the pieces will know how to communicate with the new one immediately. From a technical point of view, the description of this architecture is said to follow the SOLID principles, which you have surely heard of before.

Advantages and Disadvantages of modular architectures

Like everything in life, modular architectures have advantages but also disadvantages. Let's see what they are:

Most relevant advantages

• Allow to redo parts that do not work without affecting the rest.
• Allow to parallelize the development more once the technical base is established.
• Facilitate maintenance by being divided into smaller and less complex pieces.
• Improve team happiness in the long term as they do not generate as much frustration.
• Allow to adapt quickly to new functionalities of operating systems (e.g. the "App Clips" recently announced by Apple).

Most relevant disadvantages

• Require a greater initial effort: the economic investment they require compared to a traditional architecture is much higher. Mainly because profiles with a lot of experience are needed and a lot of time must be dedicated to writing technical documentation and carrying out complex technical analyses that provide solutions to long-term business needs.
• Require constant monitoring: to prevent the initial approach from being distorted, it is essential to periodically monitor the state of the code, ensure that the guidelines are followed, etc. The teams that usually perform these tasks are often called technical offices. It is not necessary for them to be formed by many people, but it is strictly necessary that they exist.