The document discusses the VIPER architecture, which aims to improve testability of iOS apps by separating concerns into distinct layers. It describes the main components of VIPER - View, Interactor, Presenter, Entity, and Router. The Interactor contains business logic, the Presenter prepares data for the View, and the Router handles navigation. By separating concerns, VIPER allows for easier testing and maintenance of large iOS codebases. It advocates designing the app as independent, reusable modules that conform to the single responsibility principle.

2. VIPER Architecture
By: Ahmed Lotfy

3. VIPER Overview
VIPER Architecture approach
for application development
Clean Architecture divides
logical structure into distinct
layers of responsibility.

4. VIPER Main Goals
Resolve problems. Increase of test coverage for
the Presentation level.
Using Single Responsibility Principle

5. History
●08 - 2012
⚪An article The Clean Architecture by Robert Martin.
●12 - 2013
⚪An article Introduction to VIPER
●06 - 2014
⚪Issue #13. objc.io Architecting iOS Apps with VIPER
●New architecture, introduced on 2014
at Mutual Mobile.

6. History
“We found that writing tests for iOS apps was difficult.
We decided that if we were going to improve the way we
test our software, we would first need to come up with a
better way to architect our apps. We call that method
VIPER”.

7. Note
“VIPER is not the list of rules and templates. It's
the list of recommendations how to build flexible,
testable and reusable architecture.”

8. What is the problem?

9. Old Paradigm
My project is getting larger..
Best Architecture?
Big Project

10. Massive View Controller
●What goes into View Controllers?
Application Flows
Transitions

11. Massive View Controller
Large files (+1000 lines) High complexity Unstructured code

12. Maybe VIPER Will Solve The Problem

13. VIPER Architecture

14. VIPER Components
V(iew) I(nteractor) P(resenter) E(ntity) R(outer)

15. VIPER Components
Components
act like plugins
to use cases.
VIPER is a way of describing:
○ What is the role of each of these
components?
○ How they can interact with one
another?

16. Entity
Contains basic model objects.
Don’t be surprised if your entities are just data
structures.
Entities are only manipulated by the Interactor.

17. Example

18. Interactor
A single use case.
Business logic to Entities to a specific task.
Should be independent of any UI.
The Interactor never passes entities to the presentation
layer.

19. Interactor
The same Interactor could be
used in an iOS app or an OS X
app.
Easy to develop using TDD.

20. Data Manage
Data Manager Role:
⚪ Building fetch requests.
⚪ Store/fetch data from
database.
This allows the Interactor to
focus more on application logic
and not have to know anything
about how. Entities are
gathered or persisted.

21. Interactor Example

22. Example

23. View
Passive Component (UILabel, UITableView, ..).
Determine how the content is displayed.
The Presenter give it contents to display.
It never asks the Presenter for data.

24. Wireframes (Routing)
Own the UINavigationController and UIViewController
Create a View/ViewController and installing it in the
window.
Contain navigation logic for describing which screens are
shown in which order.
Routes from one screen to another are defined here.

25. Example

26. Presenter
●Contain view logic.
●Do not know about UILabel, UIButton, etc.
●Know about the content and when it should be displayed.

27. Presenter
Contain the logic to react to user inputs by requesting
new data from the Interactor.
Receive results from an Interactor and Prepare content
to a form that is efficient to update the UI.
Entities are never passed.
Simple data structures passed.
Use the wireframe to perform the navigation and
present the UI.

28. Example

29. Example

30. Presenter and View
The communicate between Presenter and View by a
higher level of abstraction (a protocol) expressed in
terms of its content,
and not how that content is to be displayed.

31. Presenter and Wireframe
●The Presenter knows:
⚪When to navigate to another screen.
⚪Which screen to navigate to it.
●The wireframe knows:
⚪How to navigate.
⚪Handle navigation transition animations.

32. Presenter and Wireframe
Responsibility for Routing is shared between two
objects: the Presenter, and the wireframe.
Together, they describe a route from one screen to the
next.

33. Example

34. VIPER and Storyboard
VIPER tends not to use segues.
The danger with segues is they make it very difficult to
keep the separation between UI and application logic –
intact.

35. Using VIPER to Build Modules
A screen or set of screens tends to come together as a
module.
A module can be described as a feature.
Good simple way to organize code.
Easy to find a class exactly where you
expected to look for it.

36. Designing your App as a set of Modules
Modules can have very clear and well-defined
interfaces, as well as be independent of other
modules.
This makes it much easier to add/remove features, or to
change the way the interface presents various modules
to the user.

37. Modules
A module might include a common application logic
layer of entities, interactors, and managers that can
be used for multiple screens.
Depends on the interaction between these screens and
how similar they are.
A module could just as easily represent only a single
screen.

38. Testing with VIPER
Separation of concerns makes it
easier to adopt TDD.
The Interactor contains pure logic.
The Presenter contains logic to
prepare data for display.
They are independent of any UI

39. Generarted Tools
iOS Code generation:
Generamba ViperCode
VIPER gen
Boa

40. VIPER vs. MV(C/P)

42. Advantages
Structure:
Lighter and Neat Code!
Stricter classes.
Isolate dependencies.
Separated concerns.
Conforms to “Single Responsibility Principle”.

43. Advantages
Help Team:
Helps developer to be more explicit about separation of
code.
Excellent scalability of the tasks among developers.
●Easier to maintain.
Test:
Easier to test the interactions at the boundaries
between layers (No excuse for making tests).

44. Advantages
Test:
Increase of testability for the application presentation
layer.
Modules are independent from each other. It makes the
separate development environment and increases the
code reusability.
Main architecture approaches are defined. So it's much
easier to add new developer into the team or move
project to another team.

45. Disadvantages
VIPER looks difficult at first, especially for
developers without the team work
experiences on large projects.
Highly increases of the number of class in the
project, as well as the complexity of
creating the new module.
Some principles don't work with UIKit out of
the box (Segue).

46. References
https://www.objc.io/issues/13-architecture/viper/
Swift example.
https://github.com/rambler-digital-solutions/The-Book-
of-VIPER/blob/master/english/introduction-to-
viper.md
http://www.slideshare.net/instinctools_EE_Labs/viper-
architecture-59871979
http://www.slideshare.net/HendyChristianto/introducti
on-to-viper-architecture

47. References
#8 VIPER to be or not to be?
https://brigade.engineering/brigades-experience-using-
an-mvc-alternative-36ef1601a41f#.a0skcve7l
https://github.com/rambler-digital-solutions/The-Book-
of-VIPER/blob/master/english/contents.md
https://8thlight.com/blog/uncle-bob/2012/08/13/the-
clean-architecture.html
Android Templates.

49. Thank you