Good mobile app architecture is the foundation of all well-designed software and can provide excellent user experience. However, when it comes to mobile applications or platforms, there’s always been a problem with a good architecture. In the case of Android, it might be because Google doesn’t support or even recommend any specific architecture. Apple, on the other hand, suggested the MVC architecture for UIKit, but their proposal aroused a lot of controversy and many experts claimed it was not a good solution.
In this blogpost we’ll try to figure out what makes a good architecture for mobile app development.
What makes a good mobile app architecture
Good mobile application architecture is one that will enforce assumptions and good programming patterns like SOLID, KISS, or ensuring that components have multiple responsibility layers. Meeting these conditions allows you to accelerate development and make future maintenance much easier, thus saving you time and money.
A wisely selected architecture together with platform-specific technology (like Swift for iOS or Kotlin for Android) will be the best for resolving complex business problems in most effective way for mobile projects. This will allow you to avoid many problems resulting from the quirks of hybrid technologies. It will definitely be a time- and money-saving approach in the long term.
Additionally, a good architecture should be so abstract that it can be applied on various platforms - like iOS or Android. Thanks to such an assumption, the common goal can be achieved in a unified way, which will result in more time efficiency. One of the most crucial features of a good architecture is responsibility layer separation. Such a division will be key to reducing the context and extent of errors.
One of the most popular multilayer architectures is a three-layer architecture shown in the diagram below:
Example of mobile architecture usage
A clearly defined architecture makes work easier and faster. Developers and managers have better control over the work and the data flow in the application. It makes testing more efficient and increases the quality of both management and the product.
Looking at a three-layer model (graph above) you can see that implementation of each of the layers will be dependent on its purpose or project scope.
The presentation layer
The presentation layer depends on screen designs and their behaviour. Business logic, on the other hand, depends on what kind of data will be provided by the data layer and how this data needs to be processed to match the presentation layer’s requirements. Finally, the data layer will be responsible for managing the sources of data, synchronizing them, and providing it to the higher levels.
The data layer
It has the most specified scope, making it the perfect starting point for optimizations. To start optimization of the data layer we need to select a programming pattern that will solve common problems and make our work much easier and faster. The most optimal pattern for mobile projects for the data layer will be the so-called Repository pattern, which is shown below:
The Repository pattern
It is one of many examples of patterns for data layers. As the mobile team at Netguru, we consider it a perfect solution for large mobile projects because it resolves the problem of managing multiple data sources and mapping data entities to data models used by business logic components.
Applying such an approach (a well-known pattern) solves another group of problems out-of-the-box. Using the Repository pattern in this case will allow you to create logic that will be responsible for providing well-mapped data for the business layer and all specific implementation of data sources can be easily replaced without any impact on the business logic layer. Again, we saved time and money through a well-chosen pattern.
The example data layer presented above is one of many. Similar solutions can also be found for presentation layers, such as MVP, MVVM, MVI etc. This will make work easier by resolving another group of problems in a different field.
Why we underestimate mobile app architecture
In recent years, the approach to mobile app architecture has improved. Developers pay more attention to proven patterns and standards, but there are still many engineers who don’t follow the best practices. Many mobile apps were created with low quality source code and without any architecture or they’re even based on antipatterns. Such custom applications are really hard to maintain and develop further. Bad architecture can drastically increase the time and cost of development.
Many sources also recommend finding an alternative approach to native enterprise mobile development, which is often seen as time-consuming and problematic. In native development, you need at least two developers - each for one platform, so why not opt for cross-platform development with e.g. React Native? Hybrid technologies indeed let us cut down costs, but they are not the right fit for all of applications. Ignoring this may lead to many problems in mobile application architecture.
Problems with mobile application architecture
Choosing the right architecture should be an obligatory step and a primary element in the design and planning phase of software development. However, as a result of developers' negligence, rush, lack of experience and knowledge, or neglect of suppliers (e.g. Google), architecture is often overlooked. The lack of architecture in applications (not only mobile) causes major problems with software:
- It will be more error prone;
- It will be difficult to develop and to maintain;
- Code is less readable;
- Having many developers work on it at the same time can be difficult;
- Source code without architecture or design patterns is harder to test, which results in missing unit tests of key functionalities. Lack of tests causes difficulties with maintaining the software (e.g. no regression control, much harder refactoring or bug fixing, etc);
- And many more.
Developing a software project without architecture or design patterns can be compared to building without foundations - the bigger the building, the more problems this will cause.
At the beginning, inexperienced developers or managers oftentimes see an approach without architecture as faster. However, very soon it turns out to be a dead end. Often it is too late to add architecture or patterns to such code. Along with the increase of size and complexity of the project, these problems accumulate.
Well-selected architecture for mobile app
A well-chosen architecture saves a lot of problems with maintenance and development. It also gives structure to both the development process and the project as a whole. It is very important during developing and maintaining a project, as it helps you improve or fix non-existent or poor architecture. This is also why we believe that choosing an architecture should be an integral part of the planning phase of every software project.
We hope that these few tips will facilitate the custom development of your application or project and save you a lot of time. We care about well-selected architecture in all projects, including mobile ones, so if you’d like to discuss it with our experts, just drop us a message.