Native Mobile App Architecture: MVC, MVVM, HMVC & Layered Patterns

Native app development cycles are much shorter than traditional projects, and requirements change frequently; using appropriate architectural patterns at different lifecycle stages can save development time and improve efficiency.

Presentation Layer

Basic MVC

Mobile apps typically adopt the classic MVC architecture.

Summary:

C → M: API C → V: Outlet V → C: Target‑action, Delegate, DataSource M → C: Notification, KVO

MVC Improved: MVVM

MVVM adds a ViewModel that contains presentation logic, converting model data into a form suitable for the view; it is suitable for apps with extensive data display.

HMVC

Hierarchical MVC decomposes the client application into a hierarchy of parent‑child MVC modules, repeatedly applying the pattern to form a structured client architecture, suitable for heavyweight B/S web apps.

A MVC module abstracts a part of the application; a key concept is the Parent MVC, which can correspond to UI elements such as tab bars, toolbars, navigation bars, or abstract objects. For example, an app’s bottom tab bar is Layer 1, the navigation bar is Layer 2, the main workspace is Layer 3, and the toolbar can be another layer.

The Controller acts as the central coordinator, communicating with child or parent Controllers and notifying its View to update the UI, while the Model handles business logic or data access. For instance, when a toolbar button is tapped, the toolbar’s Controller forwards the event to its parent Controller, which may further propagate it up the hierarchy until the appropriate Controller handles the view switch.

Advantages:

Reduces dependencies by dividing the program into separate parts. Encourages code, component, or module reuse. Improves extensibility for future maintenance.

Layered Design

Three‑Layer Architecture

The classic three‑tier architecture consists of:

Presentation Layer (UI) Business Logic Layer or Domain Layer (BLL) Data Access Layer (DAL)

Our current architecture extends this model as shown below:

Four‑Layer Architecture

Adding a Business Rules layer on top of the three‑tier model separates validation of user input and database errors, clarifying the Business Logic layer and allowing logic engineers to focus on core logic.

From top to bottom:

Presentation Layer Business Rules Layer Business Logic Layer or Domain Layer Data Access Layer

Five‑Layer Architecture

When business logic resides in the middle layer, many diverse classes are called from the presentation layer, increasing its complexity and coupling. Introducing a Facade (Business Facade layer) unifies these calls.

From top to bottom:

Presentation Layer Business Facade Layer Business Rules Layer Business Logic Layer or Domain Layer Data Access Layer

Introducing Service Layer

The Service layer differs from ordinary layered architectures by containing its own data and being able to run independently.

Presentation Layer Service Layer Data Access Layer Business Logic Layer