(String: {%- set hs_blog_post_body -%} {%- set in_blog_post_body = true -%} <span id="hs_cos_wrapper_post_body" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_rich_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="rich_text"> <div class="blog-post__lead h3"> <p data-renderer-start-pos="729">Clean Swift (VIP) was first introduced by Raymond Law on his website&nbsp;<a target="_blank" href="https://clean-swift.com/" title="https://clean-swift.com/" data-renderer-mark="true" rel="noopener">clean-swift.com</a>. The idea behind it was to tackle the Massive view controller problem while following the main ideas found in Uncle Bob’s <a target="_blank" href="http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html" title="http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html" data-renderer-mark="true" rel="noopener">Clean Architecture</a>.</p> </div></span>)

Clean Swift (VIP) iOS Architecture Pattern

Photo of Patryk Strzemiecki

Patryk Strzemiecki

Updated Feb 21, 2024 • 17 min read
woman in front of a computer

Clean Swift (VIP) was first introduced by Raymond Law on his website clean-swift.com. The idea behind it was to tackle the Massive view controller problem while following the main ideas found in Uncle Bob’s Clean Architecture.

Quick overview

When implementing a Clean Swift project your code will be structured around each of your application screens or segments of screens, also known as “scenes”.

In theory, each scene is a structure with around 6 components:

  • View Controller,

  • Interactor,

  • Presenter,

  • Worker,

  • Models,

  • Router.

The view controller, interactor, and presenter are the three main components of Clean Swift. They act as input and output to one another as shown in the following diagram.

view controller interactor presenter cycle

The output of the view controller is connected to the input of the interactor. The output of the interactor is connected to the input of the presenter. The output of the presenter is connected to the input of the view controller. This means the flow of control is always unidirectional.

Example

Imagine a screen with a login button. It's a Scene that defines a structure with a VIP cycle of View Controller, Interactor, and Presenter. When the user taps the button, the View Controller calls the interactor. The interactor uses the business logic inside to prepare an output (with the use of workers). It then propagates the result to the presenter. The presenter calls the VC’s method to call the router to display a new scene.

View Controller

  • Defines a scene and contains a view or views.

  • Keeps instances of the interactor and router.

  • Passes the actions from views to the interactor (output) and takes the presenter actions as input.

protocol LoginSceneViewControllerInput: AnyObject {
func showLogingSuccess(fullUserName: String)
func showLogingFailure(message: String)
}

protocol LoginSceneViewControllerOutput: AnyObject {
func tryToLogIn()
}

final class LoginSceneViewController: UIViewController {
var interactor: LoginSceneInteractorInput?
var router: LoginSceneRoutingLogic?

private var loginButton: UIButton = {...}()
}

private extension LoginSceneViewController {
@objc func loginButtonAction() {
interactor?.tryToLogIn()
}
}

extension LoginSceneViewController: LoginSceneViewControllerInput {
func showLogingSuccess(fullUserName: String) {
router?.showLoginSuccess()
}

func showLogingFailure(message: String) {
router?.showLogingFailure(message: message)
}
}

Interactor

  • Contains a Scene’s business logic.

  • Keeps a reference to the presenter.

  • Runs actions on workers based on input (from the View Controller), triggers and passes the output to the presenter.

  • The interactor should never import the UIKit.

typealias LoginSceneInteractorInput = LoginSceneViewControllerOutput

protocol LoginInteractorOutput: AnyObject {
func showLogingSuccess(user: CleanLoginUser)
func showLogingFailure(message: String)
}

final class LoginSceneInteractor {
var presenter: LoginScenePresenterInput?
var authWorker: LoginSceneAuthLogic?
}

extension LoginSceneInteractor: LoginSceneInteractorInput {
func tryToLogIn() {
authWorker?.makeAuth(completion: { result in
DispatchQueue.main.async { [weak self] in
switch result {
case .success(let data):
self?.presenter?.showLogingSuccess(user: data)
case .failure(let error):
self?.presenter?.showLogingFailure(message: error.localizedDescription)
}
}
})
}
}

Worker

  • An abstraction that handles different under-the-hood operations like fetch the user from Core Data, download the profile photo, allows users to like and follow, etc.

  • Should follow the Single Responsibility principle (an interactor may contain many workers with different responsibilities).

protocol LoginSceneAuthLogic {
func makeAuth(
completion: @escaping (Result<CleanLoginUser, LoginSceneAuthWorker.LoginSceneAuthWorkerError>
) -> Void)
}

final class LoginSceneAuthWorker {
private let service: AuthService
private var bag = Set<AnyCancellable>()

init(service: AuthService) {
self.service = service
}

enum LoginSceneAuthWorkerError: Error {
case authFailed(String)
case unauthorized
}
}

extension LoginSceneAuthWorker: LoginSceneAuthLogic {
func makeAuth(
completion: @escaping (Result<CleanLoginUser, LoginSceneAuthWorkerError>
) -> Void) {
service.auth()
.sink { _ in } receiveValue: { value in
switch value.authorized {
case true:
completion(.success(CleanLoginUser()))
case false:
completion(.failure(.unauthorized))
}
}
.store(in: &bag)
}
}

