Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 16

VIPER Architecture: Roles and Responsibilities

Recommended resources

Hello! Welcome to the next lesson in our module on Advanced Architecture and Navigation.

In our last session, we explored the high-level principles of Clean Architecture, focusing on the Dependency Rule and the roles of Entities, Use Cases, and Presenters. We established that the core idea is to create a system with independent, testable layers by ensuring dependencies only point inwards.

Today, we will build directly on that foundation by examining VIPER, a concrete architectural pattern that is a strict implementation of Clean Architecture for iOS. By the end of this lesson, you will be able to describe the roles of the View, Interactor, Presenter, Entity, and Router in the VIPER architecture.

From Clean Architecture to VIPER

VIPER is a backronym for View, Interactor, Presenter, Entity, and Router. It was created to address the common "Massive View Controller" problem in iOS development by providing a clear and distinct separation of responsibilities.

The concepts from Clean Architecture map almost directly to VIPER:

  • Clean Architecture's Entities are VIPER's Entities.
  • Clean Architecture's Use Cases are VIPER's Interactors.
  • Clean Architecture's Presenters are VIPER's Presenters.

VIPER formalizes two other key responsibilities: handling the UI (View) and managing navigation (Router).

To understand this connection and the motivation behind VIPER, let's start with a foundational article.

Architecting iOS Apps with VIPER - objc.io

This article from objc.io is one of the definitive original sources on VIPER. It clearly explains how VIPER is an application of Clean Architecture designed to improve testability and maintainability in iOS apps.

Please read the first section of the article, down to 'Application Design Based on Use Cases'. Focus on how VIPER's layers are proposed as a solution to the 'Massive View Controller' issue.

The Roles of the Five VIPER Components

Now, let's define the role of each component. As you'll see, each one has a single, well-defined responsibility. This conforms to the Single Responsibility Principle and is the key to VIPER's power.

First, watch this short video for a quick overview of what each of the five components does.

Swift: VIPER Design Pattern (Architecture, 2023, Xcode 14, Swift 5) - iOS Development

This video from iOS Academy provides a concise introduction to each part of the VIPER acronym. It will give you a high-level mental map before we examine each component in more detail.

Watch the segment from 03:23 to 05:59. As you watch, note the primary job of the View, Interactor, Presenter, Entity, and Router.

Now that you have a general idea, let's formalize those definitions. The following table summarizes the core responsibility of each component, based on the classic definitions.

Component Core Responsibility
View Displays what the Presenter tells it to and relays user input back to the Presenter. It is passive and "dumb".
Interactor Contains the business logic for a specific use case (e.g., fetching data, performing a calculation).
Presenter Acts as the "glue". It receives user input from the View, requests data from the Interactor, and formats the data for display in the View.
Entity Represents the basic model objects (the "what," not the "how"). These are manipulated by the Interactor.
Router Handles navigation logic, such as pushing a new view controller or presenting a modal. Also assembles the module.

For a more detailed breakdown, the objc.io article is an excellent resource.

Architecting iOS Apps with VIPER - objc.io

Let's dig deeper into the precise responsibilities of each component with the same objc.io article. It provides clear, practical explanations for each role.

Read the sections titled 'Interactor', 'Entity', 'Presenter', 'View', and 'Routing'. As you read, notice how the Interactor is independent of the UI and how the Presenter never passes raw Entities to the View.

Visualizing the Connections

Understanding the roles is the first step. The second is seeing how they all connect. The following diagram illustrates the relationships between the components.

VIPER Architecture Diagram with Reference Types
This diagram shows the five main components of a VIPER module. Pay close attention to the direction of the arrows, which indicate who holds a reference to whom. Also, note the labels for 'strong' and 'weak' references—this is critical for preventing retain cycles, a topic we covered earlier in the course.

From the diagram, we can see the typical communication flow:

  1. A user action happens in the View.
  2. The View notifies the Presenter.
  3. The Presenter decides what to do. It might ask the Router to navigate, or it might ask the Interactor for data.
  4. The Interactor performs its business logic (e.g., fetching data from a network service and creating Entities).
  5. The Interactor returns the result to the Presenter.
  6. The Presenter formats the data from the Entities into a display-friendly format and tells the View to update.

Communication via Protocols

A crucial aspect of VIPER is that components communicate through protocols (or interfaces). This enforces the Dependency Rule we learned about and keeps the components decoupled and independently testable. For example, the Presenter doesn't know about UIViewController; it only knows about a protocol that the UIViewController conforms to, like HomeViewProtocol.

This next video explains these communication pathways clearly.

VIPER Architecture in iOS (Swift)

This video does an excellent job of illustrating how protocols act as the contracts between the different VIPER layers, enabling clean and decoupled communication.

Please watch from 06:33 to 08:17. Focus on understanding the different 'protocol pairs' used for communication, such as the two protocols needed for the View-Presenter relationship (one for View -> Presenter calls, and one for Presenter -> View calls).

Conclusion

In this lesson, we dissected the VIPER architecture and defined the specific role of each of its five components. You saw how VIPER is a direct and strict application of Clean Architecture principles, designed to create highly modular and testable iOS applications.

Key Takeaways:

  • View: The passive UI layer, implemented by a UIViewController or UIView. It forwards user events to the Presenter.
  • Interactor: The heart of the business logic for a single use case. It is UI-agnostic and manipulates Entities.
  • Presenter: The central coordinator. It processes user input, fetches data via the Interactor, formats it for display, and updates the View.
  • Entity: Simple, plain data objects representing the core domain models. They contain no business logic.
  • Router: Responsible for all navigation logic and for assembling the VIPER module's components.
  • Communication: Components are decoupled using protocols, which define clear boundaries and enable independent testing.

Preview of the Next Lesson:
Theory is essential, but practice solidifies understanding. In our next lesson, we will move from "what" to "how" by implementing a single VIPER component: the Interactor. We will take a feature's business logic and encapsulate it within an Interactor, putting what we've learned today directly into code.