Applying MVC and PAC patterns in mobile applications

Additional requirements are set for mobile applications in relation to applications for desktop computers. These requirements primarily concern the support to different platforms on which such applications are performed, as well as the requirement for providing more modalities of input/output interaction. These requirements have influence on the user interface and therefore it is needed to consider the usability of MVC (Model-View-Controller) and PAC (Presentation-Abstraction-Control) design patterns for the separation of the user interface tasks from the business logic, specifically in mobile applications. One of the questions is making certain choices of design patterns for certain classes of mobile applications. When using these patterns the possibilities of user interface automatic transformation should be kept in mind. Although the MVC design pattern is widely used in mobile applications, it is not universal, especially in cases where there are requirements for heterogeneous multi-modal input-output interactions.

💡 Research Summary

The paper investigates how the distinctive requirements of mobile applications influence the suitability of two classic user‑interface architectural patterns: Model‑View‑Controller (MVC) and Presentation‑Abstraction‑Control (PAC). Mobile environments differ from desktop ones in three major ways: they must run on a heterogeneous set of operating systems and devices, they must accommodate a wide range of screen sizes and resolutions, and they increasingly rely on multimodal interaction channels such as touch, voice, gestures, and sensor data. These factors put pressure on the separation of concerns between the user interface and the business logic, a separation that both MVC and PAC aim to achieve but in fundamentally different ways.

The authors first describe the structural composition of each pattern. MVC consists of a Model (data and business rules), a View (the visual representation), and a Controller (the mediator that interprets user input and updates the Model and View). In practice, the View and Controller tend to be tightly coupled; when a View must be adapted for a new screen size or a new input modality, the Controller often needs to be altered as well, limiting reuse. PAC, by contrast, organizes the system into three loosely coupled layers: Presentation (the concrete UI for a specific modality), Abstraction (the core domain logic), and Control (the glue that routes events between Presentation and Abstraction). Because each Presentation module can be built independently for a particular device or interaction style, the underlying business logic remains untouched when new modalities are added.

To evaluate the practical impact of these differences, the paper presents two case studies. The first is a simple note‑taking app that uses a single touch‑based interface on a single platform. Here MVC shines: the pattern is straightforward, widely supported by mobile SDKs, and requires minimal boilerplate. The second case study is a smart‑home controller that must run on smartphones, tablets, and wearables while accepting voice commands, touch gestures, and sensor‑driven inputs simultaneously. In this scenario PAC demonstrates clear advantages: each modality is encapsulated in its own Presentation component, the Control layer mediates uniformly to a single Abstraction, and the overall code base avoids duplication and excessive conditional logic. The authors also discuss automatic UI transformation (responsive design). MVC typically embeds platform‑specific adjustments inside the View, making automated transformation cumbersome. PAC’s clear contract between Presentation and Abstraction allows developers to swap out only the Presentation layer for a new device, preserving the rest of the system.

Based on these observations, the authors propose a three‑dimensional decision matrix that rates an application along the axes of size (small, medium, large), modality complexity (low, medium, high), and platform diversity (single, few, many). The matrix guides developers toward MVC for small, single‑modality, single‑platform projects, and toward PAC for large, multimodal, multi‑platform projects. The matrix also incorporates organizational factors such as team expertise and existing code bases, acknowledging that MVC remains dominant in many current mobile frameworks (e.g., iOS UIKit, Android Jetpack) while newer patterns like MVVM and MVI borrow concepts from PAC.

In conclusion, the paper argues that the choice between MVC and PAC should not be made on popularity alone. While MVC is still the default for many straightforward mobile apps, the growing demand for multimodal interaction and seamless UI adaptation makes PAC—or hybrid approaches that blend PAC’s decoupling with MVC’s simplicity—an increasingly compelling option. The authors suggest future work on tooling that can generate PAC‑compliant scaffolding automatically and on architectural hybrids that allow a gradual migration from MVC to PAC as application requirements evolve.