Presenter

  • Keeps a weak reference to the view controller that is an output of the presenter.

  • After the interactor produces some results, it passes the response to the presenter. Next, the presenter marshals the response into view models suitable for display and then passes the view models back to the view controller for display to the user.

typealias LoginScenePresenterInput = LoginInteractorOutput
typealias LoginScenePresenterOutput = LoginSceneViewControllerInput

final class LoginScenePresenter {
weak var viewController: LoginScenePresenterOutput?
}

extension LoginScenePresenter: LoginScenePresenterInput {
func showLogingFailure(message: String) {
viewController?.showLogingFailure(message: "")
}

func showLogingSuccess(user: CleanLoginUser) {
viewController?.showLogingSuccess(fullUserName: user.firstName + " " + user.lastName)
}
}

Router

  • Extracts this navigation logic out of the view controller.

  • Keeps a weak reference to the source (View Controller).

protocol LoginSceneRoutingLogic {
func showLoginSuccess()
func showLogingFailure(message: String)
}

final class LoginSceneRouter {
weak var source: UIViewController?

private let sceneFactory: SceneFactory

init(sceneFactory: SceneFactory) {
self.sceneFactory = sceneFactory
}
}

extension LoginSceneRouter: LoginSceneRoutingLogic {
func showLogingFailure(message: String) {
source?.present(UIAlertController.failure(message), animated: true)
}

func showLoginSuccess() {
let scene = sceneFactory.makeLoginScene()
source?.navigationController?.pushViewController(scene, animated: true)
}
}

Configurator

  • Takes the responsibility of configuring the VIP cycle by encapsulating the creation of all instances and assigning them where needed.
protocol LoginSceneConfigurator {
func configured(_ vc: LoginSceneViewController) -> LoginSceneViewController
}

final class DefaultLoginSceneConfigurator: LoginSceneConfigurator {
private var sceneFactory: SceneFactory

init(sceneFactory: SceneFactory) {
self.sceneFactory = sceneFactory
}

@discardableResult
func configured(_ vc: LoginSceneViewController) -> LoginSceneViewController {
sceneFactory.configurator = self
let service = DefaultAuthService(
networkManager: DefaultNetworkManager(session: MockNetworkSession())
)
let authWorker = LoginSceneAuthWorker(service: service)
let interactor = LoginSceneInteractor()
let presenter = LoginScenePresenter()
let router = LoginSceneRouter(sceneFactory: sceneFactory)
router.source = vc
presenter.viewController = vc
interactor.presenter = presenter
interactor.authWorker = authWorker
vc.interactor = interactor
vc.router = router
return vc
}
}

Model

  • Decoupled data abstractions.

Full schema


clean swift full schema VIP cycle

Other

To avoid memory leaks always pass the view controller to the router and presenter as a weak reference.

I’m not the biggest fan of the official implementation guide. I encourage you to check the sample project of CleanStore. Or just follow the examples above (examples are from my sample project on GitHub).

Key Rules

  • Keep the file structure (follow the Scene naming).

    clean swift files structure
  • Use VIP cycle and input/output protocols:

    • The view controller accepts a user event, constructs a request object, and sends it to the interactor.

    • The interactor does some work with the request, constructs a response object, and sends it to the presenter.

    • The presenter formats the data in the response, constructs a view model object, and sends it to the view controller.

    • The view controller displays the results contained in the view model to the user.

Recommendations

  • Projects where unit testing is expected.

  • Long-term and big projects.

  • Projects with a generous amount of logic.

  • Projects you want to reuse in the future.

  • When MVVM, MVP, MVC are not enough or you just hate VIPER but there is a need to introduce a sophisticated architecture.

  • Native and imperative projects.

Strengths

  • Easy to maintain and fix bugs.

  • Enforces modularity to write shorter methods with a single responsibility.

  • Nice for decoupling class dependencies with established boundaries.

  • Extracts business logic from view controllers into interactors.

  • Nice to build reusable components with workers and service objects.

  • Encourages to write factored code from the start with fast and maintainable unit tests.

  • Applies to existing projects of any size.

  • Modular: Interfaces may be easy to change without changing the rest of the system due to using protocol conformant business logic

  • Independent from the database.

Disadvantages and traps

  • Many protocols with complicated naming and responsibilities, at first it may be confusing where the protocol is defined.

  • Large app size due to many protocols.

  • Despite the fact that there is an official website of Clean Swift architecture, it changes often and implementations may differ between projects.

  • It’s hard to maintain the separation between VC and presenter. Sometimes the presenter just calls the view methods instead of preparing the UI, so it seems useless and just creates boilerplate.

Learning materials

Summary

Clean Swift is not the easiest to maintain, but possibly the best to avoid coupling and be able to keep a high code coverage score.
The VIP cycle enforces a strict naming convention and class responsibilities with a medium amount of boilerplate code.

Would you like to see a simple example of Clean Swift architecture?
Check my sample project ‘CleanLogin’ on GitHub.

Clean Swift Clean Login app coverage example

Photo of Patryk Strzemiecki

More posts by this author

Patryk Strzemiecki

Senior iOS Developer
Codestories Newsletter  Check what has recently been hot in European Tech.   Subscribe now

We're Netguru!

At Netguru we specialize in designing, building, shipping and scaling beautiful, usable products with blazing-fast efficiency
Let's talk business!

Trusted by: