Mobile App Architecture
Selecting the right architecture is a critical decision in mobile app development. It directly influences your app’s testability, scalability, and long-term maintainability. Let’s explore some common architectural patterns and examine how evolving platform ecosystems — Android and iOS — shape these choices.
Comparing Architectural Patterns
Model-View-Controller (MVC)
- Overview: Divides the application into three components: Model, View, and Controller.
- Pros: Simple to understand and implement.
- Cons: The Controller often becomes a catch-all for logic, making unit testing and maintenance challenging.
Model-View-Presenter (MVP)
- Overview: Separates the Presenter from the View, allowing business logic to be tested independently.
- Pros: Enhanced testability compared to MVC.
- Cons: Lacks inherent support for reactive, real-time data updates, which can limit its use in dynamic applications.
Model-View-ViewModel (MVVM)*
- Overview: Introduces a ViewModel that mediates between the Model and the View.
- Pros: Supports both testability and reactivity through data binding, enabling automatic UI updates.
- Cons: While it leverages unidirectional data flow, the state remains mutable. This can lead to complications in state management and debugging.
Model-View-Intent (MVI)*
- Overview: Builds on previous patterns by incorporating immutable state management and unidirectional data flow.
- Pros: Offers improved predictability and simplified debugging, as changes are modeled as immutable data objects.
- Cons: Adoption might require a steeper learning curve, especially for teams new to reactive programming paradigms.
*Note: Using MVVM/MVI on iOS is increasingly misaligned with Apple’s evolving ecosystem. With the advent of SwiftData — designed specifically to work with SwiftUI — the traditional MV* pattern shows limitations, as it tends to complicate rather than simplify integration with new tools.
Platform Perspectives
Android — From Fragmentation to Clarity
Past Development
In the early days of Android, the lack of standardized guidelines led to a fragmented landscape of languages, tools, and design principles. Developers received little direction on structuring an Android app, and it was often said that Android is not a complete platform. Instead of having a unified framework, developers had to integrate various popular libraries just to build a simple production app. Even the four primary Android app components — Activities, Services, Broadcast Receivers, and Content Providers — serve more as a contract between the OS and the application rather than as true building blocks. This meant that with every new app, developers often had to reconstruct the fundamentals, leading to confusion over which libraries and architectures to choose. The varying quality and approach of these libraries fueled conflicting opinions on how best to build an Android app (e.g., debates like “#performance matters” vs. “#enums matter”).
Note: Using community open source libraries and tools to build Android apps, before the introduction of Android Architecture components. Watch the talk here
Current Development
Google has since addressed these challenges with the release of Jetpack — a comprehensive suite of libraries that resolves many of the longstanding pain points in Android development. Jetpack provides:
- Foundation Components: Core system capabilities, Kotlin extensions, multidex support, and automated testing.
- Architecture Components: Tools for managing UI lifecycles, handling data persistence, and more. Components like Room, Lifecycle-aware classes, ViewModels, and Kotlin Flow work individually to address specific issues (persisting data, managing lifecycles, modularization, error reduction) and collectively form a cohesive app architecture.
- Behavior Components: Aid in designing robust, testable, and maintainable applications.
- UI Components: Facilitate the creation of intuitive and delightful user experiences.
These components create a common language and framework that empower developers to build high-quality, maintainable apps that are well-aligned with future tool releases.
Today, with clear architectural guidelines and best practices, Google has transformed Android development, enabling developers to create robust and consistent applications that stand the test of time.
How we build Android @ YLabZ …
iOS: Navigating a Shifting Landscape
Initially, Apple promoted the MVC pattern, but as app complexity grew, many developers transitioned to MVVM. The advent of new technologies — Swift, SwiftUI, structured concurrency, Combine, and now SwiftData — has upended established norms. SwiftData is designed to integrate seamlessly with SwiftUI, forming a tightly coupled ecosystem of tools and libraries for future app development. However, continuing to use MVVM can leave developers at odds with this integrated ecosystem, leading to compatibility challenges as Apple releases new technologies. Clear, authoritative guidance from Apple is crucial so that developers can adopt an architectural pattern that is future-proof, allowing them to fully leverage forthcoming tools without having to re-engineer their apps.
Case Study
The ViewModel Debate — Is the View Actually the ViewModel?
Two prominent voices in the iOS community offer contrasting perspectives:
Mohammad Azam:
A seasoned iOS expert and educator, Azam argues that SwiftUI does not need a ViewModel. His extensive writings on AzamSharp and his comprehensive SwiftData guides emphasize that trying to force MVVM into a SwiftData context often leads to unnecessary complexity.
Key Insights from Azam:
- SwiftData Integration: In sample SwiftData applications from WWDC23 (such as Apple’s “Backyard Birds” app), there is little to no evidence of a traditional ViewModel layer. Instead, the architecture often leans towards variations of the Active Record Pattern or container-based approaches.
- Multiple Architectural Patterns: Since 2019, Azam has experimented with MVVM, Container, Redux, MV, and Active Record patterns when building SwiftUI applications, ultimately finding that MVVM complicates SwiftData integration.
Since 2019, I have used many different architectural patterns when building SwiftUI applications. This included MVVM, Container pattern, Redux, MV pattern and Active Record Pattern. Apple has a sample SwiftData application called Backyard Birds: Building an app with SwiftData and widgets, which uses a variation of Active Record Pattern.
Paul Hegarty & Paul Hudson:
Paul Hegarty, a well-known Stanford instructor, continues to endorse the MVVM pattern. (Not including SwiftData in his classes)
However, Paul Hudson (of Hacking with Swift) has remarked that using MVVM with SwiftData “works really badly” at least in its current state. Hudson notes that while this might improve in the future, at present, integrating SwiftData into an MVVM architecture is nearly impossible.
Hacking with Swift (Paul Hudson) Why he does not use MVVM with SwiftData
“It works really badly with SwiftData, at least right now. This might improve in the future, but right now using SwiftData is basically impossible with MVVM.”
In summary, the debate underscores a critical point: the view might very well be the ViewModel in a SwiftUI/SwiftData world. This evolving perspective challenges traditional architectural boundaries and reinforces the need for Apple to provide clear, future-proof architectural guidance. Without such direction, developers risk building applications that become increasingly misaligned with the native evolution of the platform.
The Need for Clear Architectural Guidance
The underlying issue is not just the merits or demerits of any single pattern — it’s about future-proofing your app. Both Apple and Google are evolving their platforms with interconnected tools and libraries designed to work seamlessly together. If developers persist with outdated or misaligned patterns (such as MVVM on iOS), they risk creating applications that are difficult to maintain and incompatible with future releases. Therefore, it is imperative for platform providers to offer definitive architectural guidance. With clear directions, developers can make informed decisions that ensure long-term compatibility and enable them to harness the full potential of future innovations.
Conclusion
Understanding the nuances of various architectural patterns is key to building mobile applications that are robust, scalable, and maintainable. As both Android and iOS evolve, the need for cohesive, future-oriented architectural guidelines becomes ever more critical. For iOS developers, the introduction of SwiftData — and its seamless integration with SwiftUI — highlights that clinging to traditional patterns like MVVM might soon become a liability. Developers need clear, authoritative guidance from platform providers to choose an architecture that not only meets today’s demands but also aligns with the future trajectory of these platforms. This will ensure that the tools and libraries released in the future can be adopted smoothly, keeping apps both modern and maintainable.
We are actively talking with both Google (Android) & Apple (iOS) about best practices
~Ash
P.S>
With all this evolution one last piece still needs to be addressed.
Mobile development has evolved from the early days when most apps had no architecture, no design, and no real functionality. To remedy this we started to focus on the quality of code which has been addressed with JetPack Architecture components. Then we focused on UX/UI which has been addressed by JetPack Material components, but now we need to focus on designing the right product. Too many times developers have a great architecture with great UX/UI but built a product that does not fit the market. I believe once we address this last piece of mobile development we will be in great shape.
GNSeven is our solution:
We currently utilize materials from d.school@Stanford and ThinkWithGoogle:
