Introduction
In the early days of mobile application development, architecture design wasn’t a primary concern. Applications were built for limited devices, like PalmOS and WindowsCE, with minimal resources. These apps were often dismissed as “toy apps,” a term famously used by Steve Jobs. At that time, architectural considerations were reserved for complex systems like banking or enterprise software, not mobile apps.
Figure 1. WindowsCE app
Fast forward to today, and the landscape has changed dramatically. Mobile apps have evolved into powerful tools capable of handling tasks like messaging, multimedia editing, and more—all on devices we carry in our pockets. With this evolution comes the need for robust architectures to support increasingly complex functionality and maintainability.
Why Mobile Architecture Matters
The complexity of mobile apps has grown significantly, making architecture design a critical factor in development. A poorly structured app can become a nightmare to maintain, as I experienced firsthand at a previous job.
A simple proof-of-concept (POC) app we developed grew into a full-fledged product, but its lack of architecture made it buggy and hard to extend. Adding features was daunting, and no one wanted to touch the code. This experience highlighted the importance of building systems with thoughtful design and architecture to minimize effort and maximize productivity.
“To build a system that minimizes effort and maximizes productivity, you need to understand which attributes of system architecture contribute to that goal.”
Figure 2. Modular Design
Here’s how we turned things around:
- Create a POC: Test if the app meets client expectations.
- Redesign the Architecture: Organize components and interactions to support maintainability and unit testing.
- Implement the Design: Bring the improved architecture to life.
Popular Mobile Architecture Patterns
Thankfully, we don’t have to reinvent the wheel. Experienced developers have established design patterns to address common challenges, particularly in creating applications with testable, maintainable layers.
MVC: Model-View-Controller
Overview
MVC is one of the earliest architecture patterns, developed in the 1970s at the Palo Alto Research Center. It remains a core design principle for platforms like iOS and frameworks like Ruby on Rails. The goal is to separate concerns among the Model, View, and Controller.
Figure 3. MVC
Components
- Model: Represents the app’s data and business logic. It handles data retrieval and manipulation, encapsulating the application’s core functionality.
- View: Manages the UI elements displayed to the user. The view doesn’t store data but presents it, potentially caching it for performance optimization.
- Controller: Acts as a mediator between the Model and View. It handles user interactions, updates the model, and refreshes the view accordingly.
MVP: Model-View-Presenter
Overview
Introduced by Martin Fowler in 1997, MVP evolved from MVC to address specific challenges. The main difference is the consolidation of the View and Controller into one “chunk,” with the Presenter serving as an intermediary layer.
Figure 4. MVP components
Components
- Model: Functions the same as in MVC.
- View + Controller: Combined into a single entity responsible for UI interactions and user inputs.
- Presenter: Handles business logic, mediates between the View and Model, and facilitates testing by remaining agnostic of service implementations.
MVVM: Model-View-ViewModel
Overview
MVVM is a widely-used pattern, particularly in mobile development, often implemented alongside binding frameworks like RxSwift. This pattern focuses on keeping UI elements synchronized with the underlying data.
Figure 5. MVVM components diagram
Components
- Model: Represents the app’s data and logic.
- View: Displays data to the user.
- ViewModel: Serves as a binding layer between the View and Model, ensuring that the UI remains consistent with application data.
Redux
Overview
Redux, originally developed for web applications, has been adapted for mobile development. It enables a highly testable structure by ensuring that all state changes are predictable and traceable.
Figure 6. REDUX design pattern
Components
- State: A single source of truth for the application’s data.
- Actions: Objects that describe user intentions or system events.
- Reducers: Pure functions that update the state based on actions.
Pros and Cons of These Architectures
MVC
- Pros: Simple and widely supported.
- Cons: Can lead to “Massive View Controllers,” where too much code resides in the controller, reducing testability.
MVP and MVVM
- Pros: Better separation of concerns and improved testability.
- Cons: Increased complexity, with additional layers and boilerplate code.
Redux
- Pros: Exceptional testability and a clear flow of data.
- Cons: Learning curve and added complexity, especially for smaller projects.
Practical Examples of Architecture Use
- MVVM: Microsoft LookGlass
- Redux: Applications like Craftsy, Grailed, and Blink Health.
Conclusion
Choosing the right architecture for your mobile app is crucial for its success. However, adopting complex patterns like MVVM or Redux is not a silver bullet. Before moving to advanced architectures, it’s important to explore and maximize the potential of simpler patterns like MVC. They can often be sufficient with proper implementation.
When transitioning to more complex architectures, weigh the pros and cons carefully. What works for one project might be overkill for another. As you experiment with these patterns, you’ll gain a deeper understanding of how to structure apps that are scalable, maintainable, and robust.
