At Qonto, Xcode migrations used to paralyze our 60+ iOS engineers for 3+ weeks. Today we complete them in 1 day without disrupting anyone’s work. The secret? We removed CocoaPods entirely, built Swift-based automation tools, and created proactive monitoring instead of reactive chaos. Result: 75% faster migrations with zero team disruption.

Read the complete story here: https://medium.com/qonto-way/xcode-migrations-from-stone-age-to-ai-mastery-d2590657e809

In this article, we will explore the modern approach to localizing strings in an iOS application. We will delve into Apple’s Foundation frameworks related to localization and learn how to effectively use them.

The source code for this article is open source and available on GitHub. You can also read more about this topic on my personal blog.️

Motivation

Recently, I have been working on an iOS application and sought an easy way to make it accessible to a global audience. While SwiftUI simplifies the process, I found myself puzzled by the various methods available for localizing text.

The Fun Way to Work with Strings

It all started simply. In my Localizable.xcstrings catalog, I have a key named main.onboarding.title.label, which I plan to use in a Text view on my main screen.

The main screen is built using SwiftUI and features a straightforward card containing an Image and a Text view.

struct MainView: View {
    var body: some View {
        VStack {
            Image(systemName: "sun.max.fill")
            Text("main.onboarding.title.label")
            ...
        }
        ...
    }
}

When I build the project, I automatically receive the key main.onboarding.title.label, as shown in the previous image.

So far, so good. I can easily navigate to my Strings catalog, add a new language, and select French.

This process is seamless; you don’t need to worry about the underlying mechanics. You can add your key in the UI element, build the project, go to your Strings catalog, translate it, and you’re done.

Here is the complete main screen of the app displayed in both French and English languages.

Understanding Localization is Hard

As an iOS developer, you may encounter various methods for translating text in larger projects.

In one project, you might see this:

let title = LocalizedStringResource(stringLiteral: "weird.text")

In another project, you could come across:

let petDetailsScreenTitleKey = LocalizedStringKey("dog.details.title")

Or this:

let alertTitle = String(localized: "login.alert.title.label")

In older projects, you might find strings localized like this:

let commentBoxText = NSLocalizedString(
    "comment.box",
    comment: "Users enter their comment in this box."
)

And one more example:

let placeholderLocalizationValue = String.LocalizationValue(
    "textfield.placeholder"
)

That’s too much. What are these functions and classes doing to my lovely String?
Is my String even a String anymore or it lost the authenticity?!
Who knows?!

Cracking the Code

Don’t worry; things will become clearer shortly.

Let’s apply all of these localization methods to our key defined at the beginning of the article:

static let localizationValue = String.LocalizationValue(
    "main.onboarding.title.label"
)
static let localizationStaticString: StaticString = "main.onboarding.title.label"

let localizedResourceWithStringLiteral = LocalizedStringResource(
    stringLiteral: "main.onboarding.title.label"
)

let localizedResourceWithLocalizationValue = LocalizedStringResource(
    localizationValue
)

let localizedResourceWithStaticString = LocalizedStringResource(
    localizationStaticString,
    defaultValue: localizationValue
)

let localizedString = String(localized: "main.onboarding.title.label")

let localizedStringKey = LocalizedStringKey("main.onboarding.title.label")

let localizedStringOldWay = NSLocalizedString(
    "main.onboarding.title.label",
    comment: "Used to show the onboarding title."
)

Believe it or not, the first three variables:

• localizedResourceWithStringLiteral,
• localizedResourceWithLocalizationValue, and
• localizedResourceWithStaticString

are equivalent. They hold the same information and point to the same localized string resource, producing identical output when used in our app.

The same applies to localizedString and localizedStringOldWay, which will yield the translated version of your string.

Finally, using localizedStringKey in a SwiftUI Text view will also produce the translated string.

Now we understand that we have multiple ways to translate a string and present it to our users.

Let’s clarify when to use each method.

LocalizedStringResource vs String(localized:)

According to Apple’s documentation, LocalizedStringResource is a “reference to a localizable string, accessible from another process”.
We should use LocalizedStringResource when we want to provide localizable strings with lookups deferred to a later time.

What does this mean? Why would we want to defer lookups?

Here are a few scenarios:

1. When communicating between processes (like the main app and extensions),

2. When you want to change the locale before displaying the string,

3. When working with features like Siri or App Intents.

Imagine a notification system that allows users to schedule messages for a later time. We want those messages to be in the user’s preferred language, which might differ from the app’s current language. For example, the app is in English, while the user’s device has been changed later on to French.

struct NotificationScheduler {
    /// The localized greeting message key used in notifications.
    private static let greeting = LocalizedStringResource("main.onboarding.title.label")
    
    func scheduleNotification(forUserWithLocale locale: Locale) async {
        // Create a unique notification request with localized content and trigger.
        let request = UNNotificationRequest(
            identifier: UUID().uuidString,
            content: buildContent(locale: locale), // contains the `greeting` message
            trigger: buildTrigger() // creates the `UNTimeIntervalNotificationTrigger` object
        )

        // Get the shared notification center instance for managing notifications
        let notificationCenter = UNUserNotificationCenter.current()
        
        // Request user's permission to show notifications
        await requestAuthorization(notificationCenter: notificationCenter)
        
        // Schedule the notification with the notification center
        await scheduleNotification(
            request: request,
            notificationCenter: notificationCenter
        )
    }
    ...
}

We can trigger the notification scheduler with a Task, as the code is asynchronous:

Task {
    await scheduler.scheduleNotification(
        forUserWithLocale: Locale.current
    )
}

This ensures that the notification displays the correct translation based on the device’s locale.

Understanding this concept is crucial. If we had used String(localized: “main.onboarding.title.label”) when setting the notification content, the message would have already been translated. If the user changed the locale or language before receiving the scheduled notification, they would see it in a different language.

This is shown in the below image, where the message of the notification is in English, but the phone is in French:

Seeing a real-world example applied to an app helps clarify this important concept.

Moreover, Apple states that LocalizedStringResource is the recommended type for representing and passing around localizable strings. If you need to provide localized strings to another process that might be using a different locale, then LocalizedStringResource is the way to go.

In summary, this type is part of Apple’s efforts to streamline localization in iOS applications, making it easier for developers to create apps that are accessible to a global audience.

What About String.LocalizationValue?

Apple recommends using “this type when the localization key is the localized string value in the development language”. This essentially means that the string you use as a key is the same string that will appear in your default development language (usually English).

For example, consider the localization key “Sign In”, with translations in different languages:

• 🇬🇧 English: “Sign In”,
• 🇪🇸 Spanish: “Iniciar Sesión”,
• 🇫🇷 French: “Se Connecter”.

One drawback is that String.LocalizationValue does not conform to StringProtocol, so you can’t use it directly in SwiftUI Text views. As a key, you can use it with LocalizedStringResource(keyAndValue:) or with String(localized:) initializers, for example.

// ❌ This does not work
Text(String.LocalizationValue("main.onboarding.title.label"))

// ✅ This works
let localizationValue = String.LocalizationValue("main.onboarding.title.label")
Text(LocalizedStringResource(localizationValue))

// ✅ This also works
Text(String(localized: localizationValue))

How Is That Different from LocalizedStringKey?

LocalizedStringKey was integrated into SwiftUI from the beginning and works with many UI components and modifiers.

When you use this initializer, it searches for the key you provide in a localization table. If it finds the key, it displays the corresponding string in the text view. However, if the key isn’t found or if there’s no localization table available, the text view will simply show the key itself as a string.

Compared to String.LocalizationValue, a major advantage of LocalizedStringKey is that it can be used directly in SwiftUI views.

// ✅ This works
Text(LocalizedStringKey("main.onboarding.title.label"))

Oops, We Forgot NSLocalizedString

We can safely assume that when we see something that starts with NS, it’s something old — specifically, Objective-C old. You are correct.

NSLocalizedString was introduced in iOS 2.0 🙀, 16 years ago, during the era of the iPhone 3G when most programmers used NSLog to print messages to their console.

It works perfectly well with SwiftUI and can be safely used in our codebase. In Swift, we use its successor, String(localized:).

Text(
    NSLocalizedString(
        "main.onboarding.title.label",
        comment: "Used to show the onboarding title." // comment for translators
    )
)

God Mode IDDQD

Consider the following challenge:

You are working on the next-gen iOS puzzle game and have been assigned an important task: designing the “Special Hint” feature.

What is the “Special Hint” feature, you might ask? Let me explain.

1. Users will see a text field to enter a keyword.
2. To progress to the next level, they must enter the correct keyword.
3. They have opted in to receive special hints based on the entered words that are related to the keyword.
4. If they enter a word that should trigger a special hint but is not the keyword, the game should display an alert with a localized message.

📒 Note: The iOS puzzle game is localized in multiple languages.

Example:

• Pierre has his device set to French and enters the word: ‘morse’.
• The word ‘morse’ is recognized as a trigger for a special hint.
• The special hint in English is ‘You will have to be more archaic’, which can be translated approximately in French as ‘Vous devrez être plus archaïque’. The message in French is shown to Pierre.
• Jane has her phone set to English and enters the word: ‘walrus’. The special hint will be triggered, and Jane will see the message ‘You will have to be more archaic’.

📒 Note: The game should have multiple special hints associated with the keyword that unlocks the next level (e.g., walrus, cone, banana). Each special hint will trigger a different message.

Before jumping to the solution, I encourage you to resolve this problem. It will help you better understand the localization concepts we discussed in this article.

Here is one way to approach the implementation:

1. The user is French and enters the special hint “morse”.
2. We have a predefined array of keys: [“walrus”, “banana”, “cone”]. These keys should be localized based on the entered word.
3. Translations in French for those keys are:
   “walrus” = “morse”;
   “banana” = “banane”;
   “cone” = “cône”.
4. For each key in the array, retrieve the localized string for the key. The mapped array will be [“morse”, “banane”, “cône”].
5. If one of the keys matches the special hint “morse”, we should display the special hint message. To achieve this, we can create a convention for each key and add “_value” as a suffix: [“walrus_value”, “banana_value”, “cone_value”].
6. Since we know “morse” is a key in the array and corresponds to the localized key “walrus”, we should display the localized text corresponding to the key “walrus_value”.

Code snippet (full source-code on GitHub):

struct ChallengeView: View {
    /// The message to be displayed in the alert when a special hint is triggered.
    @State private var alertMessage: LocalizedStringResource = ""
    
    /// A flag to control the visibility of the alert.
    @State private var showAlert = false
    
    /// The word entered by the user to check against accepted keys.
    @State private var enteredWord = ""

    /// An array of accepted localized keys that can trigger special hints.
    private let acceptedLocalizedKeys = ["walrus", "cone", "banana"]

    var body: some View {
        contentView
            .onChange(of: enteredWord) { _, newValue in
                checkWord(newValue) // Check the entered word for special hints.
            }
            .alert(...) // Display the alert if showAlert is true.
    }

    /// Checks the entered text against the accepted keys and updates the alert message if a match is found.
    /// - Parameter enteredText: The text entered by the user to check for special hints.
    private func checkWord(_ enteredText: String) {
        let localizedKeyValueWords = Dictionary(
            uniqueKeysWithValues: acceptedLocalizedKeys.map { key in
                let translatedCopy = String.LocalizationValue(key)
                return (key, String(localized: translatedCopy))
            }
        )
        
        // Invoke the use case to find a matching special hint.
        if let specialHint = FindWordInListCaseInsensitiveUseCase.invoke(
            input: enteredText,
            wordsDictionary: localizedKeyValueWords
        ) {
            // Update the alert message with the localized key for the special hint.
            alertMessage = LocalizedStringResource(
                stringLiteral: "\(specialHint.localizedKey)\(Self.suffixForSpecialHint)"
            )
            showAlert = true // Set the flag to show the alert.
        }
    }
}

// Enum to encapsulate the logic for finding a word in a case-insensitive manner.
enum FindWordInListCaseInsensitiveUseCase {
    /// Invokes the search for a matching word in the provided dictionary.
    /// - Parameters:
    ///   - input: The user input to compare against the dictionary.
    ///   - wordsDictionary: A dictionary of words to search through.
    /// - Returns: A tuple containing the localized key and the word if a match is found; otherwise, nil.
    static func invoke(
        input: String,
        wordsDictionary: [String: String]
    ) -> (localizedKey: String, word: String)? {
        // Search for a matching word in the dictionary using case-insensitive comparison.
        if let (localizedKey, word) = wordsDictionary.first(where: { key, word in
            input.compare(
                word,
                options: [.caseInsensitive, .diacriticInsensitive, .widthInsensitive]
            ) == .orderedSame
        }) {
            return (localizedKey, word) // Return the found key and word.
        }
        return nil // Return nil if no match is found.
    }
}

Conclusion

In conclusion, localizing strings in iOS applications is a crucial aspect of creating a user-friendly experience for a global audience. Throughout this article, we explored various methods for localization, including LocalizedStringResource, String(localized:), LocalizedStringKey, and NSLocalizedString. Each method has its own use cases and advantages, allowing developers to choose the most appropriate approach based on their specific needs.

Understanding the differences between these localization techniques is essential for effective app development. By leveraging the right tools, developers can ensure that their applications not only reach a wider audience but also resonate with users in their preferred languages.

As you continue to develop your iOS applications, remember the importance of localization and consider implementing these strategies to enhance accessibility and user satisfaction. Embracing localization will ultimately lead to a more inclusive and successful app experience for users around the world.

Bonus Questions

1. What improvements can we make to the algorithm for the challenge?
2. What does the NS in NSLocalizedString stand for?

Resources

Here are some helpful resources for further reading on localization in iOS:

• Localization Value Documentation
• Localized String Resource Documentation
• Localized Words GitHub Repository
• iOS Localization: LocalizedStringResource vs LocalizedStringKey
• NSLocalizedString Documentation
• Default Value on NSLocalizedString
• Localization in iOS Apps

Cracking the Localizable Strings in iOS was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

Motivation

Before diving into iOS app development, it’s crucial to carefully consider the project’s architecture. We need to thoughtfully plan how different pieces of code will fit together, ensuring they remain comprehensible not just today, but months or years later when we need to revisit and modify the codebase. Moreover, a well-structured project helps establish a shared technical vocabulary among team members, making collaboration more efficient.

This article kicks off an exciting series where we’ll explore different architectural approaches by building the same application using various patterns. Throughout the series, we’ll analyze practical aspects like build times and implementation complexity, weigh the pros and cons of each pattern, and most importantly, examine real, production-ready code implementations. This hands-on approach will help you make informed decisions about which architecture best suits your project needs.

Architecture Series Articles

• Model View Controller (MVC)
• Model View ViewModel (MVVM)
• Model View Presenter (MVP)
• Model View Presenter with Coordinators (MVP-C)
• View Interactor Presenter Entity Router (VIPER)
• View Interactor Presenter (VIP) — Current Article

If you’re eager to explore the implementation details directly, you can find the complete source code in our open-source repository here.

Why Your iOS App Needs a Solid Architecture Pattern

The cornerstone of any successful iOS application is maintainability. A well-architected app clearly defines boundaries — you know exactly where view logic belongs, what responsibilities each view controller has, and which components handle business logic. This clarity isn’t just for you; it’s essential for your entire development team to understand and maintain these boundaries consistently.

Here are the key benefits of implementing a robust architecture pattern:

• Maintainability: Makes code easier to update and modify over time
• Testability: Facilitates comprehensive testing of business logic through clear separation of concerns
• Team Collaboration: Creates a shared technical vocabulary and understanding among team members
• Clean Separation: Ensures each component has clear, single responsibilities
• Bug Reduction: Minimizes errors through better organization and clearer interfaces between components

Project Requirements Overview

Given a medium-sized iOS application consisting of 6–7 screens, we’ll demonstrate how to implement it using the most popular architectural patterns in the iOS ecosystem: MVC (Model-View-Controller), MVVM (Model-View-ViewModel), MVP (Model-View-Presenter), VIPER (View-Interactor-Presenter-Entity-Router), VIP (Clean Swift), and the Coordinator pattern. Each implementation will showcase the pattern’s strengths and potential challenges.

Our demo application, Football Gather, is designed to help friends organize and track their casual football matches. It’s complex enough to demonstrate real-world architectural challenges while remaining simple enough to clearly illustrate different patterns.

Core Features and Functionality

• Player Management: Add and maintain a roster of players in the application
• Team Assignment: Flexibly organize players into different teams for each match
• Player Customization: Edit player details and preferences
• Match Management: Set and control countdown timers for match duration

Screen Mockups

Backend

The application is supported by a web backend developed using the Vapor framework, a popular choice for building modern REST APIs in Swift. You can explore the details of this implementation in our article here, which covers the fundamentals of building REST APIs with Vapor and Fluent in Swift. Additionally, we have documented the transition from Vapor 3 to Vapor 4, highlighting the enhancements and new features in our article here.

Cleaning Your Code Like a VIP

VIP is not a widely adopted architecture pattern, but it offers unique advantages for clean and scalable iOS development. Invented by Raymond Law, VIP is an adaptation of Uncle Bob’s Clean Architecture principles tailored for iOS projects. For more details, visit Clean Swift.

The primary goal of VIP is to address the “Massive View Controller” problem often associated with MVC. VIP also aims to resolve challenges seen in other architecture patterns. For example, while VIPER places the Presenter at the center of the application, VIP simplifies this process by using a unidirectional flow of control, making it easier to manage method invocations across layers.

VIP organizes your app into distinct control cycles, ensuring a clear and consistent flow of data and actions.

Example Scenario of Applying VIP:

1. A user taps a button to fetch a list of players, starting in the ViewController.
2. The associated IBAction triggers a method in the Interactor.
3. The Interactor processes the request, executes business logic (e.g., fetching players from a server), and sends the response to the Presenter to format it for display.
4. The Presenter passes the formatted data to the ViewController, which displays it to the user.

VIP Architecture Components

View/ViewController

The View/ViewController layer has two primary responsibilities: sending user actions to the Interactor and displaying data received from the Presenter.

Interactor

Known as the “new Presenter,” the Interactor serves as the core of the VIP architecture. It handles tasks like network calls, error handling, and business logic computation.

Worker

In some cases (e.g., in Football Gather), we refer to Workers as “Services.” A Worker offloads specific tasks from the Interactor, such as managing network requests or database interactions.

Presenter

The Presenter processes data from the Interactor and formats it into a ViewModel suitable for display in the View.

Router

The Router manages scene transitions, similar to its role in VIPER.

Models

The Model layer encapsulates data, much like in other architectural patterns.

Communication

Communication flows in a unidirectional manner:

• The ViewController interacts with both the Router and the Interactor.
• The Interactor processes data and communicates with the Presenter. It may also collaborate with Workers for specific tasks.
• The Presenter formats the response from the Interactor into a ViewModel and sends it to the View/ViewController.

Advantages of VIP

• Eliminates the “Massive View Controller” issue found in MVC.
• Avoids the “Massive View Model” problem that can occur with incorrect MVVM implementation.
• Solves control issues seen in VIPER by introducing the VIP cycle.
• Prevents “Massive Presenters” often encountered with improper VIPER use.
• Aligns with Clean Architecture principles, ensuring separation of concerns.
• Facilitates handling of complex business logic by delegating to Workers.
• Highly testable and compatible with TDD practices.
• Offers good modularity and easier debugging.

Disadvantages of VIP

• Introduces numerous layers, which can become tedious without code generation tools.
• Involves writing significant amounts of code, even for simple actions.
• Not well-suited for small applications due to its complexity.
• Certain components may feel redundant, depending on the app’s use case.
• Slightly increases app startup time.

VIP vs. VIPER

• In VIP, the Interactor directly interacts with the ViewController.
• The ViewController holds a reference to the Router in VIP.
• VIPER’s flexibility can lead to “Massive Presenters” if not implemented correctly.
• VIP maintains a unidirectional flow of control.
• Services in VIPER are referred to as Workers in VIP.

Applying VIP to Our Code

Transitioning an app from VIPER to VIP is not a straightforward process. The first step is to transform the Presenter into an Interactor. Afterward, extract the Router from the Presenter and integrate it into the ViewController.

The module assembly logic from VIPER can remain intact, simplifying the process.

Login Scene

Let’s start by applying these changes to the Login scene and iterating from there.

final class LoginViewController: UIViewController, LoginViewable {

    // MARK: - Properties
    @IBOutlet private weak var usernameTextField: UITextField!
    @IBOutlet private weak var passwordTextField: UITextField!
    @IBOutlet private weak var rememberMeSwitch: UISwitch!

    lazy var loadingView = LoadingView.initToView(view)

    var interactor: LoginInteractorProtocol = LoginInteractor()
    var router: LoginRouterProtocol = LoginRouter()

    // MARK: - View life cycle
    override func viewDidLoad() {
        super.viewDidLoad()
        loadCredentials()
    }

    private func loadCredentials() {
        let request = Login.LoadCredentials.Request()
        interactor.loadCredentials(request: request)
    }

    // ...
}

As you can see we no longer tell the Presenter that the view has been loaded. We now make a request to the Interactor to load the credentials.

The IBActions have been modified as below:

final class LoginViewController: UIViewController, LoginViewable {

    // ...
    @IBAction private func login(_ sender: Any) {
        showLoadingView()
        let request = Login.Authenticate.Request(username: usernameTextField.text,
                                                  password: passwordTextField.text,
                                                  storeCredentials: rememberMeSwitch.isOn)
        interactor.login(request: request)
    }

    @IBAction private func register(_ sender: Any) {
        showLoadingView()
        let request = Login.Authenticate.Request(username: usernameTextField.text,
                                                  password: passwordTextField.text,
                                                  storeCredentials: rememberMeSwitch.isOn)
        interactor.register(request: request)
    }
    // ...
}

We start the loading view, construct the request to the Interactor containing the username, password contents of the text fields and the state of the UISwitch for remembering the username.

Next, handling the viewDidLoad UI updates are made through the LoginViewConfigurable protocol:

extension LoginViewController: LoginViewConfigurable {
    func displayStoredCredentials(viewModel: Login.LoadCredentials.ViewModel) {
        rememberMeSwitch.isOn = viewModel.rememberMeIsOn
        usernameTextField.text = viewModel.usernameText
    }
}

Finally, when the logic service call has been completed we call from the Presenter the following method:

func loginCompleted(viewModel: Login.Authenticate.ViewModel) {
    hideLoadingView()

    if viewModel.isSuccessful {
        router.showPlayerList()
    } else {
        handleError(title: viewModel.errorTitle!, message: viewModel.errorDescription!)
    }
}

The Interactor looks the same as the one from the VIPER architecture. It has the same dependencies:

final class LoginInteractor: LoginInteractable {

    var presenter: LoginPresenterProtocol

    private let loginService: LoginService
    private let usersService: StandardNetworkService
    private let userDefaults: FootballGatherUserDefaults
    private let keychain: FootbalGatherKeychain

    init(presenter: LoginPresenterProtocol = LoginPresenter(),
          loginService: LoginService = LoginService(),
          usersService: StandardNetworkService = StandardNetworkService(resourcePath: "/api/users"),
          userDefaults: FootballGatherUserDefaults = .shared,
          keychain: FootbalGatherKeychain = .shared) {
        self.presenter = presenter
        self.loginService = loginService
        self.usersService = usersService
        self.userDefaults = userDefaults
        self.keychain = keychain
    }
}

The key thing here is that we now inject the Presenter through the initializer and it is no longer a weak variable.

Loading credentials is presented below. We first take the incoming request from the ViewController. We create a response for the presenter and call the function presentCredentials(response: response).

func loadCredentials(request: Login.LoadCredentials.Request) {
    let rememberUsername = userDefaults.rememberUsername ?? true
    let username = keychain.username
    let response = Login.LoadCredentials.Response(rememberUsername: rememberUsername, username: username)
    presenter.presentCredentials(response: response)
}

The login and register methods are the same, the exception being the Network service (Worker).

func login(request: Login.Authenticate.Request) {
    guard let username = request.username, let password = request.password else {
        let response = Login.Authenticate.Response(error: .missingCredentials)
        presenter.authenticationCompleted(response: response)
        return
    }

    let requestModel = UserRequestModel(username: username, password: password)

    loginService.login(user: requestModel) { [weak self] result in
        DispatchQueue.main.async {
            switch result {
            case .failure(let error):
                let response = Login.Authenticate.Response(error: .loginFailed(error.localizedDescription))
                self?.presenter.authenticationCompleted(response: response)
            case .success(_):
                guard let self = self else { return }
                self.updateCredentials(username: username, shouldStore: request.storeCredentials)
                let response = Login.Authenticate.Response(error: nil)
                self.presenter.authenticationCompleted(response: response)
            }
        }
    }
}

private func updateCredentials(username: String, shouldStore: Bool) {
    keychain.username = shouldStore ? username : nil
    userDefaults.rememberUsername = shouldStore
}

The Presenter doesn’t hold references to the Router or Interactor. We just keep the dependency of the View, which has to be weak to complete the VIP cycle and not have retain cycles.

The Presenter has been greatly simplified, exposing two methods of the public API:

func presentCredentials(response: Login.LoadCredentials.Response) {
    let viewModel = Login.LoadCredentials.ViewModel(rememberMeIsOn: response.rememberUsername,
                                                    usernameText: response.username)
    view?.displayStoredCredentials(viewModel: viewModel)
}

func authenticationCompleted(response: Login.Authenticate.Response) {
    guard response.error == nil else {
        handleServiceError(response.error)
        return
    }

    let viewModel = Login.Authenticate.ViewModel(isSuccessful: true, errorTitle: nil, errorDescription: nil)
    view?.loginCompleted(viewModel: viewModel)
}

private func handleServiceError(_ error: LoginError?) {
    switch error {
    case .missingCredentials:
        let viewModel = Login.Authenticate.ViewModel(isSuccessful: false,
                                                      errorTitle: "Error",
                                                      errorDescription: "Both fields are mandatory.")
        view?.loginCompleted(viewModel: viewModel)
    case .loginFailed(let message), .registerFailed(let message):
        let viewModel = Login.Authenticate.ViewModel(isSuccessful: false,
                                                      errorTitle: "Error",
                                                      errorDescription: String(describing: message))
        view?.loginCompleted(viewModel: viewModel)
    default:
        break
    }
}

The Router layer remains the same.

We apply some minor updates to the Module assembly:

extension LoginModule: AppModule {
    func assemble() -> UIViewController? {
        presenter.view = view

        interactor.presenter = presenter
        view.interactor = interactor
        view.router     = router
        return view as? UIViewController
    }
}

PlayerList scene

Next, we move to PlayerList scene.

The ViewController will be transformed in a similar way - the Presenter will be replaced by Interactor and we now hold a reference to the Router.

An interesting aspect in VIP is the fact we can have an array of view models inside the ViewController:

var interactor: PlayerListInteractorProtocol = PlayerListInteractor()
var router: PlayerListRouterProtocol = PlayerListRouter()

private var displayedPlayers: [PlayerList.FetchPlayers.ViewModel.DisplayedPlayer] = []

We no longer tell the Presenter that the View has been loaded. The ViewController will configure its UI elements in the initial state.

override func viewDidLoad() {
    super.viewDidLoad()

    setupView()
    fetchPlayers()
}

private func setupView() {
    configureTitle("Players")
    setupBarButtonItem(title: "Select")
    setBarButtonState(isEnabled: false)
    setupTableView()
}

Similar to Login, the IBActions will construct a request and will call a method within the Interactor.

// MARK: - Selectors
@objc private func selectPlayers() {
    let request = PlayerList.SelectPlayers.Request()
    interactor.selectPlayers(request: request)
}

@IBAction private func confirmOrAddPlayers(_ sender: Any) {
    let request = PlayerList.ConfirmOrAddPlayers.Request()
    interactor.confirmOrAddPlayers(request: request)
}

When the data will be fetched and ready to be displayable, the Presenter will call the method from the ViewController displayFetchedPlayers.

The rest of the code is available in the open-source repository.

Key Metrics

Lines of code — Protocols

Lines of code — View Controllers and Views

Lines of code — Modules

Lines of code — Local Models

Lines of code — Routers

Lines of code — Presenters

Lines of code — Interactors

Unit Tests

Build Times

Tests were run on an 8-Core Intel Core i9, MacBook Pro, 2019. Xcode version: 12.5.1. macOS Big Sur.

Conclusion

We implemented VIP architecture in an application originally built with VIPER. The first noticeable improvement is the significant simplification and cleanliness of the Presenters. If the transition were made from an MVC application, the ViewControllers would have been reduced drastically due to better separation of concerns.

VIP introduces a unidirectional flow of control, making the invocation of methods across layers more straightforward and predictable. This results in a cleaner and more maintainable structure.

The average build times for VIP are comparable to those of VIPER and MVP, remaining around 10 seconds. While the addition of more unit tests increases the overall test execution time, we found it to be slightly faster than VIPER during our testing process.

One key observation is the reduction in the size of Presenters. With VIP, Presenters were streamlined to only 514 lines of code, a substantial improvement over VIPER. However, this reduction is offset by an increase in the size of Interactors, which grew by 508 lines. Essentially, what was removed from the Presenters was redistributed to the Interactors, resulting in a similar overall code footprint.

Personally, I still lean towards VIPER. While VIP offers several advantages, there are aspects of the architecture that, in my view, deviate from the principles it claims to follow, including Uncle Bob’s Clean Architecture guidelines.

For instance, the necessity of constructing a Request object, even when there is no data to attach to it, seems redundant. While this step can technically be skipped, the example repository demonstrates numerous instances of empty Request objects, which add unnecessary boilerplate code.

Another challenge is the added complexity of maintaining an array of view models within the ViewController. This approach can lead to synchronization issues with the corresponding Worker models, making the architecture harder to manage.

That said, there’s room to customize and adapt VIP to better suit specific project needs. A personalized variation of VIP could mitigate many of these concerns and improve its practicality in certain contexts.

On a positive note, the concept of VIP cycles is compelling, and the architecture is well-suited for Test-Driven Development (TDD). However, adhering strictly to the prescribed layering rules can make even minor changes more cumbersome than necessary. After all, software development should aim to be adaptable — true to the spirit of “SOFTware.”

Useful Links

• The iOS App, Football Gather — GitHub Repo Link
• The web server application made in Vapor — GitHub Repo Link
• Vapor 3 Backend APIs article link
• Migrating to Vapor 4 article link
• Model View Controller (MVC) — GitHub Repo Link and article link
• Model View ViewModel (MVVM) — GitHub Repo Link and article link
• Model View Presenter (MVP) — GitHub Repo link and article link
• Coordinator Pattern — MVP with Coordinators (MVP-C) — GitHub Repo link and article link
• View Interactor Presenter Entity Router (VIPER) — GitHub Repo link and article link
• View Interactor Presenter (VIP) — GitHub Repo link

Battle of the iOS Architecture Patterns: View Interactor Presenter (VIP) was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

Motivation

Before diving into iOS app development, it’s crucial to carefully consider the project’s architecture. We need to thoughtfully plan how different pieces of code will fit together, ensuring they remain comprehensible not just today, but months or years later when we need to revisit and modify the codebase. Moreover, a well-structured project helps establish a shared technical vocabulary among team members, making collaboration more efficient.

This article kicks off an exciting series where we’ll explore different architectural approaches by building the same application using various patterns. Throughout the series, we’ll analyze practical aspects like build times and implementation complexity, weigh the pros and cons of each pattern, and most importantly, examine real, production-ready code implementations. This hands-on approach will help you make informed decisions about which architecture best suits your project needs.

Architecture Series Articles

• Model View Controller (MVC)
• Model View ViewModel (MVVM)
• Model View Presenter (MVP)
• Model View Presenter with Coordinators (MVP-C)
• View Interactor Presenter Entity Router (VIPER) — Current Article
• View Interactor Presenter (VIP)

If you’re eager to explore the implementation details directly, you can find the complete source code in our open-source repository here.

Why Your iOS App Needs a Solid Architecture Pattern

The cornerstone of any successful iOS application is maintainability. A well-architected app clearly defines boundaries — you know exactly where view logic belongs, what responsibilities each view controller has, and which components handle business logic. This clarity isn’t just for you; it’s essential for your entire development team to understand and maintain these boundaries consistently.

Here are the key benefits of implementing a robust architecture pattern:

• Maintainability: Makes code easier to update and modify over time
• Testability: Facilitates comprehensive testing of business logic through clear separation of concerns
• Team Collaboration: Creates a shared technical vocabulary and understanding among team members
• Clean Separation: Ensures each component has clear, single responsibilities
• Bug Reduction: Minimizes errors through better organization and clearer interfaces between components

Project Requirements Overview

Given a medium-sized iOS application consisting of 6–7 screens, we’ll demonstrate how to implement it using the most popular architectural patterns in the iOS ecosystem: MVC (Model-View-Controller), MVVM (Model-View-ViewModel), MVP (Model-View-Presenter), VIPER (View-Interactor-Presenter-Entity-Router), VIP (Clean Swift), and the Coordinator pattern. Each implementation will showcase the pattern’s strengths and potential challenges.

Our demo application, Football Gather, is designed to help friends organize and track their casual football matches. It’s complex enough to demonstrate real-world architectural challenges while remaining simple enough to clearly illustrate different patterns.

Core Features and Functionality

• Player Management: Add and maintain a roster of players in the application
• Team Assignment: Flexibly organize players into different teams for each match
• Player Customization: Edit player details and preferences
• Match Management: Set and control countdown timers for match duration

Screen Mockups

Backend

The application is supported by a web backend developed using the Vapor framework, a popular choice for building modern REST APIs in Swift. You can explore the details of this implementation in our article here, which covers the fundamentals of building REST APIs with Vapor and Fluent in Swift. Additionally, we have documented the transition from Vapor 3 to Vapor 4, highlighting the enhancements and new features in our article here.

Dude, where’s my VIPER?

VIPER stands for View-Interactor-Presenter-Entity-Router.

We saw in MVP what the Presenter layer is and what it does. This concept applies as well for VIPER, but has been enhanced with a new responsibility, to get data from the Interactor and based on the rules, it will update / configure the View.

View

Must be as dumb as possible. It forwards all events to the Presenter and mostly should do what the Presenter tells it to do, being passive.

Interactor

A new layer has been introduced, and in here we should put everything that has to do with the business rules and logic.

Presenter

Has the responsibility to get data from the Interactor, based on the user’s actions, and then handle the View updates.

Entity

Is the Model layer and is used to encapsulate data.

Router

Holds all navigation logic for our application. It looks more like a Coordinator, without the business logic.

Communication

When something happens in the view layer, for example when the user initiates an action, it is communicated to the Presenter.

The Presenter asks the Interactor for the data needed by the user. The Interactor provides the data.

The Presenter applies the needed UI transformation to display that data.

When the model / data has been changed, the Interactor will inform the Presenter.

The Presenter will configure or refresh the View based on the data it received.

When users navigate through different screens within the app or take a different route that will change the flow, the View will communicate it to the Presenter.

The Presenter will notify the Router to load the new screen or load the new flow (e.g. pushing a new view controller).

Extended VIPER

There are a few concepts that are commonly used with VIPER architecture pattern.

Modules

Is a good idea to separate the VIPER layers creation from the Router and introduce a new handler for module assembly. This is done most likely with a Factory method pattern.

/// Defines the structure for the AppModule protocol, which requires an assemble method that returns an optional UIViewController.
protocol AppModule {
    func assemble() -> UIViewController?
}

/// Defines the ModuleFactoryProtocol with methods to create specific modules like Login and PlayerList.
protocol ModuleFactoryProtocol {
    func makeLogin(using navigationController: UINavigationController) -> LoginModule
    func makePlayerList(using navigationController: UINavigationController) -> PlayerListModule
}

And the concrete implementation for our app:

/// ModuleFactory struct implements the ModuleFactoryProtocol, providing concrete methods to create modules.
struct ModuleFactory: ModuleFactoryProtocol {
    /// Creates the Login module with a provided or default navigation controller.
    func makeLogin(using navigationController: UINavigationController = UINavigationController()) -> LoginModule {
        let router = LoginRouter(navigationController: navigationController, moduleFactory: self)
        let view: LoginViewController = Storyboard.defaultStoryboard.instantiateViewController()
        return LoginModule(view: view, router: router)
    }

    /// Creates the PlayerList module with a provided or default navigation controller.
    func makePlayerList(using navigationController: UINavigationController = UINavigationController()) -> PlayerListModule {
        let router = PlayerListRouter(navigationController: navigationController, moduleFactory: self)
        let view: PlayerListViewController = Storyboard.defaultStoryboard.instantiateViewController()
        return PlayerListModule(view: view, router: router)
    }
}

We will see later more source code.

TDD

This approach does a good job from a Clean Code perspective, and you develop the layers to have a good separation of concerns and follow the SOLID principles better.

So, TDD is easy to achieve using VIPER.

• The modules are decoupled.
• There is a clear separation of concerns.
• The modules are are neat and clean from a coding perspective.

Code generation tool

As we add more modules, flows and functionality to our application, we will discover that we write a lot of code and most of it is repetitive.

There is a good idea to have a code generator tool for your VIPER modules.

Solving the back problem

We saw that when applying the Coordinator pattern we had a problem when navigating back in the stack, to a specific view controller.
In this case, we need to think of a way if in our app we need to go back or send data between different VIPER modules.

This problem can be easily solved with Delegation.

For example:

protocol PlayerDetailsDelegate: AnyObject {
    func didUpdatePlayer(_ player: Player)
}

/// This extension makes the Presenter the delegate of PlayerDetailsPresenter.
/// This allows refreshing the UI when a player is updated.
extension PlayerListPresenter: PlayerDetailsDelegate {
    func didUpdatePlayer(_ player: Player) {
        viewState = .list
        configureView()
        view?.reloadData()
    }
}

More practical examples we are going to see in the section Applying to our code.

When to use VIPER

VIPER should be used when you have some knowledge about Swift and iOS programming or you have experienced or more senior developers within your team.

If you are part of a small project, that will not scale, then VIPER might be too much. MVC should work just fine.

Use it when you are more interested in modularising and unit test the app giving you a high code coverage.
Don’t use it when you are a beginner or you don’t have that much experience into iOS development.
Be prepared to write more code.

From my point of view, VIPER is great and I really like how clean the code looks. Is easy to test, my classes are decoupled and the code is indeed SOLID.

For our app, we separated the View layer into two components: ViewController and the actual View.
The ViewController acts as a Coordinator / Router and holds a reference to the view, usually set as an IBOutlet.

Advantages

• The code is clean, SRP is at its core.
• Unit tests are easy to write.
• The code is decoupled.
• Less bugs, especially if you are using TDD.
• Very useful for complex projects, where it simplifies the business logic.
• The modules can be reusable.
• New features are easy to add.

Disadvantages

• You may write a lot of boilerplate code.
• Is not great for small apps.
• You end up with a big codebase and a lot of classes.
• Some of the components might be redundant based on your app use cases.
• App startup will slightly increase.

Applying to our code

There will be major changes to the app by applying VIPER.

We decided to not keep two separate layers for View and ViewController, because one of these layer will become very light and it didn’t serve much purpose.

All coordinators will be removed.

First, we start by creating an AppLoader that will load the first module, Login.

struct AppLoader {
    private let window: UIWindow
    private let navigationController: UINavigationController
    private let moduleFactory: ModuleFactoryProtocol

    init(window: UIWindow = UIWindow(frame: UIScreen.main.bounds),
          navigationController: UINavigationController = UINavigationController(),
          moduleFactory: ModuleFactoryProtocol = ModuleFactory()) {
        self.window = window
        self.navigationController = navigationController
        self.moduleFactory = moduleFactory
    }

    /// This function is similar to the one we had for Coordinators, start().
    func build() {
        let module = moduleFactory.makeLogin(using: navigationController)
        let viewController = module.assemble()
        setRootViewController(viewController)
    }

    private func setRootViewController(_ viewController: UIViewController?) {
        window.rootViewController = navigationController
        if let viewController = viewController {
            navigationController.pushViewController(viewController, animated: true)
        }
        window.makeKeyAndVisible()
    }
}

We allocate AppLoader in AppDelegate and call the function build() when the app did finish launching.

class AppDelegate: UIResponder, UIApplicationDelegate {

    private lazy var loader = AppLoader()
    
    func application(
      _ application: UIApplication,
      didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        loader.build()
        return true
    }
    ..
}

We saw earlier how we use ModuleFactory to create VIPER modules. We provide an interface for all modules that require assembly in our app.

protocol ModuleFactoryProtocol {
    func makeLogin(using navigationController: UINavigationController) -> LoginModule
    func makePlayerList(using navigationController: UINavigationController) -> PlayerListModule
    func makePlayerDetails(using navigationController: UINavigationController,
                            for player: PlayerResponseModel,
                            delegate: PlayerDetailDelegate) -> PlayerDetailModule
    func makePlayerEdit(using navigationController: UINavigationController,
                        for playerEditable: PlayerEditable,
                        delegate: PlayerEditDelegate) -> PlayerEditModule
    func makePlayerAdd(using navigationController: UINavigationController, delegate: PlayerAddDelegate) -> PlayerAddModule
    func makeConfirmPlayers(using navigationController: UINavigationController,
                            playersDictionary: [TeamSection: [PlayerResponseModel]],
                            delegate: ConfirmPlayersDelegate) -> ConfirmPlayersModule
    func makeGather(using navigationController: UINavigationController,
                    gather: GatherModel,
                    delegate: GatherDelegate) -> GatherModule
}

We have a struct ModuleFactory that is the concrete implementation of the above protocol.

struct ModuleFactory: ModuleFactoryProtocol {
    func makeLogin(using navigationController: UINavigationController = UINavigationController()) -> LoginModule {
        let router = LoginRouter(navigationController: navigationController, moduleFactory: self)
        let view: LoginViewController = Storyboard.defaultStoryboard.instantiateViewController()
        return LoginModule(view: view, router: router)
    }
    /// other functions
    …
}

Let’s see how LoginModule is created.

final class LoginModule {

    /// Set the dependencies
    private var view: LoginViewProtocol
    private var router: LoginRouterProtocol
    private var interactor: LoginInteractorProtocol
    private var presenter: LoginPresenterProtocol

    /// Optionally, provide default implementation for your protocols with concrete classes
    init(view: LoginViewProtocol = LoginViewController(),
          router: LoginRouterProtocol = LoginRouter(),
          interactor: LoginInteractorProtocol = LoginInteractor(),
          presenter: LoginPresenterProtocol = LoginPresenter()) {
        self.view = view
        self.router = router
        self.interactor = interactor
        self.presenter = presenter
    }
}

/// Reference your layers
extension LoginModule: AppModule {
    func assemble() -> UIViewController? {
        presenter.view = view
        presenter.interactor = interactor
        presenter.router = router
        interactor.presenter = presenter
        view.presenter = presenter
        return view as? UIViewController
    }
}

Every module will have a function assemble() that is needed when implementing the AppModule protocol.

In here, we create the references between the VIPER layers:

• We set the view to the presenter (weak link).
• Presenter holds a strong reference to the Interactor.
• Presenter holds a strong reference to the Router.
• Interactor holds a weak reference to the Presenter.
• Our View holds a strong reference to the Presenter.

We set the weak references to avoid, of course, retain cycles which can cause memory leaks.

Every VIPER module within our app is assembled in the same way.

LoginRouter has a simple job: present the players after the user logged in.

final class LoginRouter {

    private let navigationController: UINavigationController
    private let moduleFactory: ModuleFactoryProtocol

    // We inject the module factory so we can create and assemble the next screen module (PlayerList).
    init(navigationController: UINavigationController = UINavigationController(),
         moduleFactory: ModuleFactoryProtocol = ModuleFactory()) {
        self.navigationController = navigationController
        self.moduleFactory = moduleFactory
    }
}

extension LoginRouter: LoginRouterProtocol {
    func showPlayerList() {
        let module = moduleFactory.makePlayerList(using: navigationController)
        if let viewController = module.assemble() {
            navigationController.pushViewController(viewController, animated: true)
        }
    }
}

One important aspect that we missed when applying MVP to our code, was that we didn’t made our View passive. The Presenter acted more like a ViewModel in some cases.

Let’s correct that and make the View as passive and dumb as we can.

Another thing that we did, was to split the LoginViewProtocol into multiple small protocols, addressing the specific need:

typealias LoginViewProtocol = LoginViewable & Loadable & LoginViewConfigurable & ErrorHandler

protocol LoginViewable: AnyObject {
    var presenter: LoginPresenterProtocol { get set }
}

protocol LoginViewConfigurable: AnyObject {
    var rememberMeIsOn: Bool { get }
    var usernameText: String? { get }
    var passwordText: String? { get }

    func setRememberMeSwitch(isOn: Bool)
    func setUsername(_ username: String?)
}

We combined all of them by using protocol composition and named them with a typealias. We use the same approach for all of our VIPER protocols.

The LoginViewController is described below:

final class LoginViewController: UIViewController, LoginViewable {

    // MARK: - Properties
    @IBOutlet weak var usernameTextField: UITextField!
    @IBOutlet weak var passwordTextField: UITextField!
    @IBOutlet weak var rememberMeSwitch: UISwitch!

    lazy var loadingView = LoadingView.initToView(view)

    // We can remove the default implementation of LoginPresenter() and force-unwrap the presenter in the protocol definition. We used this approach for some modules.
    var presenter: LoginPresenterProtocol = LoginPresenter()

    // MARK: - View life cycle
    override func viewDidLoad() {
        super.viewDidLoad()
        presenter.viewDidLoad()
    }

    // MARK: - IBActions

    @IBAction private func login(_ sender: Any) {
        presenter.performLogin()
    }

    @IBAction private func register(_ sender: Any) {
        presenter.performRegister()
    }
}

extension LoginViewController: LoginViewConfigurable {
    // UIKit is not allowed to be referenced in the Presenter. We expose the value of our outlets by using abstraction.
    var rememberMeIsOn: Bool { rememberMeSwitch.isOn }
    var usernameText: String? { usernameTextField.text }
    var passwordText: String? { passwordTextField.text }

    func setRememberMeSwitch(isOn: Bool) {
        rememberMeSwitch.isOn = isOn
    }

    func setUsername(_ username: String?) {
        usernameTextField.text = username
    }
}

extension LoginViewController: Loadable {}

extension LoginViewController: ErrorHandler {}

Loadable is the same helper protocol that we used in our previous versions of the codebase. It simply shows and hides a loading view, which comes in handy when doing some Network requests. It has a default implementation for classes of type UIView and UIViewController (example: extension Loadable where Self: UIViewController).

ErrorHandler is a new helper protocol that has one method:

protocol ErrorHandler {
    func handleError(title: String, message: String)
}

extension ErrorHandler where Self: UIViewController {
    func handleError(title: String, message: String) {
        AlertHelper.present(in: self, title: title, message: message)
    }
}

The default implementation uses the static method from AlertHelper to present an alert controller. We use it for displaying the Network errors.

We continue with the Presenter layer below:

final class LoginPresenter: LoginPresentable {

    // MARK: - Properties
    weak var view: LoginViewProtocol?
    var interactor: LoginInteractorProtocol
    var router: LoginRouterProtocol

    // MARK: - Public API
    init(view: LoginViewProtocol? = nil,
         interactor: LoginInteractorProtocol = LoginInteractor(),
         router: LoginRouterProtocol = LoginRouter()) {
        self.view = view
        self.interactor = interactor
        self.router = router
    }
}

We set our dependencies to be injected via the initialiser. Now, the presenter has two new dependencies: Interactor and Router.

After our ViewController finished to load the view, we notify the Presenter. We want to make the View more passive, so we let the Presenter to specify the View how to configure its UI elements with the information that we get from the Interactor:

extension LoginPresenter: LoginPresenterViewConfiguration {
    func viewDidLoad() {
        // Fetch the UserDefaults and Keychain values by asking the Interactor. Configure the UI elements based on the values we got.
        let rememberUsername = interactor.rememberUsername

        view?.setRememberMeSwitch(isOn: rememberUsername)

        if rememberUsername {
            view?.setUsername(interactor.username)
        }
    }
}

The service API calls to login and register are similar:

extension LoginPresenter: LoginPresenterServiceInteractable {
    func performLogin() {
        guard validateCredentials() else { return }

        view?.showLoadingView()

        interactor.login(username: username!, password: password!)
    }

    func performRegister() {
        guard validateCredentials() else { return }
        view?.showLoadingView()
        interactor.register(username: username!, password: password!)
    }

    private func validateCredentials() -> Bool {
        guard credentialsAreValid else {
            view?.handleError(title: "Error", message: "Both fields are mandatory.")
            return false
        }

        return true
    }

    private var credentialsAreValid: Bool {
        username?.isEmpty == false && password?.isEmpty == false
    }

    private var username: String? {
        view?.usernameText
    }

    private var password: String? {
        view?.passwordText
    }
}

When the API calls are finished, the Interactor calls the following methods from the Presenter:

// MARK: - Service Handler
extension LoginPresenter: LoginPresenterServiceHandler {
    func serviceFailedWithError(_ error: Error) {
        view?.hideLoadingView()
        view?.handleError(title: "Error", message: String(describing: error))
    }

    func didLogin() {
        handleAuthCompletion()
    }

    func didRegister() {
        handleAuthCompletion()
    }

    private func handleAuthCompletion() {
        storeUsernameAndRememberMe()
        view?.hideLoadingView()
        router.showPlayerList()
    }

    private func storeUsernameAndRememberMe() {
        let rememberMe = view?.rememberMeIsOn ?? true
        if rememberMe {
            interactor.setUsername(view?.usernameText)
        } else {
            interactor.setUsername(nil)
        }
    }
}

The Interactor now holds the business logic:

final class LoginInteractor: LoginInteractable {

    weak var presenter: LoginPresenterProtocol?

    private let loginService: LoginService
    private let usersService: StandardNetworkService
    private let userDefaults: FootballGatherUserDefaults
    private let keychain: FootbalGatherKeychain

    init(loginService: LoginService = LoginService(),
         usersService: StandardNetworkService = StandardNetworkService(resourcePath: "/api/users"),
         userDefaults: FootballGatherUserDefaults = .shared,
         keychain: FootbalGatherKeychain = .shared) {
        self.loginService = loginService
        self.usersService = usersService
        self.userDefaults = userDefaults
        self.keychain = keychain
    }
}

We expose in our Public API the actual values for rememberMe and the username:

// MARK: - Credentials handler
extension LoginInteractor: LoginInteractorCredentialsHandler {

    var rememberUsername: Bool { userDefaults.rememberUsername ?? true }
    var username: String? { keychain.username }

    func setRememberUsername(_ value: Bool) {
        userDefaults.rememberUsername = value
    }

    func setUsername(_ username: String?) {
        keychain.username = username
    }
}

The service handlers are lighter than in previous architecture patterns:

// MARK: - Services
extension LoginInteractor: LoginInteractorServiceRequester {
    func login(username: String, password: String) {
        let requestModel = UserRequestModel(username: username, password: password)
        loginService.login(user: requestModel) { [weak self] result in
            DispatchQueue.main.async {
                switch result {
                case .failure(let error):
                    self?.presenter?.serviceFailedWithError(error)

                case .success(_):
                    self?.presenter?.didLogin()
                }
            }
        }
    }

    func register(username: String, password: String) {
        guard let hashedPasssword = Crypto.hash(message: password) else {
            fatalError("Unable to hash password")
        }

        let requestModel = UserRequestModel(username: username, password: hashedPasssword)
        usersService.create(requestModel) { [weak self] result in
            DispatchQueue.main.async {
                switch result {
                case .failure(let error):
                    self?.presenter?.serviceFailedWithError(error)
                case .success(let resourceId):
                    print("Created user: \(resourceId)")
                    self?.presenter?.didRegister()
                }
            }
        }
    }
}

When editing a player, we use delegation for refreshing the list of the players from the PlayerList module.

struct ModuleFactory: ModuleFactoryProtocol {
    func makePlayerDetails(using navigationController: UINavigationController = UINavigationController(),
                           for player: PlayerResponseModel,
                           delegate: PlayerDetailDelegate) -> PlayerDetailModule {
        let router = PlayerDetailRouter(navigationController: navigationController, moduleFactory: self)
        let view: PlayerDetailViewController = Storyboard.defaultStoryboard.instantiateViewController()
        let interactor = PlayerDetailInteractor(player: player)
        let presenter = PlayerDetailPresenter(interactor: interactor, delegate: delegate)

        return PlayerDetailModule(view: view, router: router, interactor: interactor, presenter: presenter)
    }

    func makePlayerEdit(using navigationController: UINavigationController = UINavigationController(),
                        for playerEditable: PlayerEditable,
                        delegate: PlayerEditDelegate) -> PlayerEditModule {
        let router = PlayerEditRouter(navigationController: navigationController, moduleFactory: self)
        let view: PlayerEditViewController = Storyboard.defaultStoryboard.instantiateViewController()
        let interactor = PlayerEditInteractor(playerEditable: playerEditable)
        let presenter = PlayerEditPresenter(interactor: interactor, delegate: delegate)
        return PlayerEditModule(view: view, router: router, interactor: interactor, presenter: presenter)
    }
}

Navigating to Edit screen

We show PlayerDetailsView by calling the router from PlayerListPresenter:

func selectRow(at index: Int) {
    guard playersCollectionIsEmpty == false else {
        return
    }

    if isInListViewMode {
        let player = interactor.players[index]
        showDetailsView(for: player)
    } else {
        toggleRow(at: index)
        updateSelectedRows(at: index)
        reloadViewAfterRowSelection(at: index)
    }
}

private func showDetailsView(for player: PlayerResponseModel) {
    router.showDetails(for: player, delegate: self)
}

PlayerListRouter is shown below:

extension PlayerListRouter: PlayerListRouterProtocol {
    func showDetails(for player: PlayerResponseModel, delegate: PlayerDetailDelegate) {
        let module = moduleFactory.makePlayerDetails(using: navigationController, for: player, delegate: delegate)

        if let viewController = module.assemble() {
            navigationController.pushViewController(viewController, animated: true)
        }
    }
}

Now, we use the same approach from Detail screen to Edit screen:

func selectRow(at indexPath: IndexPath) {
    let player = interactor.player
    let rowDetails = sections[indexPath.section].rows[indexPath.row]
    let items = self.items(for: rowDetails.editableField)
    let selectedItemIndex = items.firstIndex(of: rowDetails.value.lowercased())
    let editablePlayerDetails = PlayerEditable(player: player,
                                                items: items,
                                                selectedItemIndex: selectedItemIndex,
                                                rowDetails: rowDetails)

    router.showEditView(with: editablePlayerDetails, delegate: self)
}

And the router:

extension PlayerDetailRouter: PlayerDetailRouterProtocol {
    func showEditView(with editablePlayerDetails: PlayerEditable, delegate: PlayerEditDelegate) {
        let module = moduleFactory.makePlayerEdit(using: navigationController, for: editablePlayerDetails, delegate: delegate)

        if let viewController = module.assemble() {
            navigationController.pushViewController(viewController, animated: true)
        }
    }
}

Navigating back to the List screen

When the user confirms the changes to a player, we call our presenter delegate.

extension PlayerEditPresenter: PlayerEditPresenterServiceHandler {
    func playerWasUpdated() {
        view?.hideLoadingView()
        delegate?.didUpdate(player: interactor.playerEditable.player)
        router.dismissEditView()
    }
}

// MARK: - PlayerEditDelegate
extension PlayerDetailPresenter: PlayerEditDelegate {
    func didUpdate(player: PlayerResponseModel) {
        interactor.updatePlayer(player)
        delegate?.didUpdate(player: player)
    }
}

The delegate is PlayerDetailsPresenter:

Finally, we call the PlayerDetailDelegate (assigned to PlayerListPresenter) and refresh the list of players:

// MARK: - PlayerEditDelegate
extension PlayerListPresenter: PlayerDetailDelegate {
    func didUpdate(player: PlayerResponseModel) {
        interactor.updatePlayer(player)
    }
}

We follow the same approach for Confirm and Add modules:

func confirmOrAddPlayers() {
    if isInListViewMode {
        showAddPlayerView()
    } else {
        showConfirmPlayersView()
    }
}

private var isInListViewMode: Bool {
    viewState == .list
}

private func showAddPlayerView() {
    router.showAddPlayer(delegate: self)
}

private func showConfirmPlayersView() {
    router.showConfirmPlayers(with: interactor.selectedPlayers(atRows: selectedRows), delegate: self)
}

The Router class is presented below:

extension PlayerListRouter: PlayerListRouterProtocol {
    func showAddPlayer(delegate: PlayerAddDelegate) {
        let module = moduleFactory.makePlayerAdd(using: navigationController, delegate: delegate)

        if let viewController = module.assemble() {
            navigationController.pushViewController(viewController, animated: true)
        }
    }

    func showConfirmPlayers(with playersDictionary: [TeamSection: [PlayerResponseModel]], delegate: ConfirmPlayersDelegate) {
        let module = moduleFactory.makeConfirmPlayers(using: navigationController, playersDictionary: playersDictionary, delegate: delegate)

        if let viewController = module.assemble() {
            navigationController.pushViewController(viewController, animated: true)
        }
    }
}

Implementing the service handler in PlayerAddPresenter:

extension PlayerAddPresenter: PlayerAddPresenterServiceHandler {
    func playerWasAdded() {
        view?.hideLoadingView()
        delegate?.didAddPlayer()
        router.dismissAddView()
    }
}

Finally, delegation to the list of players:

// MARK: - PlayerAddDelegate
extension PlayerListPresenter: PlayerAddDelegate {
    func didAddPlayer() {
        loadPlayers()
    }
}

// MARK: - ConfirmPlayersDelegate
extension PlayerListPresenter: ConfirmPlayersDelegate {
    func didEndGather() {
        viewState = .list
        configureView()
        view?.reloadData()
    }
}

In this architecture pattern, we wanted to make the View as passive as we could (this concept should be applied to MVP, too).
For that we created for the table rows, a CellViewPresenter:

protocol PlayerTableViewCellPresenterProtocol: AnyObject {
    var view: PlayerTableViewCellProtocol? { get set }
    var viewState: PlayerListViewState { get set }
    var isSelected: Bool { get set }

    func setupView()
    func configure(with player: PlayerResponseModel)
    func toggle()
}

The concrete class described below:

final class PlayerTableViewCellPresenter: PlayerTableViewCellPresenterProtocol {

    var view: PlayerTableViewCellProtocol?
    var viewState: PlayerListViewState
    var isSelected = false

    init(view: PlayerTableViewCellProtocol? = nil, viewState: PlayerListViewState = .list) {
        self.view = view
        self.viewState = viewState
    }

    func setupView() {
        if viewState == .list {
            view?.setupDefaultView()
        } else {
            view?.setupViewForSelection(isSelected: isSelected)
        }
    }

    func toggle() {
        isSelected.toggle()
        if viewState == .selection {
            view?.setupCheckBoxImage(isSelected: isSelected)
        }
    }

    func configure(with player: PlayerResponseModel) {
        view?.set(nameDescription: player.name)
        setPositionDescription(for: player)
        setSkillDescription(for: player)
    }

    private func setPositionDescription(for player: PlayerResponseModel) {
        let position = player.preferredPosition?.rawValue
        view?.set(positionDescription: "Position: \(position ?? "-")")
    }

    private func setSkillDescription(for player: PlayerResponseModel) {
        let skill = player.skill?.rawValue
        view?.set(skillDescription: "Skill: \(skill ?? "-")")
    }
}

The presenter will update the CellView:

final class PlayerTableViewCell: UITableViewCell, PlayerTableViewCellProtocol {
    @IBOutlet weak var checkboxImageView: UIImageView!
    @IBOutlet weak var playerCellLeftConstraint: NSLayoutConstraint!
    @IBOutlet weak var nameLabel: UILabel!
    @IBOutlet weak var positionLabel: UILabel!
    @IBOutlet weak var skillLabel: UILabel!

    private enum Constants {
        static let playerContentLeftPadding: CGFloat = 10.0
        static let playerContentAndIconLeftPadding: CGFloat = -20.0
    }

    func setupDefaultView() {
        playerCellLeftConstraint.constant = Constants.playerContentAndIconLeftPadding
        setupCheckBoxImage(isSelected: false)
        checkboxImageView.isHidden = true
    }

    func setupViewForSelection(isSelected: Bool) {
        playerCellLeftConstraint.constant = Constants.playerContentLeftPadding
        checkboxImageView.isHidden = false
        setupCheckBoxImage(isSelected: isSelected)
    }

    func setupCheckBoxImage(isSelected: Bool) {
        let imageName = isSelected ? "ticked" : "unticked"
        checkboxImageView.image = UIImage(named: imageName)
    }

    func set(nameDescription: String) {
        nameLabel.text = nameDescription
    }

    func set(positionDescription: String) {
        positionLabel.text = positionDescription
    }

    func set(skillDescription: String) {
        skillLabel.text = skillDescription
    }
}

In PlayerViewController, we have the cellForRowAt method:

func tableView(_ tableView: UITableView, 
    cellForRowAt indexPath: IndexPath
) -> UITableViewCell {
   guard let cell: PlayerTableViewCell = tableView.dequeueReusableCell(withIdentifier: "PlayerTableViewCell") as? PlayerTableViewCell else {
       return UITableViewCell()
   }

   let index = indexPath.row
   let cellPresenter = presenter.cellPresenter(at: index)
   let player = presenter.player(at: index)
   cellPresenter.view = cell
   cellPresenter.setupView()
   cellPresenter.configure(with: player)
   return cell
}

Inside the Presenter we cache the existing cell presenters:

func cellPresenter(at index: Int) -> PlayerTableViewCellPresenterProtocol {
   if let cellPresenter = cellPresenters[index] {
       cellPresenter.viewState = viewState
       return cellPresenter
   }

   let cellPresenter = PlayerTableViewCellPresenter(viewState: viewState)
   cellPresenters[index] = cellPresenter
   return cellPresenter
}

The rest of the code is available in the open-source repository.

Key Metrics

Lines of code — Protocols

Lines of code — View Controllers and Views

Lines of code — Modules

Lines of code — Routers

Lines of code — Presenters

Lines of code — Interactors

Lines of code — Local Models

Unit Tests

Build Times

Tests were run on an 8-Core Intel Core i9, MacBook Pro, 2019. Xcode version: 12.5.1. macOS Big Sur.

Conclusion

VIPER is an excellent architectural choice if you prioritize clean and maintainable code. It allows for strict adherence to the Single Responsibility Principle, and we can even introduce additional layers to further refine our application structure.

One of the standout benefits of VIPER is how straightforward it makes writing unit tests. Its decoupled nature simplifies testability and ensures each component is independently verifiable.

However, VIPER’s modularity comes at a cost. The architecture introduces a significant number of files, protocols, and classes. When UI changes or updates are required, multiple components often need to be modified, which can be time-consuming.

In our specific case, transitioning from MVP-C to VIPER proved to be more challenging compared to other patterns. We had to first merge the View and ViewController layers, then refactor almost every class, and finally create several new files and classes. This transformation required considerable effort and time.

On the positive side, VIPER encourages the creation of small, focused functions, with most performing a single, well-defined task. This improves readability and maintainability.

Another advantage is the use of protocol files. These abstractions decouple the modules from the main .xcodeproj, making it easier to work with static frameworks.

Our ViewControllers saw a significant reduction in size. Collectively, they now total approximately 800 lines of code, which is a dramatic improvement over the 1627 lines we had under MVC. This reduction highlights the benefits of delegating responsibilities to other layers.

However, VIPER introduces new layers, such as:

• Protocols — These define abstractions for the modules, specifying only the structure of the layers.
• Modules — These assemble the VIPER layers and are typically part of the Router, initialized via a factory.
• Interactors — These handle business logic, manage network calls, and orchestrate data flow.

These new layers added 1903 lines of code to our project, increasing its complexity.

Writing unit tests with VIPER was an enjoyable experience. The decoupled components made it easy to test various scenarios, and we achieved 100% code coverage, a noteworthy milestone.

However, one downside is the increased build times. Clearing the Derived Data folder and cleaning the build folder adds 10.43 seconds to the process, which is nearly one second more than when the app used MVVM or MVC. On the bright side, this added time is a small trade-off for the potential bugs we avoid with the improved architecture.

Executing unit tests after a clean build takes around 20 seconds, with a total of 46 tests. The additional files, classes, and dependencies naturally contribute to longer compile times.

Fortunately, we don’t need to clean the build or wipe out the Derived Data folder every time we run unit tests. This task can be delegated to the CI server, reducing the impact on developer productivity.

In conclusion, VIPER is an excellent choice for medium to large applications that are relatively stable and primarily focused on adding new features incrementally. Its advantages in maintainability and testability make it an attractive option for complex projects.

However, it does come with some drawbacks. Firstly, the amount of boilerplate code can feel excessive, and at times, you might question the need to go through multiple layers instead of directly handling tasks in the ViewController.

Secondly, VIPER is not a good fit for small applications where simplicity and rapid development are priorities. Adding redundant files for straightforward tasks can feel unnecessary.

Finally, adopting VIPER may result in longer app compilation and startup times, which can impact the overall development experience.

Thank you for reading until the end! We hope this analysis helps you decide if VIPER is the right choice for your project.

Useful Links

• The iOS App, Football Gather — GitHub Repo Link
• The web server application made in Vapor — GitHub Repo Link
• Vapor 3 Backend APIs article link
• Migrating to Vapor 4 article link
• Model View Controller (MVC) — GitHub Repo Link and article link
• Model View ViewModel (MVVM) — GitHub Repo Link and article link
• Model View Presenter (MVP) — GitHub Repo link and article link
• Coordinator Pattern — MVP with Coordinators (MVP-C) — GitHub Repo link and article link
• View Interactor Presenter Entity Router (VIPER) — GitHub Repo link
• View Interactor Presenter (VIP) — GitHub Repo link and article link

Battle of the iOS Architecture Patterns: View Interactor Presenter Entity Router (VIPER) was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

Motivation

Before diving into iOS app development, it’s crucial to carefully consider the project’s architecture. We need to thoughtfully plan how different pieces of code will fit together, ensuring they remain comprehensible not just today, but months or years later when we need to revisit and modify the codebase. Moreover, a well-structured project helps establish a shared technical vocabulary among team members, making collaboration more efficient.

This article kicks off an exciting series where we’ll explore different architectural approaches by building the same application using various patterns. Throughout the series, we’ll analyze practical aspects like build times and implementation complexity, weigh the pros and cons of each pattern, and most importantly, examine real, production-ready code implementations. This hands-on approach will help you make informed decisions about which architecture best suits your project needs.

Architecture Series Articles

• Model View Controller (MVC)
• Model View ViewModel (MVVM)
• Model View Presenter (MVP)
• Model View Presenter with Coordinators (MVP-C) — Current Article
• View Interactor Presenter Entity Router (VIPER)
• View Interactor Presenter (VIP)

If you’re eager to explore the implementation details directly, you can find the complete source code in our open-source repository here.

Why Your iOS App Needs a Solid Architecture Pattern

The cornerstone of any successful iOS application is maintainability. A well-architected app clearly defines boundaries — you know exactly where view logic belongs, what responsibilities each view controller has, and which components handle business logic. This clarity isn’t just for you; it’s essential for your entire development team to understand and maintain these boundaries consistently.

Here are the key benefits of implementing a robust architecture pattern:

• Maintainability: Makes code easier to update and modify over time
• Testability: Facilitates comprehensive testing of business logic through clear separation of concerns
• Team Collaboration: Creates a shared technical vocabulary and understanding among team members
• Clean Separation: Ensures each component has clear, single responsibilities
• Bug Reduction: Minimizes errors through better organization and clearer interfaces between components

Project Requirements Overview

Given a medium-sized iOS application consisting of 6–7 screens, we’ll demonstrate how to implement it using the most popular architectural patterns in the iOS ecosystem: MVC (Model-View-Controller), MVVM (Model-View-ViewModel), MVP (Model-View-Presenter), VIPER (View-Interactor-Presenter-Entity-Router), VIP (Clean Swift), and the Coordinator pattern. Each implementation will showcase the pattern’s strengths and potential challenges.

Our demo application, Football Gather, is designed to help friends organize and track their casual football matches. It’s complex enough to demonstrate real-world architectural challenges while remaining simple enough to clearly illustrate different patterns.

Core Features and Functionality

• Player Management: Add and maintain a roster of players in the application
• Team Assignment: Flexibly organize players into different teams for each match
• Player Customization: Edit player details and preferences
• Match Management: Set and control countdown timers for match duration

Screen Mockups

Backend

The application is supported by a web backend developed using the Vapor framework, a popular choice for building modern REST APIs in Swift. You can explore the details of this implementation in our article here, which covers the fundamentals of building REST APIs with Vapor and Fluent in Swift. Additionally, we have documented the transition from Vapor 3 to Vapor 4, highlighting the enhancements and new features in our article here.

What Are Coordinators?

The concept of Coordinators was first introduced by Soroush Khanlou in 2015 as a solution for managing flow logic within view controllers.

As your application grows in size and complexity, you may need to reuse view controllers in various contexts. However, coupling flow logic with the view controller makes this difficult to achieve. To implement the pattern effectively, you will need a high-level coordinator that manages the application’s flow, as suggested by Soroush.

Here are a few benefits of extracting flow logic into a coordinator:

• View controllers can focus solely on their primary responsibilities, based on the architecture pattern you’re using in your app (e.g., binding a model to a view).
• The initialization of view controllers is moved to a separate layer, reducing clutter in individual view controllers.

Coordinators help solve several common problems:

• Overstuffed app delegates: App delegates tend to become overloaded with responsibilities. By using a base app coordinator, we can move some of that logic to a more appropriate layer.
• Excessive responsibilities for view controllers: In architectures like MVC, view controllers often handle a variety of tasks — such as model binding, view management, data fetching, and transformation. Coordinators help alleviate this burden.
• Smoother flow: Navigation logic is extracted from view controllers and placed into coordinators, creating a more streamlined process.

The app coordinator is typically responsible for resolving the issue of an overloaded AppDelegate.
Here, you can allocate the window object, create your navigation controller, and initialize the first view controller. In Martin Fowler's "Patterns of Enterprise Application Architecture", this is referred to as the Application Controller.

A key rule for coordinators is that each coordinator maintains an array of its child coordinators. This prevents child coordinators from being deallocated prematurely.
In the case of a tab bar application, each navigation controller has its own coordinator, which is managed by its parent coordinator.

In addition to managing flow logic, coordinators also take over the responsibility of handling model mutations from view controllers.

Advantages

• Each view controller becomes more isolated and focused on its specific task.
• View controllers become more reusable across different parts of the app.
• Every task and sub-task in the app is encapsulated in a dedicated coordinator.
• Coordinators separate the logic of display-binding from side effects.
• Coordinators are fully under your control, making it easier to manage and extend your app’s navigation flow.

The Back Navigation Problem

What happens when the user navigates back in the stack? While we can control custom back buttons, what about when the user swipes right to go back?

One way to solve this problem is to maintain a reference to the coordinator within the view controller and call its didFinish method inside viewDidDisappear. This solution works for simple apps, but it becomes problematic when multiple view controllers are managed by child coordinators.

As Soroush mentions, we can implement the UINavigationControllerDelegate protocol to gain control over these navigation events.

1. Implement UINavigationControllerDelegate in your main app coordinator:
   Focus on the navigationController:didShowViewController:animated: method, which is called after the navigation controller displays a view controller. When this event is triggered (indicating that a view controller has been popped from the stack), you can deallocate the relevant coordinators.
2. Subclass UIViewController to manage coordinators:
   In this special subclass, you can maintain a dictionary of coordinators for your view controllers:
   private var viewControllersToChildCoordinators: [UIViewController: Coordinator] = [:]
   Implement the UINavigationControllerDelegate within this class. When a view controller is popped and exists in the dictionary, it will be removed and deallocated.
   The main tradeoff with this approach is that your subclassed UIViewController ends up taking on more responsibilities than desired.

Applying to our code

We start first with defining our application coordinators:

protocol Coordinator: AnyObject {
    var childCoordinators: [Coordinator] { get set }
    var parent: Coordinator? { get set }

    func start()
}

The start function takes care of allocating the view controller and pushing it into the navigation controller stack.

protocol Coordinatable: AnyObject {
    var coordinator: Coordinator? { get set }
}

We define a Coordinatable project that our view controllers will implement, so they can delegate to their coordinator specific navigation tasks (such as going back).

Next, we create our main app coordinator: AppCoordinator and initialise it within the AppDelegate.

final class AppCoordinator: NSObject, Coordinator {
    weak var parent: Coordinator?
    var childCoordinators: [Coordinator] = []
    
    private let navController: UINavigationController
    private let window: UIWindow

    init(navController: UINavigationController = UINavigationController(),
          window: UIWindow = UIWindow(frame: UIScreen.main.bounds)) {
        self.navController = navController
        self.window = window
    }

    func start() {
        navController.delegate = self
        window.rootViewController = navController
        window.makeKeyAndVisible()
    }
}

The AppDelegate now looks like this:

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    private lazy var appCoordinator = AppCoordinator()

    func application(
        _ application: UIApplication, 
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        appCoordinator.start()
        return true
    }

    // ...
}

Our first screen is Login. We do the following adjustments so it can support coordinators:

final class LoginViewController: UIViewController, Coordinatable {

    @IBOutlet weak var loginView: LoginView!

    weak var coordinator: Coordinator?

    private var loginCoordinator: LoginCoordinator? {
      coordinator as? LoginCoordinator
    }
    // ...
}

extension LoginViewController: LoginViewDelegate {
    // ...
    func didLogin() {
        loginCoordinator?.navigateToPlayerList()
    }

    func didRegister() {
        loginCoordinator?.navigateToPlayerList()
    }
}

The LoginCoordinator is presented below:

final class LoginCoordinator: Coordinator {
    weak var parent: Coordinator?
    var childCoordinators: [Coordinator] = []

    private let navController: UINavigationController

    init(navController: UINavigationController, parent: Coordinator? = nil) {
        self.navController = navController
        self.parent = parent
    }

    func start() {
        let viewController: LoginViewController = Storyboard.defaultStoryboard.instantiateViewController()
        viewController.coordinator = self
        navController.pushViewController(viewController, animated: true)
    }

    func navigateToPlayerList() {
        let playerListCoordinator = PlayerListCoordinator(navController: navController, parent: self)
        playerListCoordinator.start()
        childCoordinators.append(playerListCoordinator)
    }
}

An alternative to Coordinatable, is to use delegation i.e. create a LoginViewControllerDelegate that contains the method navigateToPlayerList, and make LoginCoordinator the delegate of this class.

And the final piece for LoginScreen, is to remove the segues from the storyboard.

As we are going to instantiate all of our view controllers from the storyboard, let’s define a convenient method to do that:

enum Storyboard: String {
    case main = "Main"

    static var defaultStoryboard: UIStoryboard {
        return UIStoryboard(name: Storyboard.main.rawValue, bundle: nil)
    }
}

extension UIStoryboard {
    func instantiateViewController(withIdentifier identifier: String = String(describing: T.self)) -> T {
        return instantiateViewController(withIdentifier: identifier) as! T
    }
}

We now can allocate a view controller by setting the storyboard ID in the designated storyboard and use:

let viewController: PlayerListViewController = Storyboard.defaultStoryboard.instantiateViewController()

PlayerList screen suffers the following adjustments:

• We removed PlayerListTogglable, the pop functionality resides completely in the responsibilities of Coordinators.
• Make it implement Coordinatable so we can have a reference to the View Controller’s coordinator.
• Remove the delegate methods from PlayerDetailViewControllerDelegate, AddPlayerDelegate and PlayerListTogglable.
• Enhance the public API with the methods that will be required after a player is edited (reload data), added and after a gather finishes (toggleViewState).

weak var coordinator: Coordinator?
private var listCoordinator: PlayerListCoordinator? { coordinator as? PlayerListCoordinator }

/// .....
func reloadView() {
    playerListView.loadPlayers()
}

func didEdit(player: PlayerResponseModel) {
    playerListView.didEdit(player: player)
}

func toggleViewState() {
    playerListView.toggleViewState()
}

To navigate to different screens from PlayerList (to Add or Edit screens, for example), we created the appropriate segue identifier in the Presenter and forward it to the ViewController using the View layer. We now deprecated the use of segue identifiers, all routing will be done using Coordinators. So, let’s implement these changes:

protocol PlayerListViewDelegate: AnyObject {
    func didRequestToChangeTitle(_ title: String)
    func addRightBarButtonItem(_ barButtonItem: UIBarButtonItem)
    func presentAlert(title: String, message: String)
    func didRequestPlayerDeletion()
    func viewPlayerDetails(_ player: PlayerResponseModel)
    func addPlayer()
    func confirmPlayers(with playersDictionary: [TeamSection: [PlayerResponseModel]])
}

@IBAction private func confirmOrAddPlayers(_ sender: Any) {
    if presenter.isInListViewMode {
        delegate?.addPlayer()
    } else {
        delegate?.confirmPlayers(with: presenter.playersDictionary)
    }
}

func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
    guard !presenter.playersCollectionIsEmpty else { return }

    if presenter.isInListViewMode {
        let player = presenter.selectPlayerForDisplayingDetails(at: indexPath)
        delegate?.viewPlayerDetails(player)
    } else {
        toggleCellSelection(at: indexPath)
        updateViewForPlayerSelection()
    }
}

PlayerListCoordinator

The coordinator implementation is presented below:

final class PlayerListCoordinator: Coordinator {

    weak var parent: Coordinator?
    var childCoordinators: [Coordinator] = []

    private let navController: UINavigationController
    private var playerListViewController: PlayerListViewController?

    init(navController: UINavigationController, parent: Coordinator? = nil) {
        self.navController = navController
        self.parent = parent
    }

    func start() {
        let viewController: PlayerListViewController = Storyboard.defaultStoryboard.instantiateViewController()
        viewController.coordinator = self
        navController.pushViewController(viewController, animated: true)
    }

    func navigateToPlayerDetails(player: PlayerResponseModel) {
        let playerDetailCoordinator = PlayerDetailCoordinator(navController: navController, parent: self, player: player)
        playerDetailCoordinator.delegate = self
        playerDetailCoordinator.start()
        childCoordinators.append(playerDetailCoordinator)
    }

    func navigateToPlayerAddScreen() {
        let playerAddCoordinator = PlayerAddCoordinator(navController: navController, parent: self)
        playerAddCoordinator.delegate = self
        playerAddCoordinator.start()
        childCoordinators.append(playerAddCoordinator)
    }

    func navigateToConfirmPlayersScreen(with playersDictionary: [TeamSection: [PlayerResponseModel]]) {
        let confirmPlayersCoordinator = ConfirmPlayersCoordinator(navController: navController, parent: self, playersDictionary: playersDictionary)
        confirmPlayersCoordinator.delegate = self
        confirmPlayersCoordinator.start()
        childCoordinators.append(confirmPlayersCoordinator)
    }

There are quite a few changes we had to do to PlayerEdit and PlayerDetail screens.

Firstly, we had to make them implement Coordinatable, so we can have a reference to the coordinators, same as we did for PlayerList.

In PlayerDetails, we had to make setupTitle method public, because when we edit a player and change its name, we will need to communicate this change to the ViewController so it can refresh the navigation title. The title is actually the player name.

Same thing we did to reloadData(), and created a new function updateData(player) to communicate to the View the player changes.

func reloadData() {
   playerDetailView.reloadData()
}

func updateData(player: PlayerResponseModel) {
   playerDetailView.updateData(player: player)
}

We use PlayerDetailViewDelegate to listen to changes that happen in the View layer:

extension PlayerDetailViewController: PlayerDetailViewDelegate {
    func didRequestEditView(with viewType: PlayerEditViewType,
                             playerEditModel: PlayerEditModel?,
                             playerItemsEditModel: PlayerItemsEditModel?) {
        detailCoordinator?.navigateToEditScreen(viewType: viewType,
                                                 playerEditModel: playerEditModel,
                                                 playerItemsEditModel: playerItemsEditModel)
    }
}

PlayerDetailViewDelegate has now changed the simple didRequestEditView method, into the one that you see above.
This is called from didSelectRow table view's delegate:

func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
   presenter.selectPlayerRow(at: indexPath)

    delegate?.didRequestEditView(
        with: presenter.destinationViewType,
        playerEditModel: presenter.playerEditModel,
        playerItemsEditModel: presenter.playerItemsEditModel
    )
}

PlayerDetailCoordinator

Full code below:

protocol PlayerDetailCoordinatorDelegate: AnyObject {
    func didEdit(player: PlayerResponseModel)
}

final class PlayerDetailCoordinator: Coordinator {
    weak var parent: Coordinator?
    var childCoordinators: [Coordinator] = []
    weak var delegate: PlayerDetailCoordinatorDelegate?

    private let navController: UINavigationController
    private let player: PlayerResponseModel
    private var detailViewController: PlayerDetailViewController?

    init(navController: UINavigationController, parent: Coordinator? = nil, player: PlayerResponseModel) {
        self.navController = navController
        self.parent = parent
        self.player = player
    }

    func start() {
        let viewController: PlayerDetailViewController = Storyboard.defaultStoryboard.instantiateViewController()
        viewController.coordinator = self
        viewController.player = player
        detailViewController = viewController
        navController.pushViewController(viewController, animated: true)
    }

    func navigateToEditScreen(viewType: PlayerEditViewType,
                              playerEditModel: PlayerEditModel?,
                              playerItemsEditModel: PlayerItemsEditModel?) {
        let editCoordinator = PlayerEditCoordinator(navController: navController,
                                                    viewType: viewType,
                                                    playerEditModel: playerEditModel,
                                                    playerItemsEditModel: playerItemsEditModel)
        editCoordinator.delegate = self
        editCoordinator.start()
        childCoordinators.append(editCoordinator)
    }
}

extension PlayerDetailCoordinator: PlayerEditCoordinatorDelegate {
    func didFinishEditing(player: PlayerResponseModel) {
        detailViewController?.setupTitle()
        detailViewController?.updateData(player: player)
        detailViewController?.reloadData()
        delegate?.didEdit(player: player)
    }
}

PlayerEditCoordinator

The implementation is pretty straightforward:

protocol PlayerEditCoordinatorDelegate: AnyObject {
    func didFinishEditing(player: PlayerResponseModel)
}

final class PlayerEditCoordinator: Coordinator {
    weak var parent: Coordinator?
    var childCoordinators: [Coordinator] = []
    weak var delegate: PlayerEditCoordinatorDelegate?

    private let navController: UINavigationController
    private let viewType: PlayerEditViewType
    private let playerEditModel: PlayerEditModel?
    private let playerItemsEditModel: PlayerItemsEditModel?

    init(navController: UINavigationController,
         parent: Coordinator? = nil,
         viewType: PlayerEditViewType,
         playerEditModel: PlayerEditModel?,
         playerItemsEditModel: PlayerItemsEditModel?) {
        self.navController = navController
        self.parent = parent
        self.viewType = viewType
        self.playerEditModel = playerEditModel
        self.playerItemsEditModel = playerItemsEditModel
    }

    func start() {
        let viewController: PlayerEditViewController = Storyboard.defaultStoryboard.instantiateViewController()
        viewController.coordinator = self
        viewController.viewType = viewType
        viewController.playerEditModel = playerEditModel
        viewController.playerItemsEditModel = playerItemsEditModel
        navController.pushViewController(viewController, animated: true)
    }

    func didFinishEditingPlayer(_ player: PlayerResponseModel) {
        delegate?.didFinishEditing(player: player)
        navController.popViewController(animated: true)
    }
}

PlayerAddCoordinator

The add players feature is impacted a little, because it’s very simple. The coordinator looks like this:

protocol PlayerAddCoordinatorDelegate: AnyObject {
    func playerWasAdded()
}

final class PlayerAddCoordinator: Coordinator {
    weak var parent: Coordinator?

    var childCoordinators: [Coordinator] = []
    weak var delegate: PlayerAddCoordinatorDelegate?

    private let navController: UINavigationController

    init(navController: UINavigationController, parent: Coordinator? = nil) {
        self.navController = navController
        self.parent = parent
    }

    func start() {
        let viewController: PlayerAddViewController = Storyboard.defaultStoryboard.instantiateViewController()
        viewController.coordinator = self
        navController.pushViewController(viewController, animated: true)
    }

    func playerWasAdded() {
        delegate?.playerWasAdded()
        navController.popViewController(animated: true)
    }
}

In PlayerAddViewController, we modify didAddPlayer (that is called from the View layer) as presented below:

func didAddPlayer() {
    // The delegate is now the addCoordinator.
    // We remove navigationController?.popViewController(animated: true), because we handle this in addCoordinator.
    addCoordinator?.playerWasAdded()
}

ConfirmPlayersCoordinator

In ConfirmPlayers, we take in the selected players dictionary, we choose a team for them and finally we start the gather.

ConfirmPlayersCoordinator looks like this:

protocol ConfirmPlayersCoordinatorDelegate: AnyObject {
    func didEndGather()
}

final class ConfirmPlayersCoordinator: Coordinator {
    weak var parent: Coordinator?
    var childCoordinators: [Coordinator] = []
    weak var delegate: ConfirmPlayersCoordinatorDelegate?

    private let navController: UINavigationController
    private let playersDictionary: [TeamSection: [PlayerResponseModel]]

    init(navController: UINavigationController, parent: Coordinator? = nil, playersDictionary: [TeamSection: [PlayerResponseModel]] = [:]) {
        self.navController = navController
        self.parent = parent
        self.playersDictionary = playersDictionary
    }

    func start() {
        let viewController: ConfirmPlayersViewController = Storyboard.defaultStoryboard.instantiateViewController()
        viewController.coordinator = self
        viewController.playersDictionary = playersDictionary
        navController.pushViewController(viewController, animated: true)
    }

    func navigateToGatherScreen(with gatherModel: GatherModel) {
        let gatherCoordinator = GatherCoordinator(navController: navController, parent: self, gather: gatherModel)
        gatherCoordinator.delegate = self
        gatherCoordinator.start()
        childCoordinators.append(gatherCoordinator)
    }
}

extension ConfirmPlayersCoordinator: GatherCoordinatorDelegate {
    func didEndGather() {
        delegate?.didEndGather()
    }
}

In ConfirmPlayersView we changed the method didStartGather() and passed the GatherModel in the parameter list: func didStartGather(_ gather: GatherModel).

GatherCoordinator

Finally, GatherCoordinator is detailed below:

protocol GatherCoordinatorDelegate: AnyObject {
    func didEndGather()
}

final class GatherCoordinator: Coordinator {
    weak var parent: Coordinator?
    var childCoordinators: [Coordinator] = []
    weak var delegate: GatherCoordinatorDelegate?

    private let navController: UINavigationController
    private let gather: GatherModel

    init(navController: UINavigationController, parent: Coordinator? = nil, gather: GatherModel) {
        self.navController = navController
        self.parent = parent
        self.gather = gather
    }

    func start() {
        let viewController: GatherViewController = Storyboard.defaultStoryboard.instantiateViewController()
        viewController.coordinator = self
        viewController.gatherModel = gather
        navController.pushViewController(viewController, animated: true)
    }

    /// Called from the ViewController
    func didEndGather() {
        delegate?.didEndGather()
    }

GatherViewController’s didEndGather method has reduced considerably from:

func didEndGather() {
    guard let playerListTogglable = navigationController?.viewControllers.first(where: { $0 is PlayerListTogglable }) as? PlayerListTogglable else {
        return
    }

    playerListTogglable.toggleViewState()

    if let playerListViewController = playerListTogglable as? UIViewController {
        navigationController?.popToViewController(playerListViewController, animated: true)
    }
}

To:

func didEndGather() {
    gatherCoordinator?.didEndGather()
}

Key Metrics

Lines of code — Coordinators

Lines of code — View Controllers

Lines of code — Views

Lines of code — Presenters

Lines of code — Local Models

Unit Tests

Build Times

Tests were run in iPhone 8 Simulator, with iOS 14.4, using Xcode 12.5.1 and on an i9 MacBook Pro 2019.

Conclusion

And just like that, we’ve completed another Architecture Series implementation article. Congratulations!

Together, we explored how to integrate the Coordinator pattern into an existing application, simplifying the structure of our View Controllers.

Our journey began with removing all segues from the storyboards, leaving some screens seemingly isolated. If we opened the Main.storyboard again, we wouldn’t easily identify how the screens are connected. While it’s possible to infer the connections based on the positioning of view controllers, this approach isn’t always intuitive or clear.

Next, we introduced new classes at the Application level to define the main coordinator, providing a more structured flow.

Then, we took each module individually, applying the new pattern. This allowed us to streamline the passing of data between screens and manage the navigation flow more effectively. No longer did we need to perform segues or rely on the Presenter for maintaining references to the Model and View Controllers. We also removed the need for back-and-forth referencing between the Presenter and View Controller when preparing for a segue to the next screen.

Finally, we applied the Delegation pattern for communication between child and parent coordinators. For instance, when adding or editing players, the changes communicate back to the player list, triggering a refresh of the screen.

The Coordinator pattern is incredibly effective, and I believe it can be implemented in any app aiming to move away from segues and storyboards, leading to cleaner, more maintainable code.

Looking at the numbers, we introduced 348 new lines of code, but we also reduced 64 lines in the view controllers, improving readability and simplifying their logic.

Interestingly, the LoginViewController saw an increase of three lines of code. But why is that?

In the case of the LoginViewController, the view controller was quite simple, with just a few one-liners for segues. After adopting the Coordinator pattern, we added two new variables:

weak var coordinator: Coordinator?
private var listCoordinator: PlayerListCoordinator? { coordinator as? PlayerListCoordinator }

The Views and Presenters generally maintained the same number of lines of code. However, there was a small increase of 3 lines in the PlayerDetail module, where we added three new variables to be passed to the Edit screen (see didSelectRowAt method). On the plus side, we reduced the 7 lines of code in the PlayerListPresenter.

As anticipated, the primary beneficiaries of this pattern are the View Controllers.

In terms of build times, there was a slight increase due to the addition of new files, which the compiler now needs to process. With a clean build and the Derived Data folder wiped, we noticed a delay of about 2 seconds compared to the MVP version without Coordinators, and a delay of over 5 seconds compared to the MVC version.

However, this isn’t a major issue, as we typically rely on a Continuous Integration (CI) solution, and we don’t need to wait for builds locally before seeing all tests pass.

And with that, we wrap up this chapter of the series!

Useful Links

• The iOS App, Football Gather — GitHub Repo Link
• The web server application made in Vapor — GitHub Repo Link
• Vapor 3 Backend APIs article link
• Migrating to Vapor 4 article link
• Model View Controller (MVC) — GitHub Repo Link and article link
• Model View ViewModel (MVVM) — GitHub Repo Link and article link
• Model View Presenter (MVP) — GitHub Repo link and article link
• Coordinator Pattern — MVP with Coordinators (MVP-C) — GitHub Repo link and article link
• View Interactor Presenter Entity Router (VIPER) — GitHub Repo link and article link
• View Interactor Presenter (VIP) — GitHub Repo link and article link

Battle of the iOS Architecture Patterns: Model View Presenter with Coordinators (MVP-C) was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

Motivation

Before diving into iOS app development, it’s crucial to carefully consider the project’s architecture. We need to thoughtfully plan how different pieces of code will fit together, ensuring they remain comprehensible not just today, but months or years later when we need to revisit and modify the codebase. Moreover, a well-structured project helps establish a shared technical vocabulary among team members, making collaboration more efficient.

This article kicks off an exciting series where we’ll explore different architectural approaches by building the same application using various patterns. Throughout the series, we’ll analyze practical aspects like build times and implementation complexity, weigh the pros and cons of each pattern, and most importantly, examine real, production-ready code implementations. This hands-on approach will help you make informed decisions about which architecture best suits your project needs.

Architecture Series Articles

• Model View Controller (MVC)
• Model View ViewModel (MVVM)
• Model View Presenter (MVP) — Current Article
• Model View Presenter with Coordinators (MVP-C)
• View Interactor Presenter Entity Router (VIPER)
• View Interactor Presenter (VIP)

If you’re eager to explore the implementation details directly, you can find the complete source code in our open-source repository here.

Why Your iOS App Needs a Solid Architecture Pattern

The cornerstone of any successful iOS application is maintainability. A well-architected app clearly defines boundaries — you know exactly where view logic belongs, what responsibilities each view controller has, and which components handle business logic. This clarity isn’t just for you; it’s essential for your entire development team to understand and maintain these boundaries consistently.

Here are the key benefits of implementing a robust architecture pattern:

• Maintainability: Makes code easier to update and modify over time
• Testability: Facilitates comprehensive testing of business logic through clear separation of concerns
• Team Collaboration: Creates a shared technical vocabulary and understanding among team members
• Clean Separation: Ensures each component has clear, single responsibilities
• Bug Reduction: Minimizes errors through better organization and clearer interfaces between components

Project Requirements Overview

Given a medium-sized iOS application consisting of 6–7 screens, we’ll demonstrate how to implement it using the most popular architectural patterns in the iOS ecosystem: MVC (Model-View-Controller), MVVM (Model-View-ViewModel), MVP (Model-View-Presenter), VIPER (View-Interactor-Presenter-Entity-Router), VIP (Clean Swift), and the Coordinator pattern. Each implementation will showcase the pattern’s strengths and potential challenges.

Our demo application, Football Gather, is designed to help friends organize and track their casual football matches. It’s complex enough to demonstrate real-world architectural challenges while remaining simple enough to clearly illustrate different patterns.

Core Features and Functionality

• Player Management: Add and maintain a roster of players in the application
• Team Assignment: Flexibly organize players into different teams for each match
• Player Customization: Edit player details and preferences
• Match Management: Set and control countdown timers for match duration

Screen Mockups

Backend

The application is supported by a web backend developed using the Vapor framework, a popular choice for building modern REST APIs in Swift. You can explore the details of this implementation in our article here, which covers the fundamentals of building REST APIs with Vapor and Fluent in Swift. Additionally, we have documented the transition from Vapor 3 to Vapor 4, highlighting the enhancements and new features in our article here.

What is MVP?

MVP (Model-View-Presenter) is a design pattern used in software development, similar to MVVM (Model-View-ViewModel), but with some key distinctions:

• It introduces a Presenter layer that mediates between the View and the Model.
• The Presenter controls the View and handles the communication between the layers.

Model

• The Model layer encapsulates business data and logic.
• It acts as an interface responsible for managing domain-specific data.

Communication:

• When a user interacts with the View (e.g., clicking a button), the action is communicated to the Presenter, which then interacts with the Model.
• When the Model updates (e.g., fetching new data), the Presenter communicates these changes to the View, ensuring the user interface reflects the latest state.

View

• The View is responsible for rendering the user interface and capturing user interactions.
• Unlike MVVM, the View does not directly handle its state updates. These are managed by the Presenter.

Communication:

• The View does not directly communicate with the Model. All communication flows through the Presenter.

Presenter

• The Presenter handles events triggered by the View and performs the necessary operations with the Model.
• It acts as the intermediary, connecting the View and the Model without embedding logic into the View itself.
• Typically, each Presenter is mapped 1:1 with a View.

Communication:

• The Presenter communicates with both the Model and the View.
• It updates the View when data changes, ensuring the user interface reflects the current state.
• All updates to the View are initiated by the Presenter.

When to Use MVP

The MVP pattern is suitable in scenarios where:

• MVC or MVVM does not provide sufficient modularity or testability for your application.
• You want to make your app more modular and improve code coverage with unit tests.

However, it may not be ideal for beginners or developers with limited iOS development experience, as implementing MVP involves more boilerplate code.

In our app, we have separated the View layer into two components:

• The ViewController, which acts as a Coordinator/Router and holds a reference to the View, often set as an IBOutlet.
• The actual View, which focuses solely on rendering the UI.

Advantages

• Better separation of concerns compared to other patterns.
• Most of the business logic can be unit tested.

Disadvantages

• The “assembly problem” becomes more prominent, requiring additional layers like a Router or Coordinator for navigation and module assembly.
• The Presenter can become overly large and complex due to its responsibilities.

Applying MVP to Our Code

Implementing MVP in our app involves two major steps:

1. Converting existing ViewModels into Presenters.
2. Separating the View from the ViewController to ensure modularity.

The applied MVP pattern is outlined below:

/// FooViewController is the main view controller handling the FooView.
final class FooViewController: UIViewController {

    /// The main view for FooViewController.
    @IBOutlet weak var fooView: FooView!

    /// Called after the controller's view is loaded into memory.
    override func viewDidLoad() {
        super.viewDidLoad()
        setupView()
    }

    /// Sets up the view by assigning the presenter and delegate.
    private func setupView() {
        let presenter = FooPresenter(view: fooView)
        fooView.delegate = self
        fooView.presenter = presenter
        fooView.setupView()
    }

    /// Prepares for a segue to another view controller.
    override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    }
}

/// Conforms FooViewController to FooViewDelegate.
extension FooViewController: FooViewDelegate {
    func didRequestToNavigateToFooDetail() {
        // Perform segue to FooDetail
    }
}

/// A protocol defining delegate methods for FooView.
protocol FooViewDelegate: AnyObject {
    func didRequestToNavigateToFooDetail()
}

/// A protocol defining methods for setting up the view.
protocol FooViewProtocol: AnyObject {
    func setupView()
}

/// Represents the main view of Foo, conforming to FooViewProtocol.
final class FooView: UIView, FooViewProtocol {
    /// The presenter managing the view's business logic.
    var presenter: FooPresenterProtocol = FooPresenter()

    /// A delegate to handle user interactions.
    weak var delegate: FooViewDelegate?

    /// Sets up the view with necessary configurations.
    func setupView() {
    }

    /// Loads data into the view.
    func loadData() {
    }
}

/// A protocol defining methods for presenters managing FooView.
protocol FooPresenterProtocol: AnyObject {
    func loadData()
}

/// A presenter class implementing FooPresenterProtocol.
final class FooPresenter: FooPresenterProtocol {
    /// A weak reference to the view managed by the presenter.
    private(set) weak var view: FooViewProtocol?

    /// Initializes the presenter with an optional view.
    init(view: FooViewProtocol? = nil) {
        self.view = view
    }

    /// Loads data and updates the view.
    func loadData() {
    }
}

LoginPresenter

Let’s see how the LoginPresenter looks like:

/// Defines the public API
protocol LoginPresenterProtocol: AnyObject {
    var rememberUsername: Bool { get }
    var username: String? { get }
    func setRememberUsername(_ value: Bool)
    func setUsername(_ username: String?)
    func performLogin(withUsername username: String?, andPassword password: String?)
    func performRegister(withUsername username: String?, andPassword password: String?)
}

All parameters will be injected through the initialiser.

final class LoginPresenter: LoginPresenterProtocol {
    private weak var view: LoginViewProtocol?
    private let loginService: LoginService
    private let usersService: StandardNetworkService
    private let userDefaults: FootballGatherUserDefaults
    private let keychain: FootbalGatherKeychain

    init(view: LoginViewProtocol? = nil,
         loginService: LoginService = LoginService(),
         usersService: StandardNetworkService = StandardNetworkService(resourcePath: "/api/users"),
         userDefaults: FootballGatherUserDefaults = .shared,
         keychain: FootbalGatherKeychain = .shared) {
        self.view = view
        self.loginService = loginService
        self.usersService = usersService
        self.userDefaults = userDefaults
        self.keychain = keychain
    }

The Keychain interactions are defined below:

var rememberUsername: Bool {
    return userDefaults.rememberUsername ?? true
}

var username: String? {
    return keychain.username
}
func setRememberUsername(_ value: Bool) {
    userDefaults.rememberUsername = value
}
func setUsername(_ username: String?) {
    keychain.username = username
}

And we have the two services:

func performLogin(withUsername username: String?, andPassword password: String?) {
    guard let userText = username, !userText.isEmpty,
          let passwordText = password, !passwordText.isEmpty else {
        // Key difference between MVVM and MVP, the presenter now tells the view what should do.
        view?.handleError(title: "Error", message: "Both fields are mandatory.")
        return
    }

    // Presenter tells the view to present a loading indicator.
    view?.showLoadingView()
    let requestModel = UserRequestModel(username: userText, password: passwordText)
    loginService.login(user: requestModel) { [weak self] result in
        DispatchQueue.main.async {
            self?.view?.hideLoadingView()
            switch result {
            case .failure(let error):
                self?.view?.handleError(title: "Error", message: String(describing: error))
            case .success(_):
                // Go to next screen
                self?.view?.handleLoginSuccessful()
            }
        }
    }
}

The register function is basically the same as the login one:

func performRegister(withUsername username: String?, andPassword password: String?) {
    guard let userText = username, !userText.isEmpty,
          let passwordText = password, !passwordText.isEmpty else {
        view?.handleError(title: "Error", message: "Both fields are mandatory.")
        return
    }

    guard let hashedPasssword = Crypto.hash(message: passwordText) else {
        fatalError("Unable to hash password")
    }

    view?.showLoadingView()

    let requestModel = UserRequestModel(username: userText, password: hashedPasssword)

    usersService.create(requestModel) { [weak self] result in
        DispatchQueue.main.async {
            self?.view?.hideLoadingView()
            switch result {
            case .failure(let error):
                self?.view?.handleError(title: "Error", message: String(describing: error))
            case .success(let resourceId):
                print("Created user: \(resourceId)")
                self?.view?.handleRegisterSuccessful()
            }
        }
    }
}

The LoginView has the following protocols:

// MARK: - LoginViewDelegate
/// A protocol defining the delegate's responsibilities for communicating with the LoginViewController.
protocol LoginViewDelegate: AnyObject {
    /// Presents an alert with a given title and message.
    func presentAlert(title: String, message: String)

    /// Notifies that the login operation was successful.
    func didLogin()

    /// Notifies that the registration operation was successful.
    func didRegister()
}

// MARK: - LoginViewProtocol
/// A protocol defining the public API of the LoginView.
protocol LoginViewProtocol: AnyObject {
    /// Sets up the initial view state.
    func setupView()

    /// Displays a loading indicator.
    func showLoadingView()

    /// Hides the loading indicator.
    func hideLoadingView()

    /// Handles errors by presenting an alert with a given title and message.
    func handleError(title: String, message: String)

    /// Notifies the view that login was successful.
    func handleLoginSuccessful()

    /// Notifies the view that registration was successful.
    func handleRegisterSuccessful()
}

// MARK: - LoginView
/// The view responsible for managing the UI components and communicating with the presenter.
final class LoginView: UIView, Loadable {

    // MARK: - Properties
    @IBOutlet weak var usernameTextField: UITextField!
    @IBOutlet weak var passwordTextField: UITextField!
    @IBOutlet weak var rememberMeSwitch: UISwitch!
    lazy var loadingView = LoadingView.initToView(self)
    weak var delegate: LoginViewDelegate?
    var presenter: LoginPresenterProtocol = LoginPresenter()

    /// Configures the "Remember Me" switch and pre-fills the username if necessary.
    private func configureRememberMe() {
        rememberMeSwitch.isOn = presenter.rememberUsername
        if presenter.rememberUsername {
            usernameTextField.text = presenter.username
        }
    }

    /// Stores the username and the state of the "Remember Me" switch in the presenter.
    private func storeUsernameAndRememberMe() {
        presenter.setRememberUsername(rememberMeSwitch.isOn)
        if rememberMeSwitch.isOn {
            presenter.setUsername(usernameTextField.text)
        } else {
            presenter.setUsername(nil)
        }
    }

    /// Handles the login action and delegates the responsibility to the presenter.
    @IBAction private func login(_ sender: Any) {
        presenter.performLogin(withUsername: usernameTextField.text, andPassword: passwordTextField.text)
    }

    /// Handles the registration action and delegates the responsibility to the presenter.
    @IBAction private func register(_ sender: Any) {
        presenter.performRegister(withUsername: usernameTextField.text, andPassword: passwordTextField.text)
    }
}

// MARK: - LoginViewProtocol Implementation
extension LoginView: LoginViewProtocol {
    func setupView() {
        configureRememberMe()
    }

    func handleError(title: String, message: String) {
        delegate?.presentAlert(title: title, message: message)
    }

    func handleLoginSuccessful() {
        storeUsernameAndRememberMe()
        delegate?.didLogin()
    }

    func handleRegisterSuccessful() {
        storeUsernameAndRememberMe()
        delegate?.didRegister()
    }
}

// MARK: - LoginViewController
/// The controller responsible for managing the login view and handling navigation.
final class LoginViewController: UIViewController {

    // MARK: - Properties
    @IBOutlet weak var loginView: LoginView!
    override func viewDidLoad() {
        super.viewDidLoad()
        setupView()
    }

    /// Configures the view and initializes the presenter.
    private func setupView() {
        let presenter = LoginPresenter(view: loginView)
        loginView.delegate = self
        loginView.presenter = presenter
        loginView.setupView()
    }
}

// MARK: - LoginViewDelegate Implementation
extension LoginViewController: LoginViewDelegate {
    func presentAlert(title: String, message: String) {
        // Presents an alert to the user.
        AlertHelper.present(in: self, title: title, message: message)
    }

    func didLogin() {
        // Navigates to the player list screen after successful login.
        performSegue(withIdentifier: SegueIdentifier.playerList.rawValue, sender: nil)
    }

    func didRegister() {
        // Navigates to the player list screen after successful registration.
        performSegue(withIdentifier: SegueIdentifier.playerList.rawValue, sender: nil)
    }
}

// MARK: - PlayerListPresenter
/// The presenter responsible for handling PlayerList-specific logic.
func performPlayerDeleteRequest() {
    guard let indexPath = indexPathForDeletion else { return }
    view?.showLoadingView()
    requestDeletePlayer(at: indexPath) { [weak self] result in
        if result {
            self?.view?.handlePlayerDeletion(forRowAt: indexPath)
        }
    }
}

Now, the check for player deletion is made inside the Presenter and not in the View/ViewController.

// MARK: - Player Deletion Request
private func requestDeletePlayer(at indexPath: IndexPath, completion: @escaping (Bool) -> Void) {
    let player = players[indexPath.row]
    var service = playersService

    // Request to delete the player
    service.delete(withID: ResourceID.integer(player.id)) { [weak self] result in
        DispatchQueue.main.async {
            // [1] Hide the loading spinner view.
            self?.view?.hideLoadingView()
            // Handle the result of the deletion
            switch result {
            case .failure(let error):
                // [2] Notify the view of the error
                self?.view?.handleError(title: "Error", message: String(describing: error))
                completion(false)
            case .success(_):
                // [3] Notify completion of successful deletion
                completion(true)
            }
        }
    }
}

If we look in the PlayerListView, at the table view's data source methods, we observe that the Presenter is behaving exactly as a ViewModel:

// MARK: - Table View Data Source
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
    // The number of rows is determined by the presenter
    return presenter.numberOfRows
}

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    guard let cell: PlayerTableViewCell = tableView.dequeueReusableCell(
        withIdentifier: "PlayerTableViewCell"
    ) as? PlayerTableViewCell else {
        return UITableViewCell()
    }

    // Check if the presenter is in list view mode
    if presenter.isInListViewMode {
        // Clear any selected player if necessary
        presenter.clearSelectedPlayerIfNeeded(at: indexPath)
        cell.setupDefaultView()
    } else {
        // Setup the cell for selection view
        cell.setupSelectionView()
    }

    // Configure cell with player information provided by the presenter
    cell.nameLabel.text = presenter.playerNameDescription(at: indexPath)
    cell.positionLabel.text = presenter.playerPositionDescription(at: indexPath)
    cell.skillLabel.text = presenter.playerSkillDescription(at: indexPath)
    cell.playerIsSelected = presenter.playerIsSelected(at: indexPath)
    return cell
}

The PlayerListViewController now acts as a router between the Edit, Confirm, and Add screens.

override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    switch segue.identifier {
    case SegueIdentifier.confirmPlayers.rawValue:
        // [1] Compose the selected players that will be added in the ConfirmPlayersPresenter.
        if let confirmPlayersViewController = segue.destination as? ConfirmPlayersViewController {
            confirmPlayersViewController.playersDictionary = playerListView.presenter.playersDictionary
        }

    case SegueIdentifier.playerDetails.rawValue:
        // [2] Set the player that we want to show the details.
        if let playerDetailsViewController = segue.destination as? PlayerDetailViewController,
          let player = playerListView.presenter.selectedPlayerForDetails {
            // [3] From the Details screen, we can edit a player. Using delegation, we listen for
            // such modifications and refresh this view with the updated details.
            playerDetailsViewController.delegate = self
            playerDetailsViewController.player = player
        }
    case SegueIdentifier.addPlayer.rawValue:
        (segue.destination as? PlayerAddViewController)?.delegate = self
    default:
        break
    }
}

Breaking into responsibilities, the PlayerList module has the following components:

PlayerListViewController responsibilities:

• Implements the PlayerListTogglable protocol to return to the listView mode when a gather is completed (called from GatherViewController).
• Holds an IBOutlet to PlayerListView.
• Sets the presenter and view delegate, and instructs the view to set up.
• Handles navigation logic and constructs models for Edit, Add, and Confirm screens.
• Implements the PlayerListViewDelegate, performing operations such as:
• Changing the title when requested (func didRequestToChangeTitle(_ title: String)).
• Adding the right navigation bar button item (Select or Cancel selection of players).
• Performing the appropriate segue with the identifier constructed in the Presenter.
• Presenting alerts for service failures or delete confirmations.
• Implements PlayerDetailViewControllerDelegate to refresh the View when a player is edited.
• Implements AddPlayerDelegate to reload the list of players in the View.

PlayerListView responsibilities:

• Exposes a public API via PlayerListViewProtocol. This layer should remain simple and avoid complex logic.

PlayerListPresenter responsibilities:

• Exposes necessary methods for the View, such as barButtonItemTitle, barButtonItemIsEnabled, etc.

PlayerListViewState responsibilities:

• Uses the Factory Method pattern to manage different states of PlayerListView, encapsulated in a separate file.

PlayerDetail screen

For the PlayerDetail screen, the View is separated from the ViewController.

// MARK: - PlayerDetailViewController
final class PlayerDetailViewController: UIViewController {

    // MARK: - Properties
    @IBOutlet weak var playerDetailView: PlayerDetailView!
    weak var delegate: PlayerDetailViewControllerDelegate?
    var player: PlayerResponseModel?
    // .. other methods
}

Navigation to the Edit screen follows a delegation pattern:

• The user taps a row corresponding to a player property. The View informs the ViewController to edit that field, and the ViewController performs the segue. In the prepare(for segue:) method, required properties are allocated for editing.

extension PlayerDetailViewController: PlayerDetailViewDelegate {
    func didRequestEditView() {
        performSegue(withIdentifier: SegueIdentifier.editPlayer.rawValue, sender: nil)
    }
}

Inside PlayerDetailViewController:

override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    guard segue.identifier == SegueIdentifier.editPlayer.rawValue,
          let destinationViewController = segue.destination as? PlayerEditViewController else {
        return
    }

    let presenter = playerDetailView.presenter
    destinationViewController.viewType = presenter?.destinationViewType ?? .text
    destinationViewController.playerEditModel = presenter?.playerEditModel
    destinationViewController.playerItemsEditModel = presenter?.playerItemsEditModel
    destinationViewController.delegate = self
}

PlayerDetailView:

final class PlayerDetailView: UIView, PlayerDetailViewProtocol {

    // MARK: - Properties
    @IBOutlet weak var playerDetailTableView: UITableView!
    weak var delegate: PlayerDetailViewDelegate?
    var presenter: PlayerDetailPresenterProtocol!
    
    // MARK: - Public API
    var title: String {
        return presenter.title
    }

    func reloadData() {
        playerDetailTableView.reloadData()
    }

    func updateData(player: PlayerResponseModel) {
        presenter.updatePlayer(player)
        presenter.reloadSections()
    }
}

The table view delegate and data source implementation:

extension PlayerDetailView: UITableViewDelegate, UITableViewDataSource {
    func numberOfSections(in tableView: UITableView) -> Int {
        return presenter.numberOfSections
    }

    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return presenter.numberOfRowsInSection(section)
    }

    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        guard let cell = tableView.dequeueReusableCell(withIdentifier: "PlayerDetailTableViewCell") as? PlayerDetailTableViewCell else {
            return UITableViewCell()
        }
        cell.leftLabel.text = presenter.rowTitleDescription(for: indexPath)
        cell.rightLabel.text = presenter.rowValueDescription(for: indexPath)
        return cell
    }

    func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
        return presenter.titleForHeaderInSection(section)
    }

    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        presenter.selectPlayerRow(at: indexPath)
        delegate?.didRequestEditView()
    }
}

Inside PlayerDetailViewController:

/// Prepares for a segue by passing the necessary data to the destination view controller.
override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    // Ensure the segue identifier matches and cast the destination view controller.
    guard segue.identifier == SegueIdentifier.editPlayer.rawValue,
          let destinationViewController = segue.destination as? PlayerEditViewController else {
        return
    }

    // Get the presenter from the player detail view.
    let presenter = playerDetailView.presenter

    // [1] Show the textfield or the picker for editing a player field.
    destinationViewController.viewType = presenter?.destinationViewType ?? .text

    // [2] Pass the edit model to the destination view controller.
    destinationViewController.playerEditModel = presenter?.playerEditModel

    // [3] Pass the data source for picker mode if applicable.
    destinationViewController.playerItemsEditModel = presenter?.playerItemsEditModel

    // Set the delegate to self.
    destinationViewController.delegate = self
}

PlayerDetailView is presented below:

final class PlayerDetailView: UIView, PlayerDetailViewProtocol {

    // MARK: - Properties
    @IBOutlet weak var playerDetailTableView: UITableView!
    weak var delegate: PlayerDetailViewDelegate?
    var presenter: PlayerDetailPresenterProtocol!
    
    // MARK: - Public API
    /// Returns the title for the view.
    var title: String {
        return presenter.title
    }

    /// Reloads the table view data.
    func reloadData() {
        playerDetailTableView.reloadData()
    }

    /// Updates the player data and refreshes the view.
    func updateData(player: PlayerResponseModel) {
        presenter.updatePlayer(player)
        presenter.reloadSections()
    }
}

And the table view delegate and data source implementation:

extension PlayerDetailView: UITableViewDelegate, UITableViewDataSource {

    /// Returns the number of sections in the table view.
    func numberOfSections(in tableView: UITableView) -> Int {
        return presenter.numberOfSections
    }

    /// Returns the number of rows in a given section.
    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return presenter.numberOfRowsInSection(section)
    }

    /// Configures and returns the cell for a given index path.
    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        guard let cell = tableView.dequeueReusableCell(withIdentifier: "PlayerDetailTableViewCell") as? PlayerDetailTableViewCell else {
            return UITableViewCell()
        }
        cell.leftLabel.text = presenter.rowTitleDescription(for: indexPath)
        cell.rightLabel.text = presenter.rowValueDescription(for: indexPath)
        return cell
    }

    /// Returns the title for the header of a section.
    func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
        return presenter.titleForHeaderInSection(section)
    }

    /// Handles the selection of a row and requests the edit view.
    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        presenter.selectPlayerRow(at: indexPath)
        delegate?.didRequestEditView()
    }
}

The PlayerDetailPresenter:

final class PlayerDetailPresenter: PlayerDetailPresenterProtocol {

    // MARK: - Properties
    private(set) var player: PlayerResponseModel
    private lazy var sections = makeSections()
    private(set) var selectedPlayerRow: PlayerRow?

    // MARK: - Public API
    init(player: PlayerResponseModel) {
        self.player = player
    }

    // other methods
}

Edit Screen

We follow the same approach for the remaining screens of the app.
Exemplifying below the PlayerEdit functionality. The PlayerEditView class is basically the new ViewController.

final class PlayerEditView: UIView, Loadable {

    // MARK: - Properties
    @IBOutlet weak var playerEditTextField: UITextField!
    @IBOutlet weak var playerTableView: UITableView!

    private lazy var doneButton = UIBarButtonItem(title: "Done", style: .done, target: self, action: #selector(doneAction))

    lazy var loadingView = LoadingView.initToView(self)
    weak var delegate: PlayerEditViewDelegate?
    var presenter: PlayerEditPresenterProtocol!
    
    // other methods
}

The selectors are pretty straightforward:

// MARK: - Selectors
@objc private func textFieldDidChange(textField: UITextField) {
    doneButton.isEnabled = presenter.doneButtonIsEnabled(newValue: playerEditTextField.text)
}

@objc private func doneAction(sender: UIBarButtonItem) {
    presenter.updatePlayerBasedOnViewType(inputFieldValue: playerEditTextField.text)
}

And the Public API:

extension PlayerEditView: PlayerEditViewProtocol {
    var title: String {
        return presenter.title
    }

    func setupView() {
        setupNavigationItems()
        setupPlayerEditTextField()
        setupTableView()
    }

    func handleError(title: String, message: String) {
        delegate?.presentAlert(title: title, message: message)
    }

    func handleSuccessfulPlayerUpdate() {
        delegate?.didFinishEditingPlayer()
    }
}

Finally, the UITableViewDataSource and UITableViewDelegate methods:

extension PlayerEditView: UITableViewDelegate, UITableViewDataSource {
    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return presenter.numberOfRows
    }

    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        guard let cell = tableView.dequeueReusableCell(withIdentifier: "ItemSelectionCellIdentifier") else {
            return UITableViewCell()
        }
        cell.textLabel?.text = presenter.itemRowTextDescription(indexPath: indexPath)
        cell.accessoryType = presenter.isSelectedIndexPath(indexPath) ? .checkmark : .none
        return cell
    }

    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        if let selectedItemIndex = presenter.selectedItemIndex {
            clearAccessoryType(forSelectedIndex: selectedItemIndex)
        }
        presenter.updateSelectedItemIndex(indexPath.row)
        tableView.cellForRow(at: indexPath)?.accessoryType = .checkmark
        doneButton.isEnabled = presenter.doneButtonIsEnabled(selectedIndexPath: indexPath)
    }

    private func clearAccessoryType(forSelectedIndex selectedItemIndex: Int) {
        let indexPath = IndexPath(row: selectedItemIndex, section: 0)
        playerTableView.cellForRow(at: indexPath)?.accessoryType = .none
    }

    func tableView(_ tableView: UITableView, didDeselectRowAt indexPath: IndexPath) {
        tableView.cellForRow(at: indexPath)?.accessoryType = .none
    }
}

PlayerEditPresenter handles the business logic and exposes the properties for updating the UI elements.

final class PlayerEditPresenter: PlayerEditPresenterProtocol {

    // MARK: - Properties
    private weak var view: PlayerEditViewProtocol?
    private var playerEditModel: PlayerEditModel
    private var viewType: PlayerEditViewType
    private var playerItemsEditModel: PlayerItemsEditModel?
    private var service: StandardNetworkService

    // MARK: - Public API
    init(view: PlayerEditViewProtocol? = nil,
          viewType: PlayerEditViewType = .text,
          playerEditModel: PlayerEditModel,
          playerItemsEditModel: PlayerItemsEditModel? = nil,
          service: StandardNetworkService = StandardNetworkService(resourcePath: "/api/players", authenticated: true)) {
        self.view = view
        self.viewType = viewType
        self.playerEditModel = playerEditModel
        self.playerItemsEditModel = playerItemsEditModel
        self.service = service
    }
    // other methods
}

An API call is detailed below:

func updatePlayerBasedOnViewType(inputFieldValue: String?) {
    // [1] Check if we updated something.
    guard shouldUpdatePlayer(inputFieldValue: inputFieldValue) else { return }

    // [2] Present a loading indicator.
    view?.showLoadingView()
    let fieldValue = isSelectionViewType ? selectedItemValue : inputFieldValue
    
    // [3] Make the Network call.
    updatePlayer(newFieldValue: fieldValue) { [weak self] updated in
        DispatchQueue.main.async {
            self?.view?.hideLoadingView()
            self?.handleUpdatedPlayerResult(updated)
        }
    }
}

PlayerAdd, Confirm and Gather screens follow the same approach.

Testing our business logic

The testing approach is 90% the same as we did for MVVM.

In addition, we need to mock the view and check if the appropriate methods were called. For example, when a service API call is made, check if the view reloaded its state or handled the error in case of failures.

Unit Testing below GatherPresenter:

// [1] Basic setup
final class GatherPresenterTests: XCTestCase {

    // [2] Define the Mocked network classes.
    private let session = URLSessionMockFactory.makeSession()
    private let resourcePath = "/api/gathers"
    private let appKeychain = AppKeychainMockFactory.makeKeychain()

    // [3] Setup and clear the Keychain variables.
    override func setUp() {
        super.setUp()
        appKeychain.token = ModelsMock.token
    }

    override func tearDown() {
        appKeychain.storage.removeAll()
        super.tearDown()
    }
}

Testing the countdownTimerLabelText:

func testFormattedCountdownTimerLabelText_whenViewModelIsAllocated_returnsDefaultTime() {
    // given
    let gatherTime = GatherTime.defaultTime
    let expectedFormattedMinutes = gatherTime.minutes < 10 ? "0\(gatherTime.minutes)" : "\(gatherTime.minutes)"
    let expectedFormattedSeconds = gatherTime.seconds < 10 ? "0\(gatherTime.seconds)" : "\(gatherTime.seconds)"
    let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
    let sut = GatherPresenter(gatherModel: mockGatherModel)

    // when
    let formattedCountdownTimerLabelText = sut.formattedCountdownTimerLabelText

    // then
    XCTAssertEqual(formattedCountdownTimerLabelText, "\(expectedFormattedMinutes):\(expectedFormattedSeconds)")
}

func testFormattedCountdownTimerLabelText_whenPresenterIsAllocated_returnsDefaultTime() {
    // given
    let gatherTime = GatherTime.defaultTime
    let expectedFormattedMinutes = gatherTime.minutes < 10 ? "0\(gatherTime.minutes)" : "\(gatherTime.minutes)"
    let expectedFormattedSeconds = gatherTime.seconds < 10 ? "0\(gatherTime.seconds)" : "\(gatherTime.seconds)"
    let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
    let sut = GatherPresenter(gatherModel: mockGatherModel)

    // when
    let formattedCountdownTimerLabelText = sut.formattedCountdownTimerLabelText

    // then
    XCTAssertEqual(formattedCountdownTimerLabelText, "\(expectedFormattedMinutes):\(expectedFormattedSeconds)")
}

func testFormattedCountdownTimerLabelText_whenTimeIsZero_returnsZeroSecondsZeroMinutes() {
    // given
    let mockGatherTime = GatherTime(minutes: 0, seconds: 0)
    let mockGatherTimeHandler = GatherTimeHandler(selectedTime: mockGatherTime)
    let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
    let sut = GatherPresenter(gatherModel: mockGatherModel, timeHandler: mockGatherTimeHandler)

    // when
    let formattedCountdownTimerLabelText = sut.formattedCountdownTimerLabelText

    // then
    XCTAssertEqual(formattedCountdownTimerLabelText, "00:00")
}

func testFormattedCountdownTimerLabelText_whenTimeHasMinutesAndZeroSeconds_returnsMinutesAndZeroSeconds() {
    // given
    let mockGatherTime = GatherTime(minutes: 10, seconds: 0)
    let mockGatherTimeHandler = GatherTimeHandler(selectedTime: mockGatherTime)
    let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
    let sut = GatherPresenter(gatherModel: mockGatherModel, timeHandler: mockGatherTimeHandler)

    // when
    let formattedCountdownTimerLabelText = sut.formattedCountdownTimerLabelText

    // then
    XCTAssertEqual(formattedCountdownTimerLabelText, "10:00")
}

func testFormattedCountdownTimerLabelText_whenTimeHasSecondsAndZeroMinutes_returnsSecondsAndZeroMinutes() {
    // given
    let mockGatherTime = GatherTime(minutes: 0, seconds: 10)
    let mockGatherTimeHandler = GatherTimeHandler(selectedTime: mockGatherTime)
    let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
    let sut = GatherPresenter(gatherModel: mockGatherModel, timeHandler: mockGatherTimeHandler)

    // when
    let formattedCountdownTimerLabelText = sut.formattedCountdownTimerLabelText

    // then
    XCTAssertEqual(formattedCountdownTimerLabelText, "00:10")
}

Toggle timer becomes more interesting:

func testToggleTimer_whenSelectedTimeIsNotValid_returns() {
    // given
    let mockGatherTime = GatherTime(minutes: -1, seconds: -1)
    let mockGatherTimeHandler = GatherTimeHandler(selectedTime: mockGatherTime)
    let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
    // [1] Allocate the mock view.
    let mockView = MockView()
    let sut = GatherPresenter(view: mockView, gatherModel: mockGatherModel, timeHandler: mockGatherTimeHandler)

    // when
    sut.toggleTimer()

    // then
    // [2] configureSelectedTime() was not called.
    XCTAssertFalse(mockView.selectedTimeWasConfigured)
}

func testToggleTimer_whenSelectedTimeIsValid_updatesTime() {
    // given
    let numberOfUpdateCalls = 2
    let mockGatherTime = GatherTime(minutes: 0, seconds: numberOfUpdateCalls)
    let mockGatherTimeHandler = GatherTimeHandler(selectedTime: mockGatherTime)
    let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
    // [1] Configure the mock view parameters
    let exp = expectation(description: "Waiting timer expectation")
    let mockView = MockView()
    mockView.numberOfUpdateCalls = numberOfUpdateCalls
    mockView.expectation = exp
    let sut = GatherPresenter(view: mockView, gatherModel: mockGatherModel, timeHandler: mockGatherTimeHandler)

    // when
    sut.toggleTimer()

    // then
    // Selector should be called two times.
    waitForExpectations(timeout: 5) { _ in
        XCTAssertTrue(mockView.selectedTimeWasConfigured)
        XCTAssertEqual(mockView.actualUpdateCalls, numberOfUpdateCalls)
        sut.stopTimer()
    }
}

And below is the mock view:

/// This extension contains a mock view implementation used for testing purposes
private extension GatherPresenterTests {

    /// MockView conforms to GatherViewProtocol and helps in testing the GatherPresenter logic
    final class MockView: GatherViewProtocol {
        /// Indicates whether the selected time was configured in the view
        private(set) var selectedTimeWasConfigured = false

        weak var expectation: XCTestExpectation? = nil
        var numberOfUpdateCalls = 1
        private(set) var actualUpdateCalls = 0

        /// Configures the selected time when called
        func configureSelectedTime() {
            selectedTimeWasConfigured = true
            actualUpdateCalls += 1
            if expectation != nil && numberOfUpdateCalls == actualUpdateCalls {
                expectation?.fulfill()
            }
        }

        /// Handles the successful end of the gather process and fulfills the expectation
        func handleSuccessfulEndGather() {
            expectation?.fulfill()
        }

        /// Sets up the view (no implementation for testing purposes)
        func setupView() {}

        /// Shows a loading view (no implementation for testing purposes)
        func showLoadingView() {}

        /// Hides the loading view (no implementation for testing purposes)
        func hideLoadingView() {}

        /// Handles an error and displays the message (no implementation for testing purposes)
        func handleError(title: String, message: String) {}

        /// Confirms the end of the gather process (no implementation for testing purposes)
        func confirmEndGather() {}
    }
}

I’d say that testing the presenter is very cool. You don’t need to do magic stuff, and the methods are very small in size which is helping.
The complex thing comes with the fact that you will need to mock the View layer and check if some parameters are changing accordingly.

Key Metrics

Lines of code — View Controllers

Lines of code — Views

Lines of code — Presenters

Lines of code — Local Models

Unit Tests

Build Times

Tests were run in iPhone 8 Simulator, with iOS 14.3, using Xcode 12.4 and on an i9 MacBook Pro 2019.

Conclusion

In this refactor, we successfully transitioned the application from the MVVM architecture to MVP. The process was straightforward: we replaced each ViewModel with a corresponding Presenter layer, ensuring that our application followed the new pattern seamlessly.

Additionally, we introduced a new View layer, separating it from the ViewController to further clarify the division of responsibilities. This made the codebase cleaner, with thinner view controllers and smaller, more focused classes and functions that adhere to the Single Responsibility Principle (SRP).

Personally, I find the MVP pattern more intuitive, especially for apps built with UIKit. It offers a more natural approach compared to MVVM in this context.

Looking at the key metrics, we can draw the following conclusions:

• The View Controllers are significantly thinner; we reduced their size by more than 1,000 lines of code.
• A new View layer was introduced for managing UI updates, improving clarity and separation of concerns.
• Presenters are larger than ViewModels due to their added responsibility of managing the views.
• Unit testing was similar to the MVVM approach, resulting in almost identical code coverage of 97.2%.
• While the number of files and classes increased, the impact on build time was minimal, increasing by just 530 ms compared to MVVM, and 400 ms compared to MVC.
• Surprisingly, the average unit test execution time was faster by 1.36 seconds compared to MVVM.
• Unit tests for business logic were considerably easier to write when compared to the MVC pattern.

It’s exciting to see how transforming an app from MVVM to MVP can improve structure and maintainability. From my perspective, separating the View from the ViewController in MVP offers a cleaner and more powerful

Useful Links

• The iOS App, Football Gather — GitHub Repo Link
• The web server application made in Vapor — GitHub Repo Link
• Vapor 3 Backend APIs article link
• Migrating to Vapor 4 article link
• Model View Controller (MVC) — GitHub Repo Link and article link
• Model View ViewModel (MVVM) — GitHub Repo Link and article link
• Model View Presenter (MVP) — GitHub Repo link and article link
• Coordinator Pattern — MVP with Coordinators (MVP-C) — GitHub Repo link and article link
• View Interactor Presenter Entity Router (VIPER) — GitHub Repo link and article link
• View Interactor Presenter (VIP) — GitHub Repo link and article link

Battle of the iOS Architecture Patterns: Model View Presenter (MVP) was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

Motivation

Before diving into iOS app development, it’s crucial to carefully consider the project’s architecture. We need to thoughtfully plan how different pieces of code will fit together, ensuring they remain comprehensible not just today, but months or years later when we need to revisit and modify the codebase. Moreover, a well-structured project helps establish a shared technical vocabulary among team members, making collaboration more efficient.

This article kicks off an exciting series where we’ll explore different architectural approaches by building the same application using various patterns. Throughout the series, we’ll analyze practical aspects like build times and implementation complexity, weigh the pros and cons of each pattern, and most importantly, examine real, production-ready code implementations. This hands-on approach will help you make informed decisions about which architecture best suits your project needs.

Architecture Series Articles

• Model View Controller (MVC)
• Model View ViewModel (MVVM) — Current Article
• Model View Presenter (MVP)
• Model View Presenter with Coordinators (MVP-C)
• View Interactor Presenter Entity Router (VIPER)
• View Interactor Presenter (VIP)

If you’re eager to explore the implementation details directly, you can find the complete source code in our open-source repository here.

Why Your iOS App Needs a Solid Architecture Pattern

The cornerstone of any successful iOS application is maintainability. A well-architected app clearly defines boundaries — you know exactly where view logic belongs, what responsibilities each view controller has, and which components handle business logic. This clarity isn’t just for you; it’s essential for your entire development team to understand and maintain these boundaries consistently.

Here are the key benefits of implementing a robust architecture pattern:

• Maintainability: Makes code easier to update and modify over time
• Testability: Facilitates comprehensive testing of business logic through clear separation of concerns
• Team Collaboration: Creates a shared technical vocabulary and understanding among team members
• Clean Separation: Ensures each component has clear, single responsibilities
• Bug Reduction: Minimizes errors through better organization and clearer interfaces between components

Project Requirements Overview

Given a medium-sized iOS application consisting of 6–7 screens, we’ll demonstrate how to implement it using the most popular architectural patterns in the iOS ecosystem: MVC (Model-View-Controller), MVVM (Model-View-ViewModel), MVP (Model-View-Presenter), VIPER (View-Interactor-Presenter-Entity-Router), VIP (Clean Swift), and the Coordinator pattern. Each implementation will showcase the pattern’s strengths and potential challenges.

Our demo application, Football Gather, is designed to help friends organize and track their casual football matches. It’s complex enough to demonstrate real-world architectural challenges while remaining simple enough to clearly illustrate different patterns.

Core Features and Functionality

• Player Management: Add and maintain a roster of players in the application
• Team Assignment: Flexibly organize players into different teams for each match
• Player Customization: Edit player details and preferences
• Match Management: Set and control countdown timers for match duration

Screen Mockups

Backend

The application is supported by a web backend developed using the Vapor framework, a popular choice for building modern REST APIs in Swift. You can explore the details of this implementation in our article here, which covers the fundamentals of building REST APIs with Vapor and Fluent in Swift. Additionally, we have documented the transition from Vapor 3 to Vapor 4, highlighting the enhancements and new features in our article here.

What is MVVM

MVVM stands for Model View ViewModel, an architecture pattern that is used naturally with RxSwift where you can bind your UI elements to the Model classes through the ViewModel.

It is a newer pattern, proposed in 2005 by John Gossman and has the role of extracting the Model from the ViewController. The interaction between the ViewController and the Model is done through a new layer, called ViewModel.

Model

• The same layer we had in MVC, and is used to encapsulate data and the business logic.

Communication

• When something happens in the view layer, for example when the user initiates an action, it is communicated to the model through the ViewModel.
• When the model is changed, for example when new data is made available and we need to update the UI, the model notifies the ViewModel.

View

• View and ViewController are the layers where the visual elements reside.
• The View contains the UI elements, such as buttons, labels, table views and the ViewController is the owner of the View.
• This layer is the same as in MVC, but the ViewController is now part of it and will be changed to reference the ViewModel.

Communication

• Views can’t communicate directly with the Model, everything is done through the ViewModel.

ViewModel

• A new layer that sits between the View/View Controller and the Model.
• Through binding, it updates the UI elements when something has changed in the Model.
• Is a canonical representation of the View.
• Provides interfaces to the View.

Communication

• Can communicate with both layers, Model and View/View Controller.
• Via binding, ViewModels trigger changes to the data of the Model layer
• When data changes, it makes sure those changes are communicated to the user interface, updating the View (again through a binding).

Different flavours of MVVM

The way you apply MVVM depends on how you choose to implement the binding:

• Using a 3rd party, such as RxSwift.
• KVO — Key Value Observing.
• Manually.

In our demo app we will explore the manual approach.

How and when to use MVVM

When you see the ViewController does a lot of stuff and might turn to be massive, you can start looking at different patterns, such as MVVM.

Advantages:

• Slims down the ViewController.
• Easier to test the business logic, because you now have a dedicated layer that handles data.
• Provides a better separation of concerns

Disadvantages:

• Same as in MVC, if is not applied correctly and you are not careful of SRP (Single Responsibility Principle), it can turn out into a Massive ViewModel.
• Can be overkill and too complex for small projects (for example, in a Hackathon app/prototype).
• Adopting a 3rd party increases the app size and can impact the performance.
• Doesn’t feel natural to iOS app development with UIKit. On the other hand, for apps developed with SwiftUI makes perfect sense.

Below you can find a collection of links that tell you more about this code architecture pattern:

• Book about MVVM on raywenderlich.
• Article about MVVM in iOS
• Article “How to not get desperate with MVVM implementation”
• Introduction to Model/View/ViewModel pattern for building WPF apps
• MVVM vs MVC
• Using MVV in iOS
• Practical MVVM + RxSwift
• MVVM with RxSwift
• How to integrate RxSwift in your MVVM architecture
• What Are the Benefits of Model-View-ViewModel
• MVVM Pattern Advantages — Benefits of Using MVVM Model
• Advantages and disadvantages of M-V-VM
• MVVM-1: A General Discussion

Applying to our code

This is pretty straightforward. We go into each ViewController and extract the business logic into a new layer (ViewModel).

Decoupling LoginViewController from business logic

Transformations:

• viewModel - A new layer that handles the view state and the model updates.
• The services are now part of the ViewModel layer.

In viewDidLoad method, we call configureRememberMe() function. Here, we can observe how the View asks the ViewModel for the values of the "Remember Me" UISwitch and the username:

/// Configures the "Remember Me" functionality by setting up the switch state and username field
private func configureRememberMe() {
    // Set the switch state based on user's saved preference
    rememberMeSwitch.isOn = viewModel.rememberUsername
    
    // If "Remember Me" was enabled, populate the username field
    // with the previously stored username
    if viewModel.rememberUsername {
        usernameTextField.text = viewModel.username
    }
}

For the Login and Register actions, we tell the ViewModel to handle the service requests. We use closures for updating the UI once the server API call finished.

/// Handles the login button action
@IBAction func login(_ sender: Any) {
    // Validate that both username and password fields are filled
    guard let userText = usernameTextField.text, userText.isEmpty == false,
          let passwordText = passwordTextField.text, passwordText.isEmpty == false else {
        AlertHelper.present(in: self, title: "Error", message: "Both fields are mandatory.")
        return
    }
    
    // Show loading indicator while performing login
    showLoadingView()
    
    // Attempt to login using the ViewModel
    viewModel.performLogin(withUsername: userText, andPassword: passwordText) { [weak self] error in
        DispatchQueue.main.async {
            self?.hideLoadingView()
            self?.handleServiceResponse(error: error)
        }
    }
}

/// Handles the API response from login attempt
private func handleServiceResponse(error: Error?) {
    if let error = error {
        // Show error alert if login failed
        AlertHelper.present(in: self, title: "Error", message: String(describing: error))
    } else {
        handleSuccessResponse()
    }
}
/// Handles successful login by storing credentials and navigating to PlayerList
private func handleSuccessResponse() {
    storeUsernameAndRememberMe()
    performSegue(withIdentifier: SegueIdentifier.playerList.rawValue, sender: nil)
}
/// Stores the username and remember me preference in the ViewModel
private func storeUsernameAndRememberMe() {
    // Update remember me preference
    viewModel.setRememberUsername(rememberMeSwitch.isOn)
    
    // Store or clear username based on remember me switch
    if rememberMeSwitch.isOn {
        viewModel.setUsername(usernameTextField.text)
    } else {
        viewModel.setUsername(nil)
    }
}

The LoginViewModel is defined by the following properties:

/// ViewModel responsible for handling login-related business logic and data management
struct LoginViewModel {
    // MARK: - Dependencies
    
    /// Service handling login authentication
    private let loginService: LoginService
    
    /// Service handling user-related network operations
    private let usersService: StandardNetworkService
    
    /// Persistent storage for user preferences
    private let userDefaults: FootballGatherUserDefaults
    
    /// Secure storage for sensitive user data
    private let keychain: FootbalGatherKeychain
}

We have the services that were passed from LoginViewController (LoginService, StandardNetworkService used for registering the user and the Storage facilitators - UserDefaults and Keychain wrappers).
All of them are injected through the initializer:

/// Initializes the LoginViewModel with customizable dependencies
init(
    loginService: LoginService = LoginService(),
    usersService: StandardNetworkService = StandardNetworkService(
        resourcePath: "/api/users"
    ),
    userDefaults: FootballGatherUserDefaults = .shared,
    keychain: FootbalGatherKeychain = .shared
) {
    self.loginService = loginService
    self.usersService = usersService
    self.userDefaults = userDefaults
    self.keychain = keychain
}

This comes in handy for unit testing if we want to use our own Mocked services or storages.
The Public API is clean and simple:

// MARK: - User Preferences

/// Returns whether the "Remember Username" feature is enabled
/// Defaults to true if not previously set
var rememberUsername: Bool {
    return userDefaults.rememberUsername ?? true
}

/// Returns the stored username if "Remember Username" is enabled
/// Returns nil if no username is stored or feature is disabled
var username: String? {
    return keychain.username
}

/// Updates the "Remember Username" preference
/// - Parameter value: Boolean indicating if username should be remembered
func setRememberUsername(_ value: Bool) {
    userDefaults.rememberUsername = value
}

/// Stores or clears the username in secure storage
/// - Parameter username: The username to store, or nil to clear
func setUsername(_ username: String?) {
    keychain.username = username
}

And the two server API calls:

/// Attempts to log in a user with the provided credentials
/// - Parameters:
///   - username: The user's username
///   - password: The user's password
///   - completion: Callback with optional error if login fails
func performLogin(
    withUsername username: String,
    andPassword password: String,
    completion: @escaping (Error?) -> ()
) {
    // Create request model with user credentials
    let requestModel = UserRequestModel(username: username, password: password)
    
    // Attempt login with service
    loginService.login(user: requestModel) { result in
        switch result {
        case .failure(let error):
            completion(error)
            
        case .success(_):
            completion(nil)
        }
    }
}

/// Registers a new user with the provided credentials
/// - Parameters:
///   - username: The desired username
///   - password: The user's password (will be hashed)
///   - completion: Callback with optional error if registration fails
func performRegister(
    withUsername username: String,
    andPassword password: String,
    completion: @escaping (Error?) -> ()
) {
    // Hash the password for security
    guard let hashedPasssword = Crypto.hash(message: password) else {
        fatalError("Unable to hash password")
    }
    
    // Create request model with hashed credentials
    let requestModel = UserRequestModel(
        username: username,
        password: hashedPasssword
    )
    
    // Attempt to create user with service
    usersService.create(requestModel) { result in
        switch result {
        case .failure(let error):
            completion(error)
            
        case .success(let resourceId):
            print("Created user: \(resourceId)")
            completion(nil)
        }
    }
}

As you can see, the code looks much cleaner by separating the Model from the ViewController. Now, the View / ViewController asks the ViewModel for what it needs.

PlayerListViewController is much bigger, harder to refactor and to extract the business logic than the LoginViewController.
First, we want to leave just the outlets and all UIView objects we require for this class.
In viewDidLoad, we will do the setup and configuration of the initial state of the views, setting the view model delegate and trigger the player load through the view model.

Loading players:

/// Loads players from the server and updates the UI accordingly
private func loadPlayers() {
    // Disable user interaction while loading
    view.isUserInteractionEnabled = false
    
    // Request players from ViewModel
    viewModel.fetchPlayers { [weak self] error in
        DispatchQueue.main.async {
            // Re-enable user interaction
            self?.view.isUserInteractionEnabled = true
            
            // Handle the response
            if let error = error {
                self?.handleServiceFailures(withError: error)
            } else {
                self?.handleLoadPlayersSuccessfulResponse()
            }
        }
    }
}

The response handling is similar as we have in LoginViewController:

/// Handles service failure by presenting an error alert to the user
private func handleServiceFailures(withError error: Error) {
    AlertHelper.present(in: self, title: "Error", message: String(describing: error))
}

/// Handles successful loading of players by updating the UI
private func handleLoadPlayersSuccessfulResponse() {
    if viewModel.playersCollectionIsEmpty {
        // The players array is empty, show the empty view
        showEmptyView()
    } else {
        // Players are available, hide the empty view
        hideEmptyView()
    }
    // Reload the players table view to reflect the latest data
    playerTableView.reloadData()
}

To display the model properties in the table view’s cell and configure it, we ask the ViewModel to give us the primitives and then we set them to the cell’s properties:

/// Returns the number of rows in the section, which is the number of players
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
    return viewModel.numberOfRows
}

/// Configures and returns the cell for the given index path
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    guard let cell = tableView.dequeueReusableCell(withIdentifier: "PlayerTableViewCell") as? PlayerTableViewCell else {
        return UITableViewCell()
    }
    if viewModel.isInListViewMode {
        // Default view mode, showing the players
        viewModel.clearSelectedPlayerIfNeeded(at: indexPath)
        cell.setupDefaultView()
    } else {
        // Selection view mode for gathering players
        cell.setupSelectionView()
    }
    // Display the model properties in the cell's properties
    cell.nameLabel.text = viewModel.playerNameDescription(at: indexPath)
    cell.positionLabel.text = viewModel.playerPositionDescription(at: indexPath)
    cell.skillLabel.text = viewModel.playerSkillDescription(at: indexPath)
    cell.playerIsSelected = viewModel.playerIsSelected(at: indexPath)
    return cell
}

To delete a player, we do the following:

/// Determines if a row can be edited, only in list view mode
func tableView(_ tableView: UITableView, canEditRowAt indexPath: IndexPath) -> Bool {
    return viewModel.isInListViewMode
}

/// Handles the commit editing style for deleting a player
func tableView(_ tableView: UITableView, commit editingStyle: UITableViewCell.EditingStyle, forRowAt indexPath: IndexPath) {
    guard editingStyle == .delete else { return }

    // Present a confirmation alert
    let alertController = UIAlertController(title: "Delete player", message: "Are you sure you want to delete the selected player?", preferredStyle: .alert)
    let confirmAction = UIAlertAction(title: "Delete", style: .destructive) { [weak self] _ in
        self?.handleDeletePlayerConfirmation(forRowAt: indexPath)
    }
    alertController.addAction(confirmAction)

    let cancelAction = UIAlertAction(title: "Cancel", style: .cancel, handler: nil)
    alertController.addAction(cancelAction)
    present(alertController, animated: true, completion: nil)
}

/// Handles the confirmation of player deletion
private func handleDeletePlayerConfirmation(forRowAt indexPath: IndexPath) {
    requestDeletePlayer(at: indexPath) { [weak self] result in
        guard result, let self = self else { return }

        // In case the service succeeded, delete locally the player
        self.playerTableView.beginUpdates()
        self.viewModel.deleteLocallyPlayer(at: indexPath)

        self.playerTableView.deleteRows(at: [indexPath], with: .fade)
        self.playerTableView.endUpdates()

        // Check if we need to display the empty view in case we haven't any players left
        if self.viewModel.playersCollectionIsEmpty {
            self.showEmptyView()
        }
    }
}

/// Requests the deletion of a player from the server
private func requestDeletePlayer(at indexPath: IndexPath, completion: @escaping (Bool) -> Void) {
    viewModel.requestDeletePlayer(at: indexPath) { [weak self] error in
        DispatchQueue.main.async {
            self?.hideLoadingView()
            if let error = error {
                self?.handleServiceFailures(withError: error)
                completion(false)
            } else {
                completion(true)
            }
        }
    }
}

The navigation to Confirm / Detail and Add screens is done through performSegue. We choose PlayerListViewModel to be responsible to create the next screens view models and inject them in prepareForSegue.
This is not the best approach, because we violate the SRP principle, but we will see in the Coordinator article how we can solve this problem.

/// Prepares for navigation by configuring the destination view controller
override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    switch segue.identifier {
    case SegueIdentifier.confirmPlayers.rawValue:
        if let confirmPlayersViewController = segue.destination as? ConfirmPlayersViewController {
            // Configure confirm players screen with its view model
            confirmPlayersViewController.viewModel = viewModel.makeConfirmPlayersViewModel()
        }

    case SegueIdentifier.playerDetails.rawValue:
        if let playerDetailsViewController = segue.destination as? PlayerDetailViewController,
            let player = viewModel.selectedPlayerForDetails {
            // Configure player details screen with delegate and view model
            playerDetailsViewController.delegate = self
            playerDetailsViewController.viewModel = PlayerDetailViewModel(player: player)
        }
    case SegueIdentifier.addPlayer.rawValue:
        // Configure add player screen with delegate
        (segue.destination as? PlayerAddViewController)?.delegate = self
    default:
        break
    }
}

PlayerListViewModel is rather big and contains a lot of properties and methods that are exposed to the View, all of them mandatory.
For the sake of the demo, we will leave it like it is and let the desired refactoring as an exercise to the readers. You could:

• separate PlayerListViewController in multiple ViewControllers / ViewModels, all handled by a parent or container view controller.
• split PlayerListViewModel in different components: by edit / list functions, service component, player selection.

The ViewState (player selection and list modes) is implemented through Factory pattern:

/// ViewModel responsible for managing player list state and interactions
final class PlayerListViewModel {
    
    // MARK: - Properties
    
    /// Current view state (list or selection mode)
    private var viewState: ViewState
    
    /// Details for the current view state, created on-demand
    private var viewStateDetails: LoginViewStateDetails {
        return ViewStateDetailsFactory.makeViewStateDetails(from: viewState)
    }
}

// MARK: - ViewState Definition
extension PlayerListViewModel {
    /// Represents the possible view states for the player list
    enum ViewState {
        /// Default state showing the list of players
        case list
        /// State for selecting players for a gather
        case selection
        
        /// Toggles between list and selection states
        mutating func toggle() {
            self = self == .list ? .selection : .list
        }
    }
}

And the concrete classes for list and selection:

/// Protocol defining the interface for view state details
protocol LoginViewStateDetails {
    /// Title for the navigation bar button
    var barButtonItemTitle: String { get }

    /// Whether the action button should be enabled
    var actionButtonIsEnabled: Bool { get }

    /// Title for the action button
    var actionButtonTitle: String { get }

    /// Identifier for the segue to be performed
    var segueIdentifier: String { get }
}

// MARK: - View State Implementations
fileprivate extension PlayerListViewModel {
    
    /// Details for list view mode
    struct ListViewStateDetails: LoginViewStateDetails {
        var barButtonItemTitle: String {
            return "Select"
        }
        
        var actionButtonIsEnabled: Bool {
            return false
        }
        
        var segueIdentifier: String {
            // Bound to the add player action
            return SegueIdentifier.addPlayer.rawValue
        }
        
        var actionButtonTitle: String {
            return "Add player"
        }
    }
    /// Details for selection view mode
    struct SelectionViewStateDetails: LoginViewStateDetails {
        var barButtonItemTitle: String {
            return "Cancel"
        }
        
        var actionButtonIsEnabled: Bool {
            return true
        }
        
        var segueIdentifier: String {
            return SegueIdentifier.confirmPlayers.rawValue
        }
        
        var actionButtonTitle: String {
            return "Confirm players"
        }
    }
    /// Factory for creating view state details
    enum ViewStateDetailsFactory {
        /// Creates the appropriate view state details based on the current view state
        static func makeViewStateDetails(from viewState: ViewState) -> LoginViewStateDetails {
            switch viewState {
            case .list:
                return ListViewStateDetails()
                
            case .selection:
                return SelectionViewStateDetails()
            }
        }
    }
}

The service methods are easy to read:

/// Fetches players from the service and updates the local collection
func fetchPlayers(completion: @escaping (Error?) -> ()) {
    playersService.get { [weak self] (result: Result<[PlayerResponseModel], Error>) in
        switch result {
        case .failure(let error):
            completion(error)
            
        case .success(let players):
            self?.players = players
            completion(nil)
        }
    }
}

/// Requests deletion of a player at the specified index path
func requestDeletePlayer(at indexPath: IndexPath, completion: @escaping (Error?) -> Void) {
    let player = players[indexPath.row]
    var service = playersService
    
    service.delete(withID: ResourceID.integer(player.id)) { result in
        switch result {
        case .failure(let error):
            completion(error)
            
        case .success(_):
            completion(nil)
        }
    }
}

PlayerAddViewController - defines the Add players screen.

Once a player was created, we use delegation pattern to notify Player Add screen and pop the view controller. The service call resides in the view model.

/// Handles the done button action for creating a new player
@objc private func doneAction(sender: UIBarButtonItem) {
    guard let playerName = playerNameTextField.text else { return }

    // Show loading indicator while creating player
    showLoadingView()
    viewModel.requestCreatePlayer(name: playerName) { [weak self] playerWasCreated in
        DispatchQueue.main.async {
            self?.hideLoadingView()
            if !playerWasCreated {
                self?.handleServiceFailure()
            } else {
                self?.handleServiceSuccess()
            }
        }
    }
}

/// Handles service failure by showing an error alert
private func handleServiceFailure() {
    AlertHelper.present(in: self, title: "Error update", message: "Unable to create player. Please try again.")
}

/// Handles service success by notifying delegate and dismissing view
private func handleServiceSuccess() {
    delegate?.playerWasAdded()
    navigationController?.popViewController(animated: true)
}

// MARK: - ViewModel
/// ViewModel responsible for managing player creation
struct PlayerAddViewModel {
    /// Service used for player creation requests
    private let service: StandardNetworkService
    
    /// Initializes the view model with a network service
    init(service: StandardNetworkService = StandardNetworkService(resourcePath: "/api/players", authenticated: true)) {
        self.service = service
    }
    
    /// The title displayed in the navigation bar
    var title: String {
        return "Add Player"
    }
    
    /// Requests the creation of a new player
    func requestCreatePlayer(name: String, completion: @escaping (Bool) -> Void) {
        let player = PlayerCreateModel(name: name)
        service.create(player) { result in
            if case .success(_) = result {
                completion(true)
            } else {
                completion(false)
            }
        }
    }
    
    /// Determines if the done button should be enabled based on text input
    func doneButtonIsEnabled(forText text: String?) -> Bool {
        return text?.isEmpty == false
    }
}

PlayerDetailViewController defines the Details screen

The view model is created and passed in the PlayerListViewController's method, prepareForSegue.
We use the same approach when navigating to PlayerEditViewController:

/// Prepares for navigation to the PlayerEditViewController
override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    guard segue.identifier == SegueIdentifier.editPlayer.rawValue,
          let destinationViewController = segue.destination as? PlayerEditViewController else {
        return
    }

    // Configure the edit player screen with its view model and delegate
    destinationViewController.viewModel = viewModel.makeEditViewModel()
    destinationViewController.delegate = self
}

Displaying the player’s details is done similar as we have in PlayerList screen: the View asks the ViewModel for the properties and sets the labels’ text.

// MARK: - UITableView DataSource & Delegate
extension PlayerDetailViewController: UITableViewDelegate, UITableViewDataSource {
    /// Returns the number of sections in the table view
    func numberOfSections(in tableView: UITableView) -> Int {
        return viewModel.numberOfSections
    }

    /// Returns the number of rows in the specified section
    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return viewModel.numberOfRowsInSection(section)
    }
    
    /// Configures and returns a cell for the specified index path
    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        guard let cell = tableView.dequeueReusableCell(withIdentifier: "PlayerDetailTableViewCell") as? PlayerDetailTableViewCell else {
            return UITableViewCell()
        }
        // Configure cell with view model data
        cell.leftLabel.text = viewModel.rowTitleDescription(for: indexPath)
        cell.rightLabel.text = viewModel.rowValueDescription(for: indexPath)
        return cell
    }

    /// Returns the header title for the specified section
    func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
        return viewModel.titleForHeaderInSection(section)
    }

    /// Handles row selection by navigating to edit screen
    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        viewModel.selectPlayerRow(at: indexPath)
        performSegue(withIdentifier: SegueIdentifier.editPlayer.rawValue, sender: nil)
    }
}

// MARK: - PlayerEditViewController Delegate
extension PlayerDetailViewController: PlayerEditViewControllerDelegate {
    /// Handles completion of player editing
    func didFinishEditing(player: PlayerResponseModel) {
        setupTitle()                    // Update title if player name changed
        viewModel.updatePlayer(player)  // Update local player model
        viewModel.reloadSections()      // Rebuild sections data
        reloadData()                    // Refresh table view
        delegate?.didEdit(player: player) // Notify parent of update
    }
}

PlayerDetailViewModel has the following properties:

/// ViewModel responsible for managing player details display
final class PlayerDetailViewModel {
    
    // MARK: - Properties
    
    /// The player model being displayed in the screen
    private(set) var player: PlayerResponseModel
    
    /// Sections containing organized player data, created lazily
    private lazy var sections = makeSections()
    
    /// Currently selected player row information
    private(set) var selectedPlayerRow: PlayerRow?
    
    // MARK: - Initialization
    
    /// Initializes the view model with a player model
    init(player: PlayerResponseModel) {
        self.player = player
    }
}

PlayerEditViewController

The segue to display the Edit screen is triggered from PlayerDetails screen. This is the place where you can edit the players details.
The ViewModel is passed from PlayerDetailsViewController.
Following the same approach, we moved all server API interaction, plus the model handling, in the ViewModel.

The edit text field is configured based on the ViewModel’s properties:

/// Configures the player edit text field with initial values and behavior
private func setupPlayerEditTextField() {
    // Set initial text values
    playerEditTextField.placeholder = viewModel.playerRowValue
    playerEditTextField.text = viewModel.playerRowValue
    
    // Configure editing behavior
    playerEditTextField.addTarget(
        self, 
        action: #selector(textFieldDidChange), 
        for: .editingChanged
    )
    
    // Hide field if in selection mode
    playerEditTextField.isHidden = viewModel.isSelectionViewType
}

When we are done with editing the player’s information, we ask the view model to perform the server updates and after it’s done, we handle the success or failure responses.
In case we have a failure, we inform the user, and in case the server call was successful, we notify the delegate and pop this view controller from the view controllers stack.

/// Handles the done button action for updating player information
@objc private func doneAction(sender: UIBarButtonItem) {
    guard viewModel.shouldUpdatePlayer(
          inputFieldValue: playerEditTextField.text
    ) else { return }

    // Show loading indicator while updating
    showLoadingView()
    // Attempt to update player with current field value
    viewModel.updatePlayerBasedOnViewType(inputFieldValue: playerEditTextField.text) { [weak self] updated in
        DispatchQueue.main.async {
            self?.hideLoadingView()
            if updated {
                self?.handleSuccessfulPlayerUpdate()
            } else {
                self?.handleServiceError()
            }
        }
    }
}

/// Handles successful player update by notifying delegate and dismissing view
private func handleSuccessfulPlayerUpdate() {
    delegate?.didFinishEditing(player: viewModel.editablePlayer)
    navigationController?.popViewController(animated: true)
}

/// Handles update failure by showing an error alert
private func handleServiceError() {
    AlertHelper.present(
        in: self,
        title: "Error update",
        message: "Unable to update player. Please try again."
    )
}

PlayerEditViewModel is similar with the rest, most important methods would be the player update ones:

/// Checks if the entered value in the field is different from the old value
func shouldUpdatePlayer(inputFieldValue: String?) -> Bool {
    if isSelectionViewType {
        return newValueIsDifferentFromOldValue(newFieldValue: selectedItemValue)
    }
    
    return newValueIsDifferentFromOldValue(newFieldValue: inputFieldValue)
}

private func newValueIsDifferentFromOldValue(newFieldValue: String?) -> Bool {
    guard let newFieldValue = newFieldValue else { return false }
    
    return playerEditModel.playerRow.value.lowercased() != newFieldValue.lowercased()
}

/// There are two different ways to update player information.
/// One is through the input / textField where you can type, for example the name or age of the player
/// and the other one is through selection where you can choose a different option (applied to player's position or skill).
private var selectedItemValue: String? {
    guard let playerItemsEditModel = playerItemsEditModel else { return nil }
    
    return playerItemsEditModel.items[playerItemsEditModel.selectedItemIndex]
}

/// Decides what needs to be updated (if inputFieldValue is nil, then it will update the player through selection mode).
func updatePlayerBasedOnViewType(inputFieldValue: String?, completion: @escaping (Bool) -> ()) {
    if isSelectionViewType {
        updatePlayer(newFieldValue: selectedItemValue, completion: completion)
    } else {
        updatePlayer(newFieldValue: inputFieldValue, completion: completion)
    }
}

private func updatePlayer(newFieldValue: String?, completion: @escaping (Bool) -> ()) {
    guard let newFieldValue = newFieldValue else {
        completion(false)
        return
    }
    
    playerEditModel.player.update(usingField: playerEditModel.playerRow.editableField, value: newFieldValue)
    requestUpdatePlayer(completion: completion)
}

/// Performs the player service update call
private func requestUpdatePlayer(completion: @escaping (Bool) -> ()) {
    let player = playerEditModel.player
    service.update(PlayerCreateModel(player), resourceID: ResourceID.integer(player.id)) { [weak self] result in
        if case .success(let updated) = result {
            self?.playerEditModel.player = player
            completion(updated)
        } else {
            completion(false)
        }
    }
}

ConfirmPlayersViewController

Before reaching Gather screen, we have to confirm the selected players. This screen is defined by ConfirmPlayersViewController.
In viewDidLoad we setup the UI elements, such as the table view and configure the start gather button:

/// Configures initial view states and appearance
func setupViews() {
    // Configure table view editing state
    playerTableView.isEditing = viewModel.playerTableViewIsEditing
    
    // Setup gather button configuration
    configureStartGatherButton()
}

The server API call is presented below:

/// Handles the action to start a new gather
@IBAction private func startGather(_ sender: Any) {
    // Show loading indicator while creating gather
    showLoadingView()

    viewModel.startGather { [weak self] result in
        DispatchQueue.main.async {
            self?.hideLoadingView()
            if !result {
                self?.handleServiceFailure()
            } else {
                self?.performSegue(
                    withIdentifier: SegueIdentifier.gather.rawValue,
                    sender: nil
                )
            }
        }
    }
}

/// Handles gather creation failure by showing an error alert
private func handleServiceFailure() {
    AlertHelper.present(
        in: self,
        title: "Error",
        message: "Unable to create gather."
    )
}

And the TableView Delegate and DataSource:

// MARK: - UITableViewDelegate & UITableViewDataSource
extension ConfirmPlayersViewController: UITableViewDelegate, UITableViewDataSource {
    /// Returns the number of sections in the table view
    func numberOfSections(in tableView: UITableView) -> Int {
        return viewModel.numberOfSections
    }

    /// Returns the header title for the specified section
    func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
        return viewModel.titleForHeaderInSection(section)
    }

    /// Returns the number of rows in the specified section
    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return viewModel.numberOfRowsInSection(section)
    }

    /// Returns the editing style for a row
    func tableView(_ tableView: UITableView, editingStyleForRowAt indexPath: IndexPath) -> UITableViewCell.EditingStyle {
        return .none
    }

    /// Determines if a row should be indented while editing
    func tableView(_ tableView: UITableView, shouldIndentWhileEditingRowAt indexPath: IndexPath) -> Bool {
        return false
    }

    /// Configures and returns a cell for the specified index path
    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        guard let cell = tableView.dequeueReusableCell(withIdentifier: "PlayerChooseTableViewCellId") else {
            return UITableViewCell()
        }
        // Configure cell with view model data
        cell.textLabel?.text = viewModel.rowTitle(at: indexPath)
        cell.detailTextLabel?.text = viewModel.rowDescription(at: indexPath)
        return cell
    }

    /// Handles row movement within the table view
    func tableView(_ tableView: UITableView, moveRowAt sourceIndexPath: IndexPath, to destinationIndexPath: IndexPath) {
        viewModel.moveRowAt(sourceIndexPath: sourceIndexPath, to: destinationIndexPath)
        configureStartGatherButton()
    }
}

ConfirmPlayersViewModel contains the playersDictionary with the selected players and their teams, the services needed to add players to a gather and to start the gather, the gatherUUID which is defined after a gather is created on the server and a dispatchGroup to orchestrate the multiple server calls.

/// ViewModel responsible for managing player confirmation and gather creation
final class ConfirmPlayersViewModel {
    
    // MARK: - Properties
    
    /// Dictionary mapping teams to their selected players
    private var playersDictionary: [TeamSection: [PlayerResponseModel]]
    
    /// Service for adding players to a gather
    private var addPlayerService: AddPlayerToGatherService
    
    /// Service for gather-related network operations
    private let gatherService: StandardNetworkService
    
    /// Group for coordinating multiple player additions
    private let dispatchGroup = DispatchGroup()
    
    /// UUID of the created gather
    private var gatherUUID: UUID?
    
    // MARK: - Initialization
    
    /// Initializes the view model with players and services
    init(playersDictionary: [TeamSection: [PlayerResponseModel]] = [:],
         addPlayerService: AddPlayerToGatherService = AddPlayerToGatherService(),
         gatherService: StandardNetworkService = StandardNetworkService(
             resourcePath: "/api/gathers",
             authenticated: true
         )) {
        self.playersDictionary = playersDictionary
        self.addPlayerService = addPlayerService
        self.gatherService = gatherService
    }
}

The most complex thing from this class is the server API interaction when starting a gather:

/// Initiates the gather creation process and adds selected players
func startGather(completion: @escaping (Bool) -> ()) {
    createGather { [weak self] uuid in
        guard let gatherUUID = uuid else {
            completion(false)
            return
        }
        
        // Store UUID and add players to the created gather
        self?.gatherUUID = gatherUUID
        self?.addPlayersToGather(havingUUID: gatherUUID, completion: completion)
    }
}

/// Creates a new gather on the server
private func createGather(completion: @escaping (UUID?) -> Void) {
    gatherService.create(GatherCreateModel()) { result in
        if case let .success(ResourceID.uuid(gatherUUID)) = result {
            completion(gatherUUID)
        } else {
            completion(nil)
        }
    }
}

/// Adds all selected players to the gather using a dispatch group for coordination
private func addPlayersToGather(havingUUID gatherUUID: UUID, completion: @escaping (Bool) -> ()) {
    var serviceFailed = false
    
    playerTeamArray.forEach { playerTeam in
        dispatchGroup.enter()
        
        self.addPlayer(playerTeam.player, 
                      toGatherHavingUUID: gatherUUID, 
                      team: playerTeam.team) { [weak self] playerWasAdded in
            if !playerWasAdded {
                serviceFailed = true
            }
            
            self?.dispatchGroup.leave()
        }
    }
    
    // Wait for all player additions to complete
    dispatchGroup.notify(queue: DispatchQueue.main) {
        completion(serviceFailed)
    }
}

/// Converts the players dictionary into an array of player-team pairs
private var playerTeamArray: [PlayerTeamModel] {
    var players: [PlayerTeamModel] = []
    
    // Add Team A players
    players += self.playersDictionary
        .filter { $0.key == .teamA }
        .flatMap { $0.value }
        .map { PlayerTeamModel(team: .teamA, player: $0) }
    
    // Add Team B players
    players += self.playersDictionary
        .filter { $0.key == .teamB }
        .flatMap { $0.value }
        .map { PlayerTeamModel(team: .teamB, player: $0) }
    
    return players
}

/// Adds a single player to the gather with their team assignment
private func addPlayer(_ player: PlayerResponseModel,
                      toGatherHavingUUID gatherUUID: UUID,
                      team: TeamSection,
                      completion: @escaping (Bool) -> Void) {
    addPlayerService.addPlayer(
        havingServerId: player.id,
        toGatherWithId: gatherUUID,
        team: PlayerGatherTeam(team: team.headerTitle)
    ) { result in
        if case let .success(resultValue) = result {
            completion(resultValue)
        } else {
            completion(false)
        }
    }
}

GatherViewController

Finally, we have GatherViewController, belonging to the most important screen from FootballGather.
We manage to clean the properties and left the IBOutlets, plus the loading view and the view model:

/// View controller responsible for managing the gather screen and its interactions
final class GatherViewController: UIViewController, Loadable {
    // MARK: - IBOutlets
    
    /// Table view displaying player information
    @IBOutlet weak var playerTableView: UITableView!
    
    /// View displaying the current score
    @IBOutlet weak var scoreLabelView: ScoreLabelView!
    
    /// Stepper control for adjusting scores
    @IBOutlet weak var scoreStepper: ScoreStepper!
    
    /// Label displaying the current timer value
    @IBOutlet weak var timerLabel: UILabel!
    
    /// Container view for timer-related controls
    @IBOutlet weak var timerView: UIView!
    
    /// Picker view for selecting timer duration
    @IBOutlet weak var timePickerView: UIPickerView!
    
    /// Button for controlling timer actions
    @IBOutlet weak var actionTimerButton: UIButton!
    
    // MARK: - Properties
    
    /// Loading indicator view
    lazy var loadingView = LoadingView.initToView(self.view)
    
    /// View model managing gather business logic
    var viewModel: GatherViewModel!
}

In viewDidLoad, we setup and configure the views:

override func viewDidLoad() {
    super.viewDidLoad()

    setupViewModel()
    setupTitle()
    configureSelectedTime()
    hideTimerView()
    configureTimePickerView()
    configureActionTimerButton()
    setupScoreStepper()
    reloadData()
}

/// Sets the view controller's title from the view model
private func setupTitle() {
    title = viewModel.title
}

/// Configures the view model delegate
private func setupViewModel() {
    viewModel.delegate = self
}

/// Configures the timer label with formatted text
private func configureSelectedTime() {
    timerLabel?.text = viewModel.formattedCountdownTimerLabelText
}

/// Configures the action timer button with formatted text
private func configureActionTimerButton() {
    actionTimerButton.setTitle(viewModel.formattedActionTitleText, for: .normal)
}

/// Hides the timer view
private func hideTimerView() {
    timerView.isHidden = true
}

/// Shows the timer view
private func showTimerView() {
    timerView.isHidden = false
}

/// Sets up the score stepper delegate
private func setupScoreStepper() {
    scoreStepper.delegate = self
}

/// Reloads data for the time picker and player table views
private func reloadData() {
    timePickerView.reloadAllComponents()
    playerTableView.reloadData()
}

The timer related functions are looking neat:

// MARK: - Timer Actions

/// Shows the timer picker view
@IBAction private func setTimer(_ sender: Any) {
    configureTimePickerView()
    showTimerView()
}

/// Cancels and resets the current timer
@IBAction private func cancelTimer(_ sender: Any) {
    viewModel.stopTimer()
    viewModel.resetTimer()
    configureSelectedTime()
    configureActionTimerButton()
    hideTimerView()
}

/// Toggles the timer between running and paused states
@IBAction private func actionTimer(_ sender: Any) {
    viewModel.toggleTimer()
    configureActionTimerButton()
}

/// Dismisses the timer picker view without saving
@IBAction private func timerCancel(_ sender: Any) {
    hideTimerView()
}

/// Saves the selected timer duration and starts the timer
@IBAction private func timerDone(_ sender: Any) {
    viewModel.stopTimer()
    viewModel.setTimerMinutes(selectedMinutesRow)
    viewModel.setTimerSeconds(selectedSecondsRow)
    configureSelectedTime()
    configureActionTimerButton()
    hideTimerView()
}

// MARK: - Timer Picker Helpers
/// Returns the currently selected minutes from the picker view
private var selectedMinutesRow: Int { 
    timePickerView.selectedRow(inComponent: viewModel.minutesComponent) 
}

/// Returns the currently selected seconds from the picker view
private var selectedSecondsRow: Int { 
    timePickerView.selectedRow(inComponent: viewModel.secondsComponent) 
}

And the endGather API interaction:

// MARK: - Gather Control Actions

/// Presents a confirmation alert before ending the gather
@IBAction private func endGather(_ sender: Any) {
    let alertController = UIAlertController(
        title: "End Gather",
        message: "Are you sure you want to end the gather?",
        preferredStyle: .alert
    )
    
    let confirmAction = UIAlertAction(title: "Yes", style: .default) { [weak self] _ in
        self?.endGather()
    }
    alertController.addAction(confirmAction)
    let cancelAction = UIAlertAction(title: "Cancel", style: .cancel, handler: nil)
    alertController.addAction(cancelAction)
    present(alertController, animated: true, completion: nil)
}

/// Ends the current gather and updates the final scores
private func endGather() {
    guard let scoreTeamAString = scoreLabelView.teamAScoreLabel.text,
          let scoreTeamBString = scoreLabelView.teamBScoreLabel.text else {
        return
    }
    showLoadingView()
    viewModel.endGather(
        teamAScoreLabelText: scoreTeamAString,
        teamBScoreLabelText: scoreTeamBString
    ) { [weak self] updated in
        DispatchQueue.main.async {
            self?.hideLoadingView()
            
            if !updated {
                self?.handleServiceFailure()
            } else {
                self?.handleServiceSuccess()
            }
        }
    }
}

/// Displays an error alert when the gather update fails
private func handleServiceFailure() {
    AlertHelper.present(
        in: self,
        title: "Error update",
        message: "Unable to update gather. Please try again."
    )
}

/// Handles successful gather completion by returning to the player list
private func handleServiceSuccess() {
    guard let playerListTogglable = navigationController?.viewControllers
        .first(where: { $0 is PlayerListTogglable }) as? PlayerListTogglable else {
        return
    }

    playerListTogglable.toggleViewState()
    if let playerListViewController = playerListTogglable as? UIViewController {
        navigationController?.popToViewController(
            playerListViewController,
            animated: true
        )
    }
}

The table view’s DataSource and Delegate are looking great as well, clean and simple:

// MARK: - UITableViewDelegate | UITableViewDataSource
extension GatherViewController: UITableViewDelegate, UITableViewDataSource {
    func numberOfSections(in tableView: UITableView) -> Int {
        viewModel.numberOfSections
    }

    func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
        viewModel.titleForHeaderInSection(section)
    }

    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        viewModel.numberOfRowsInSection(section)
    }

    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        guard let cell = tableView.dequeueReusableCell(withIdentifier: "GatherCellId") else {
            return UITableViewCell()
        }
        let rowDescription = viewModel.rowDescription(at: indexPath)
        cell.textLabel?.text = rowDescription.title
        cell.detailTextLabel?.text = rowDescription.details
        return cell
    }
}

And the rest of the methods:

// MARK: - ScoreStepperDelegate
extension GatherViewController: ScoreStepperDelegate {
    func stepper(_ stepper: UIStepper, didChangeValueForTeam team: TeamSection, newValue: Double) {
        if viewModel.shouldUpdateTeamALabel(section: team) {
            scoreLabelView.teamAScoreLabel.text = viewModel.formatStepperValue(newValue)
        } else if viewModel.shouldUpdateTeamBLabel(section: team) {
            scoreLabelView.teamBScoreLabel.text = viewModel.formatStepperValue(newValue)
        }
    }
}

// MARK: - UIPickerViewDataSource
extension GatherViewController: UIPickerViewDataSource, UIPickerViewDelegate {
    func numberOfComponents(in pickerView: UIPickerView) -> Int {
        viewModel.numberOfPickerComponents
    }

    func pickerView(_ pickerView: UIPickerView, numberOfRowsInComponent component: Int) -> Int {
        viewModel.numberOfRowsInPickerComponent(component)
    }

    func pickerView(_ pickerView: UIPickerView, titleForRow row: Int, forComponent component: Int) -> String? {
        viewModel.titleForPickerRow(row, forComponent: component)
    }
}

// MARK: - GatherViewModelDelegate
extension GatherViewController: GatherViewModelDelegate {
    func didUpdateGatherTime() {
        configureSelectedTime()
    }
}

Cleaning the ViewController came with some downsides in the ViewModel class. It has a lot of methods and the class is big (around 200 lines of code).

We decided to move out the Timer interaction into a new struct, called GatherTimeHandler.
In this struct, we expose selectedTime which is set from outside of the class, and has two more variables: the timer and a state variable (can be stopped, running or paused).
The public API has methods such as stop, reset and toggle timer, as well as decrementTime:

mutating func decrementTime() {
    if selectedTime.seconds == 0 {
        decrementMinutes()
    } else {
        decrementSeconds()
    }

    if selectedTimeIsZero {
        stopTimer()
    }
}
private mutating func decrementMinutes() {
    selectedTime.minutes -= 1
    selectedTime.seconds = 59
}

private mutating func decrementSeconds() {
    selectedTime.seconds -= 1
}

private var selectedTimeIsZero: Bool {
    return selectedTime.seconds == 0 && selectedTime.minutes == 0
}

Overall, this is looking much better from the first iteration where we implemented the app via MVC.

Testing our business logic

The most important part is the ViewModel. Here, we have implemented the business logic.

Testing the title:

func testTitle_whenViewModelIsAllocated_isNotEmpty() {
    // given
    let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
    let sut = GatherViewModel(gatherModel: mockGatherModel)
    
    // when
    let title = sut.title
    
    // then
    XCTAssertFalse(title.isEmpty)
}

Testing the formatted countdown timer label text:

func testFormattedCountdownTimerLabelText_whenViewModelIsAllocated_returnsDefaultTime() {
      // given
      let gatherTime = GatherTime.defaultTime
      // Define the expected values, format should be 00:00.
      let expectedFormattedMinutes = gatherTime.minutes < 10 ? "0\(gatherTime.minutes)" : "\(gatherTime.minutes)"
      let expectedFormattedSeconds = gatherTime.seconds < 10 ? "0\(gatherTime.seconds)" : "\(gatherTime.seconds)"
      let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
      let sut = GatherViewModel(gatherModel: mockGatherModel)
      
      // when
      let formattedCountdownTimerLabelText = sut.formattedCountdownTimerLabelText
      
      // then
      XCTAssertEqual(formattedCountdownTimerLabelText, "\(expectedFormattedMinutes):\(expectedFormattedSeconds)")
  }
  
  func testFormattedCountdownTimerLabelText_whenTimeIsZero_returnsZeroSecondsZeroMinutes() {
      // given
      let mockGatherTime = GatherTime(minutes: 0, seconds: 0)
      let mockGatherTimeHandler = GatherTimeHandler(selectedTime: mockGatherTime)
      let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
      let sut = GatherViewModel(gatherModel: mockGatherModel, timeHandler: mockGatherTimeHandler)
      
      // when
      let formattedCountdownTimerLabelText = sut.formattedCountdownTimerLabelText
      
      // then
      XCTAssertEqual(formattedCountdownTimerLabelText, "00:00")
  }
  
  func testFormattedCountdownTimerLabelText_whenTimeHasMinutesAndZeroSeconds_returnsMinutesAndZeroSeconds() {
      // given
      let mockGatherTime = GatherTime(minutes: 10, seconds: 0)
      let mockGatherTimeHandler = GatherTimeHandler(selectedTime: mockGatherTime)
      let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
      let sut = GatherViewModel(gatherModel: mockGatherModel, timeHandler: mockGatherTimeHandler)
      
      // when
      let formattedCountdownTimerLabelText = sut.formattedCountdownTimerLabelText
      
      // then
      XCTAssertEqual(formattedCountdownTimerLabelText, "10:00")
  }
  
  func testFormattedCountdownTimerLabelText_whenTimeHasSecondsAndZeroMinutes_returnsSecondsAndZeroMinutes() {
      // given
      let mockGatherTime = GatherTime(minutes: 0, seconds: 10)
      let mockGatherTimeHandler = GatherTimeHandler(selectedTime: mockGatherTime)
      let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
      let sut = GatherViewModel(gatherModel: mockGatherModel, timeHandler: mockGatherTimeHandler)
      
      // when
      let formattedCountdownTimerLabelText = sut.formattedCountdownTimerLabelText
      
      // then
      XCTAssertEqual(formattedCountdownTimerLabelText, "00:10")
  }

Testing the action title text, that should be Start, Resume or Pause.

// We set the state to be initially .paused
func testFormattedActionTitleText_whenStateIsPaused_returnsResume() {
    // given
    let mockGatherTimeHandler = GatherTimeHandler(state: .paused)
    let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
    let sut = GatherViewModel(gatherModel: mockGatherModel, timeHandler: mockGatherTimeHandler)

    // when
    let formattedActionTitleText = sut.formattedActionTitleText
    
    // then
    XCTAssertEqual(formattedActionTitleText, "Resume")
}

We follow the same approach for Pause and Start:

func testFormattedActionTitleText_whenStateIsRunning_returnsPause() {
      // given
      let mockGatherTimeHandler = GatherTimeHandler(state: .running)
      let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
      let sut = GatherViewModel(gatherModel: mockGatherModel, timeHandler: mockGatherTimeHandler)
      
      // when
      let formattedActionTitleText = sut.formattedActionTitleText
      
      // then
      XCTAssertEqual(formattedActionTitleText, "Pause")
}
      
func testFormattedActionTitleText_whenStateIsStopped_returnsStart() {
      // given
      let mockGatherTimeHandler = GatherTimeHandler(state: .stopped)
      let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
      let sut = GatherViewModel(gatherModel: mockGatherModel, timeHandler: mockGatherTimeHandler)
      
      // when
      let formattedActionTitleText = sut.formattedActionTitleText
      
      // then
      XCTAssertEqual(formattedActionTitleText, "Start")
}

For testing the stopTimer function, we mock the system to be in a running state

func testStopTimer_whenStateIsRunning_updatesStateToStopped() {
      // given
      let mockGatherTimeHandler = GatherTimeHandler(state: .running)
      let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
      let sut = GatherViewModel(gatherModel: mockGatherModel, timeHandler: mockGatherTimeHandler)
      
      // when
      sut.stopTimer()
      
      // then
      let formattedActionTitleText = sut.formattedActionTitleText
      XCTAssertEqual(formattedActionTitleText, "Start")
}

The delegates of the pickerView and tableView are very easy to test. We exemplify some unit tests below:

func testNumberOfRowsInSection_whenViewModelHasPlayers_returnsCorrectNumberOfPlayers() {
        // given
        let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 5)
        let teamAPlayersCount = mockGatherModel.players.filter { $0.team == .teamA}.count
        let teamBPlayersCount = mockGatherModel.players.filter { $0.team == .teamB}.count
        let sut = GatherViewModel(gatherModel: mockGatherModel)
        
        // when
        let numberOfRowsInSection0 = sut.numberOfRowsInSection(0)
        let numberOfRowsInSection1 = sut.numberOfRowsInSection(1)
        
        // then
        XCTAssertEqual(numberOfRowsInSection0, teamAPlayersCount)
        XCTAssertEqual(numberOfRowsInSection1, teamBPlayersCount)
}

func testNumberOfRowsInPickerComponent_whenComponentIsMinutes_returns60() {
        // given
        let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
        let sut = GatherViewModel(gatherModel: mockGatherModel)
        
        // when
        let numberOfRowsInPickerComponent = sut.numberOfRowsInPickerComponent(GatherTimeHandler.Component.minutes.rawValue)
        
        // then
        XCTAssertEqual(numberOfRowsInPickerComponent, 60)
}

For ending a gather we use the mocked endpoint and models. We verify if the received response is true:

func testEndGather_whenScoreIsSet_updatesGather() {
      // given
      let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
      let mockEndpoint = EndpointMockFactory.makeSuccessfulEndpoint(path: resourcePath)
      let mockService = StandardNetworkService(session: session, urlRequest: AuthURLRequestFactory(endpoint: mockEndpoint, keychain: appKeychain))
      let sut = GatherViewModel(gatherModel: mockGatherModel, updateGatherService: mockService)
      let exp = expectation(description: "Update gather expectation")
      
      // when
      sut.endGather(teamAScoreLabelText: "1", teamBScoreLabelText: "1") { gatherUpdated in
          XCTAssertTrue(gatherUpdated)
          exp.fulfill()
      }
      
      // then
      waitForExpectations(timeout: 5, handler: nil)
  }

To check if the timer is toggled, we use a MockViewModelDelegate:

private extension GatherViewModelTests {
  final class MockViewModelDelegate: GatherViewModelDelegate {
      // [1] Used to check if the delegate was called (didUpdateGatherTime())
      private(set) var gatherTimeWasUpdated = false

      // [2] Is fulfilled when the numberOfUpdateCalls is equal to actualUpdateCalls.
      // This means that the selector for the timer was called as many times as we wanted.
      weak var expectation: XCTestExpectation? = nil
      var numberOfUpdateCalls = 1
      private(set) var actualUpdateCalls = 0
      
      func didUpdateGatherTime() {
          gatherTimeWasUpdated = true
          actualUpdateCalls += 1 // [3] Increment the number of calls to this method
          
          if expectation != nil && numberOfUpdateCalls == actualUpdateCalls {
              expectation?.fulfill()
          }
      }
  }
}

And the unit test:

func testToggleTimer_whenSelectedTimeIsValid_updatesTime() {
      // given
      let numberOfUpdateCalls = 2
      let mockGatherTime = GatherTime(minutes: 0, seconds: numberOfUpdateCalls)
      let mockGatherTimeHandler = GatherTimeHandler(selectedTime: mockGatherTime)
      let mockGatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 2)
      
      let exp = expectation(description: "Waiting timer expectation")
      let mockDelegate = MockViewModelDelegate()
      mockDelegate.numberOfUpdateCalls = numberOfUpdateCalls
      mockDelegate.expectation = exp

      let sut = GatherViewModel(gatherModel: mockGatherModel, timeHandler: mockGatherTimeHandler)
      
      // when
      sut.delegate = mockDelegate
      sut.toggleTimer()
      
      // then
      waitForExpectations(timeout: 5) { _ in
          XCTAssertTrue(mockDelegate.gatherTimeWasUpdated)
          XCTAssertEqual(mockDelegate.actualUpdateCalls, numberOfUpdateCalls)
          sut.stopTimer()
      }
  }

Compared with testing the ViewController in the MVC architecture, life becomes easier when testing the ViewModel layer. The unit tests are easy to write, easier to understand and much simpler.

Key Metrics

Lines of code — View Controllers

Lines of code — View Models

Unit tests

Build times

Tests were run in iPhone 8 Simulator, with iOS 14.3, using Xcode 12.4 and on an i9 MacBook Pro 2019.

Conclusion

In this article, we’ve documented our journey of transforming our application from MVC to MVVM architecture. By introducing a dedicated layer for business logic, we’ve successfully decoupled core functionality from the View Controller, resulting in a cleaner separation of responsibilities.

The MVVM pattern proved highly effective in reducing View Controller complexity, producing more maintainable code. A particularly notable improvement was the enhanced testability of our business logic, with unit tests becoming significantly more straightforward to implement.

However, it’s important to acknowledge that implementing MVVM with UIKit presents certain challenges, as the framework wasn't originally designed with this architectural pattern in mind.

Key Metrics and Observations

Code Distribution

• Achieved a substantial reduction of 607 lines in View Controller code
• Introduced 1113 lines of View Model code
• Net increase of 506 lines and 7 new files to the codebase

Testing Improvements

• Achieved higher code coverage for the Gathers feature, increasing by 1.6% to reach 97.3%
• Significantly simplified unit test implementation for business logic
• Minor trade-off in test execution time, with an increase of 5.1 seconds

Benefits and Trade-offs

The adoption of MVVM has delivered several key advantages:

• Enhanced code organization and maintainability
• Improved separation of concerns
• Better testability of business logic
• Reduced risk of errors through cleaner architecture

While the implementation required additional code and slightly longer test execution times, the benefits in terms of maintainability, testability, and code organization make MVVM a valuable architectural choice for iOS applications, particularly as they grow in complexity.

This exercise in architectural transformation has resulted in a more robust, maintainable, and testable application. For teams considering MVVM, our experience suggests that the initial investment in additional code and setup time can pay significant dividends in long-term maintainability and reliability.

Thank you for following along with our architectural journey! Please explore the resources below for additional information and practical examples.

Useful Links

• The iOS App, Football Gather — GitHub Repo Link
• The web server application made in Vapor — GitHub Repo Link
• Vapor 3 Backend APIs article link
• Migrating to Vapor 4 article link
• Model View Controller (MVC) — GitHub Repo Link and article link
• Model View ViewModel (MVVM) — GitHub Repo Link and article link
• Model View Presenter (MVP) — GitHub Repo link and article link
• Coordinator Pattern — MVP with Coordinators (MVP-C) — GitHub Repo link and article link
• View Interactor Presenter Entity Router (VIPER) — GitHub Repo link and article link
• View Interactor Presenter (VIP) — GitHub Repo link and article link
• Book about MVVM on raywenderlich.
• Article about MVVM in iOS
• Article “How to not get desperate with MVVM implementation”
• Introduction to Model/View/ViewModel pattern for building WPF apps
• MVVM vs MVC
• Using MVV in iOS
• Practical MVVM + RxSwift
• MVVM with RxSwift
• How to integrate RxSwift in your MVVM architecture
• What Are the Benefits of Model-View-ViewModel
• MVVM Pattern Advantages — Benefits of Using MVVM Model
• Advantages and disadvantages of M-V-VM
• MVVM-1: A General Discussion

Battle of the iOS Architecture Patterns: A Look at Model-View-ViewModel (MVVM) was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Motivation

Before diving into iOS app development, it’s crucial to carefully consider the project’s architecture. We need to thoughtfully plan how different pieces of code will fit together, ensuring they remain comprehensible not just today, but months or years later when we need to revisit and modify the codebase. Moreover, a well-structured project helps establish a shared technical vocabulary among team members, making collaboration more efficient.

This article kicks off an exciting series where we’ll explore different architectural approaches by building the same application using various patterns. Throughout the series, we’ll analyze practical aspects like build times and implementation complexity, weigh the pros and cons of each pattern, and most importantly, examine real, production-ready code implementations. This hands-on approach will help you make informed decisions about which architecture best suits your project needs.

Architecture Series Articles

• Model View Controller (MVC) — Current Article
• Model View ViewModel (MVVM)
• Model View Presenter (MVP)
• Model View Presenter with Coordinators (MVP-C)
• View Interactor Presenter Entity Router (VIPER)
• View Interactor Presenter (VIP)

If you’re eager to explore the implementation details directly, you can find the complete source code in our open-source repository here.

Why Your iOS App Needs a Solid Architecture Pattern

The cornerstone of any successful iOS application is maintainability. A well-architected app clearly defines boundaries — you know exactly where view logic belongs, what responsibilities each view controller has, and which components handle business logic. This clarity isn’t just for you; it’s essential for your entire development team to understand and maintain these boundaries consistently.

Here are the key benefits of implementing a robust architecture pattern:

• Maintainability: Makes code easier to update and modify over time
• Testability: Facilitates comprehensive testing of business logic through clear separation of concerns
• Team Collaboration: Creates a shared technical vocabulary and understanding among team members
• Clean Separation: Ensures each component has clear, single responsibilities
• Bug Reduction: Minimizes errors through better organization and clearer interfaces between components

Project Requirements Overview

Given a medium-sized iOS application consisting of 6–7 screens, we’ll demonstrate how to implement it using the most popular architectural patterns in the iOS ecosystem: MVC (Model-View-Controller), MVVM (Model-View-ViewModel), MVP (Model-View-Presenter), VIPER (View-Interactor-Presenter-Entity-Router), VIP (Clean Swift), and the Coordinator pattern. Each implementation will showcase the pattern’s strengths and potential challenges.

Our demo application, Football Gather, is designed to help friends organize and track their casual football matches. It’s complex enough to demonstrate real-world architectural challenges while remaining simple enough to clearly illustrate different patterns.

Core Features and Functionality

• Player Management: Add and maintain a roster of players in the application
• Team Assignment: Flexibly organize players into different teams for each match
• Player Customization: Edit player details and preferences
• Match Management: Set and control countdown timers for match duration

Screen Mockups

Backend

The application is supported by a web backend developed using the Vapor framework, a popular choice for building modern REST APIs in Swift. You can explore the details of this implementation in our article here, which covers the fundamentals of building REST APIs with Vapor and Fluent in Swift. Additionally, we have documented the transition from Vapor 3 to Vapor 4, highlighting the enhancements and new features in our article here.

What is MVC

Model-View-Controller (MVC) is arguably the most widely recognized architectural pattern in software development.

At its core, MVC consists of three distinct components: Model, View, and Controller. Let’s explore each one in detail.

Model

• Encompasses all data classes, helper utilities, and networking code
• Contains application-specific data and the business logic that processes it
• In our application, the Model layer includes everything within the Utils, Storage, and Networking groups
• Supports various relationships between model objects (e.g., many-to-many between players and gathers, one-to-many between users and players/gathers)
• Maintains independence from the View layer and should not be concerned with user interface details

Communication Flow

• User actions in the View layer are communicated to the Model through the Controller
• When the Model’s data changes, it notifies the Controller, which then updates the View accordingly

View

• Represents the visual elements that users interact with on screen
• Handles user input and interaction events
• Displays Model data and facilitates user interactions
• Built using Apple’s core frameworks: UIKit and AppKit
• In our application: LoadingView, EmptyView, PlayerTableViewCell, and ScoreStepper are examples of View components

Communication Flow

• Views never communicate directly with the Model — all interaction is mediated through the Controller

Controller

• Acts as the central coordinator of the MVC architecture
• Manages View updates and Model mutations
• Processes Model changes and ensures View synchronization
• Handles object lifecycle management and setup tasks

Communication Flow

• Maintains bidirectional communication with both Model and View layers
• Interprets user actions and orchestrates corresponding Model updates
• Ensures UI consistency by propagating Model changes to the View

Evolution of MVC

The traditional MVC pattern differs from Apple’s Cocoa MVC implementation. In the original pattern, View and Model layers could communicate directly, while the View remained stateless and was rendered by the Controller after Model updates.
First introduced in Smalltalk-79, MVC was built upon three fundamental design patterns: composite, strategy, and observer.

Composite Pattern

The view hierarchy in an application consists of nested view objects working together cohesively. These visual components span from windows to complex views like table views, down to basic UI elements such as buttons. User interactions can occur at any level within this composite structure.

Consider the UIView hierarchy in iOS development. Views serve as the fundamental building blocks of the user interface, capable of containing multiple subviews.
For instance, our LoginViewController's main view contains a hierarchy of stack views, which in turn contain text fields for credentials and a login button.

Strategy Pattern

Controllers implement specific strategies for view objects. While views focus solely on their visual presentation, controllers handle all application-specific logic and interface behavior decisions.

Observer Pattern

Model objects maintain and notify interested components — typically views — about changes in their state.

A significant drawback of traditional MVC is the tight coupling between all three layers, which can make testing, maintenance, and code reuse challenging.

Applying to our code

In FootballGather we implement each screen as a View Controller:

LoginViewController

Description

• landing page where users can login with their credentials or create new users

UI elements

• usernameTextField — this is the text field where users enter their username
• passwordTextField — secure text field for entering passwords
• rememberMeSwitch — is an UISwitch for saving the username in Keychain after login and autopopulate the field next time we enter the app
• loadingView — is used to show an indicator while a server call is made

Services

• loginService — used to call the Login API with the entered credentials
• usersService — used to call the Register API, creating a new user

As we can see, this class has three major functions: login, register and remember my username. Jumping to next screen is done via performSegue.

Code snippet

@IBAction private func login(_ sender: Any) {
    // Validate required fields
    // Both username and password must be non-empty strings
    guard let userText = usernameTextField.text, userText.isEmpty == false,
        let passwordText = passwordTextField.text, passwordText.isEmpty == false else {
            AlertHelper.present(in: self, title: "Error", message: "Both fields are mandatory.")
            return
    }

    // Display loading indicator while authentication is in progress
        showLoadingView()
        // Prepare login credentials model for API request
        let requestModel = UserRequestModel(username: userText, password: passwordText)
        // Attempt to authenticate user with provided credentials
        // Response is handled asynchronously
        loginService.login(user: requestModel) { [weak self] result in
            guard let self = self else { return }
            DispatchQueue.main.async {
                // Hide loading indicator once response is received
                self.hideLoadingView()
                switch result {
                case .failure(let error):
                    // Authentication failed - Display error message to user
                    AlertHelper.present(in: self, title: "Error", message: String(describing: error))
                case .success(_):
                    // Authentication successful:
                    // 1. Save "Remember Me" preference if enabled
                    // 2. Clear stored credentials if disabled
                    // 3. Navigate to main screen
                    self.handleSuccessResponse()
                }
            }
        }
  }

PlayerListViewController

Description

• shows the players for the logged in user. Consists of a main table view, each player is displayed in a separated row.

UI elements

• playerTableView — The table view that displays players
• confirmOrAddPlayersButton — Action button from the bottom of the view, that can either correspond to an add player action or confirms the selected players
• loadingView — is used to show an indicator while a server call is made
• emptyView — Shown when the user hasn’t added any players
• barButtonItem — The top right button that can have different states based on the view mode we are in. Has the title “Cancel” when we go into selection mode to choose the players we want for the gather or “Select” when we are in view mode.

Services

• playersService — Used to retrieve the list of players and to delete a player

Models

• players — An array of players created by the user. This are the rows we see in playerTableView
• selectedPlayersDictionary — A cache dictionary that stores the row index of the selected player as key and the selected player as value.

If you open up Main.storyboard you can see that from this view controller you can perform three segues

• ConfirmPlayersSegueIdentifier — After you select what players you want for your gather, you go to a confirmation screen where you assign the teams they will be part of.
• PlayerAddSegueIdentifier — Goes to a screen where you can create a new player
• PlayerDetailSegueIdentifier — Opens a screen where you can see the details of the player

We have the following function to retrieve the model for this View Controller.

private func loadPlayers() {
    // Disable user interaction during data fetch
    // Prevents multiple requests and shows loading state
    view.isUserInteractionEnabled = false

    // Fetch players from remote service
    // Returns array of PlayerResponseModel or error
    playersService.get { [weak self] (result: Result<[PlayerResponseModel], Error>) in
        DispatchQueue.main.async {
            // Re-enable user interaction after response
            self?.view.isUserInteractionEnabled = true
            switch result {
            case .failure(let error):
                // Handle service error:
                // Display error message and retry options to user
                self?.handleServiceFailures(withError: error)
            case .success(let players):
                // Update data model and refresh UI:
                // 1. Store retrieved players
                // 2. Update table view
                // 3. Handle empty states
                self?.players = players
                self?.handleLoadPlayersSuccessfulResponse()
            }
        }
    }
}

And if we want to delete one player we do the following:

func tableView(
    _ tableView: UITableView,
    commit editingStyle: UITableViewCell.EditingStyle,
    forRowAt indexPath: IndexPath
) {
    // Only handle deletion actions, ignore other editing styles
    guard editingStyle == .delete else { return }

    // Show a confirmation dialog before deleting the player
    let alertController = UIAlertController(
        title: "Delete player",
        message: "Are you sure you want to delete the selected player?",
        preferredStyle: .alert
    )
    
    // Configure delete action with destructive style
    let confirmAction = UIAlertAction(
        title: "Delete",
        style: .destructive
    ) { [weak self] _ in
        self?.handleDeletePlayerConfirmation(forRowAt: indexPath)
    }
    alertController.addAction(confirmAction)
    // Configure cancel action to dismiss dialog
    let cancelAction = UIAlertAction(
        title: "Cancel",
        style: .cancel,
        handler: nil
    )
    alertController.addAction(cancelAction)
    // Present the confirmation dialog
    present(alertController, animated: true, completion: nil)
}

The service call is presented below:

private func requestDeletePlayer(
    at indexPath: IndexPath,
    completion: @escaping (Bool) -> Void
) {
    // Retrieve player to be deleted from data model
    let player = players[indexPath.row]
    var service = playersService

    // Perform delete request using player's ID
    service.delete(withID: ResourceID.integer(player.id)) { [weak self] result in
        DispatchQueue.main.async {
            switch result {
            case .failure(let error):
                // Handle deletion failure
                // Notify user of error and pass false to completion handler
                self?.handleServiceFailures(withError: error)
                completion(false)
            case .success(_):
                // Deletion successful
                // Pass true to completion handler
                completion(true)
            }
        }
    }
}

PlayerAddViewController

Description

• This screen is used for creating a player.

UI Elements

• playerNameTextField — Used to enter the name of the player
• doneButton — Bar button item that is used to confirm the player to be created and initiates a service call
• loadingView — Is used to show an indicator while a server call is made

Services

• We use the StandardNetworkService that points to /api/players. To add players, we initiate a POST request.

Code snippet

private func createPlayer(
    _ player: PlayerCreateModel,
    completion: @escaping (Bool) -> Void
) {
    // Initialize network service for player creation
    let service = StandardNetworkService(
        resourcePath: "/api/players",
        authenticated: true
    )
    
    // Perform create request with player data
    service.create(player) { result in
        // Check result of the network request
        if case .success(_) = result {
            // Player creation successful
            completion(true)
        } else {
            // Player creation failed
            completion(false)
        }
    }
}

PlayerDetailViewController

Description

• maps a screen that shows the details of a player (name, age, position, skill and favourite team)

UI elements

• playerDetailTableView — A tableview that displays the details of the player.

Model

• player — The model of the player as PlayerResponseModel

We have no services in this ViewController. A request to update an information of player is received fromPlayerEditViewController and passed to PlayerListViewController through delegation.

The sections are made with a factory pattern:

private func makeSections() -> [PlayerSection] {
    // Create and return an array of PlayerSection objects
    return [
        PlayerSection(
            title: "Personal",
            rows: [
                // Add player name row
                PlayerRow(
                    title: "Name",
                    value: self.player?.name ?? "",
                    editableField: .name
                ),
                // Add player age row
                PlayerRow(
                    title: "Age",
                    value: self.player?.age != nil ? "\(self.player!.age!)" : "",
                    editableField: .age
                )
            ]
        ),
        PlayerSection(
            title: "Play",
            rows: [
                // Add preferred position row
                PlayerRow(
                    title: "Preferred position",
                    value: self.player?.preferredPosition?.rawValue.capitalized ?? "",
                    editableField: .position
                ),
                // Add skill row
                PlayerRow(
                    title: "Skill",
                    value: self.player?.skill?.rawValue.capitalized ?? "",
                    editableField: .skill
                )
            ]
        ),
        PlayerSection(
            title: "Likes",
            rows: [
                // Add favourite team row
                PlayerRow(
                    title: "Favourite team",
                    value: self.player?.favouriteTeam ?? "",
                    editableField: .favouriteTeam
                )
            ]
        )
    ]
}

PlayerEditViewController

Description

• Edits a player information.

UI Elements

• playerEditTextField — The field that is filled with the player’s detail we want to edit
• playerTableView — We wanted to have a similar behaviour and UI as we have in iOS General Settings for editing a details. This table view has either one row with a text field or multiple rows with a selection behaviour.
• loadingView — is used to show an indicator while a server call is made
• doneButton — An UIBarButtonItem that performs the action of editing.

Services

• Update Player API, used as a StandardNetworkService:

private func updatePlayer(
    _ player: PlayerResponseModel,
    completion: @escaping (Bool) -> Void
) {
    // Initialize network service for player update
    var service = StandardNetworkService(
        resourcePath: "/api/players",
        authenticated: true
    )
    
    // Perform update request with player data
    // Use player's ID for resource identification
    service.update(
        PlayerCreateModel(player),
        resourceID: ResourceID.integer(player.id)
    ) { result in
        // Check result of the network request
        if case .success(let updated) = result {
            // Player update successful
            completion(updated)
        } else {
            // Player update failed
            completion(false)
        }
    }
}

Models

• viewType — An enum that can be .text (for player details that are entered via keyboard) or .selection (for player details that are selected by tapping one of the cells, for example the preferred position).
• player — The player we want to edit.
• items — An array of strings corresponding to all possible options for preferred positions or skill. This array is nil when a text entry is going to be edited.

ConfirmPlayersViewController

Description

• Before reaching the Gather screen we want to put the players in the desired teams

UI elements

• playerTableView — A table view split in three sections (Bench, Team A and Team B) that shows the selected players we want for the gather.
• startGatherButton — Initially disabled, when tapped triggers an action to perform the Network API calls required to start the gather and at last, it pushes the next screen.
• loadingView — is used to show an indicator while a server call is made.

Services

• Create Gather — Adds a new gather by making a POST request to /api/gathers.
• Add Player to Gather — After we are done with selecting teams for our players, we add them to the gather by doing a POST request to api/gathers/{gather_id}/players/{player_id}.

Models

• playersDictionary — Each team has an array of players, so the dictionary has the teams as keys (Team A, Team B or Bench) and for values we have the selected players (array of players).

When we are done with the selection (UI), a new gather is created and each player is assigned a team.

@IBAction func startGatherAction(_ sender: Any) {
    // Show loading indicator while creating gather
    showLoadingView()
    
    // Create new gather with authenticated request
    // Returns UUID on success, nil on failure
    createGather { [weak self] uuid in
        guard let self = self else { return }
        
        guard let gatherUUID = uuid else {
            // Handle gather creation failure
            self.handleServiceFailure()
            return
        }
        
        // Add selected players to the newly created gather
        // Players will be assigned to their respective teams
        self.addPlayersToGather(havingUUID: gatherUUID)
    }
}

The for loop to add players is presented below:

private func addPlayersToGather(havingUUID gatherUUID: UUID) {
    // Get array of players with their team assignments
    let players = self.playerTeamArray
    
    // Create dispatch group to handle multiple concurrent requests
    // This ensures all player additions complete before updating UI
    let dispatchGroup = DispatchGroup()
    var serviceFailed = false
    
    // Add each player to the gather with their assigned team
    players.forEach { playerTeamModel in
        dispatchGroup.enter()
        
        self.addPlayer(
            playerTeamModel.player,
            toGatherHavingUUID: gatherUUID,
            team: playerTeamModel.team,
            completion: { playerWasAdded in
                // Track if any player addition fails
                if !playerWasAdded {
                    serviceFailed = true
                }
                
                dispatchGroup.leave()
            }
        )
    }
    
    // Handle completion after all player additions finish
    dispatchGroup.notify(queue: DispatchQueue.main) {
        self.hideLoadingView()
        
        if serviceFailed {
            // Handle case where one or more players failed to add
            self.handleServiceFailure()
        } else {
            // All players added successfully - navigate to gather screen
            self.performSegue(
                withIdentifier: SegueIdentifiers.gather.rawValue,
                sender: GatherModel(
                    players: players,
                    gatherUUID: gatherUUID
                )
            )
        }
    }
}

GatherViewController

Description

• This is the core screen of the application, where you are in the gather mode and start / pause or stop the timer and in the end, finish the match.

UI elements

• playerTableView — Used to display the players in gather, split in two sections: Team A and Team B.
• scoreLabelView — A view that has two labels for displaying the score, one for Team A and the other one for Team B.
• scoreStepper — A view that has two steppers for the teams.
• timerLabel — Used to display the remaining time in the format mm:ss.
• timerView — An overlay view that has a UIPickerView to choose the time of the gather.
• timePickerView — The picker view with two components (minutes and seconds) for selecting the gather’s time.
• actionTimerButton — Different state button that manages the countdown timer (resume, pause and start).
• loadingView — is used to show an indicator while a server call is made.

Services

• Update Gather — when a gather is ended, we do a PUT request to update the winner team and the score

Models

• GatherTime — A tuple that has minutes and seconds as Int.
• gatherModel — Contains the gather ID and an array of player team model (the player response model and the team he belongs to). This is created and passed from ConfirmPlayersViewController.
• timer — Used to countdown the minutes and seconds of the gather.
• timerState — Can have three states stopped, running and paused. We observer when one of the values is set so we can change the actionTimerButton's title accordingly. When it's paused the button's title will be Resume. When it's running the button's title will be Pause and Start when the timer is stopped.

When the actionTimerButton is tapped, we verify if we want to invalidate or start the timer:

@IBAction func actionTimer(_ sender: Any) {
    // Check if the user selected a time more than 1 second
    guard selectedTime.minutes > 0 || selectedTime.seconds > 0 else {
        return
    }
    
    switch timerState {
    case .stopped, .paused:
        // Timer was stopped or paused, start running
        timerState = .running
    case .running:
        // Timer is running, pause it
        timerState = .paused
    }
    
    if timerState == .paused {
        // Stop the timer
        timer.invalidate()
    } else {
        // Start the timer and call updateTimer every second
        timer = Timer.scheduledTimer(
            timeInterval: 1,
            target: self,
            selector: #selector(updateTimer),
            userInfo: nil,
            repeats: true
        )	    
    }
}

To cancel a timer we have the following action implemented:

@IBAction func cancelTimer(_ sender: Any) {
    // Set timer state to stopped and invalidate the timer
    timerState = .stopped
    timer.invalidate()
    
    // Reset selected time to default (10 minutes)
    selectedTime = Constants.defaultTime
    timerView.isHidden = true
}

The selector updateTimer is called each second:

@objc func updateTimer(_ timer: Timer) {
    // Check if seconds are zero to decrement minutes
    if selectedTime.seconds == 0 {
        selectedTime.minutes -= 1
        selectedTime.seconds = 59
    } else {
        selectedTime.seconds -= 1
    }
    
    // Stop timer if time reaches zero
    if selectedTime.seconds == 0 && selectedTime.minutes == 0 {
        timerState = .stopped
        timer.invalidate()
    }
}

Before ending a gather, check the winner team:

guard let scoreTeamAString = scoreLabelView.teamAScoreLabel.text,
      let scoreTeamBString = scoreLabelView.teamBScoreLabel.text,
      let scoreTeamA = Int(scoreTeamAString),
      let scoreTeamB = Int(scoreTeamBString) else {
    return
}

// Format the score as a string
let score = "\(scoreTeamA)-\(scoreTeamB)"
// Determine the winner team based on scores
var winnerTeam: String = "None"
if scoreTeamA > scoreTeamB {
    winnerTeam = "Team A"
} else if scoreTeamA < scoreTeamB {
    winnerTeam = "Team B"
}
// Create gather model with score and winner team
let gather = GatherCreateModel(score: score, winnerTeam: winnerTeam)

And the service call:

private func updateGather(
    _ gather: GatherCreateModel,
    completion: @escaping (Bool) -> Void
) {
    // Verify gather model exists before proceeding
    guard let gatherModel = gatherModel else {
        completion(false)
        return
    }
    
    // Initialize network service for gather update
    var service = StandardNetworkService(
        resourcePath: "/api/gathers",
        authenticated: true
    )
    
    // Perform update request with gather data
    // Use player's ID for resource identification
    service.update(
        gather,
        resourceID: ResourceID.uuid(gatherModel.gatherUUID)
    ) { result in
        // Check result of the network request
        if case .success(let updated) = result {
            // Update successful
            completion(updated)
        } else {
            // Update failed
            completion(false)
        }
    }
}

The private method updateGather is called from endGather:

let gather = GatherCreateModel(score: score, winnerTeam: winnerTeam)
  
showLoadingView()
updateGather(gather) { [weak self] gatherWasUpdated in
    guard let self = self else { return }
    
    DispatchQueue.main.async {
        self.hideLoadingView()
        
        if !gatherWasUpdated {
            // The server call failed, make sure we show an alert to the user
            AlertHelper.present(
                in: self,
                title: "Error update",
                message: "Unable to update gather. Please try again."
            )
        } else {
            guard let playerViewController = self.navigationController?.viewControllers
                .first(where: { $0 is PlayerListViewController }) as? PlayerListViewController else {
                return
            }
            
            // The PlayerListViewController is in a selection mode state
            // We make sure we turn it back to .list
            playerViewController.toggleViewState()
            
            // Pop to PlayerListViewController, skipping confirmation screen
            self.navigationController?.popToViewController(
                playerViewController,
                animated: true
            )
        }
    }
}

Testing our business logic

We saw a first iteration of applying MVC to the demo app FootbalGather. Of course, we can refactor the code and make it better and decouple some of the logic, split it into different classes, but for the sake of the exercise we are going to keep this version of the codebase.

Let’s see how we can write unit tests for our classes. We are going to exemplify for GatherViewController and try to reach close to 100% code coverage.

First, we see GatherViewController is part of Main storyboard. To make our lives easier, we use an identifier and instantiate it with the method storyboard.instantiateViewController. Let's use the setUp method for this logic:

final class GatherViewControllerTests: XCTestCase {
	  
    var sut: GatherViewController! // System Under Test (SUT)
    
    override func setUp() {
        super.setUp()
        
        // Load the storyboard named "Main"
        let storyboard = UIStoryboard(name: "Main", bundle: nil)
        
        // Instantiate GatherViewController from the storyboard
        if let viewController = storyboard.instantiateViewController(identifier: "GatherViewController") as? GatherViewController {
            sut = viewController // Assign to SUT
            sut.gatherModel = gatherModel // Set the gather model
            _ = sut.view // Load the view to trigger viewDidLoad
        } else {
            XCTFail("Unable to instantiate GatherViewController") // Fail the test if instantiation fails
        }
    }
//…
}

For our first test, we verify all outlets are not nil:

func testOutlets_whenViewControllerIsLoadedFromStoryboard_areNotNil() {
    // Verify all IBOutlets are properly connected from storyboard
    XCTAssertNotNil(sut.playerTableView)      // Table view showing players
    XCTAssertNotNil(sut.scoreLabelView)       // View displaying team scores
    XCTAssertNotNil(sut.scoreStepper)         // Stepper controls for adjusting scores
    XCTAssertNotNil(sut.timerLabel)           // Label showing countdown time
    XCTAssertNotNil(sut.timerView)            // Container view for timer controls
    XCTAssertNotNil(sut.timePickerView)       // Picker for setting match duration
    XCTAssertNotNil(sut.actionTimerButton)    // Button to start/pause/resume timer
}

Now let’s see if viewDidLoad is called. The title is set and some properties are configured. We verify the public parameters:

func testViewDidLoad_whenViewControllerIsLoadedFromStoryboard_setsVariables() {
    XCTAssertNotNil(sut.title)
    XCTAssertTrue(sut.timerView.isHidden)
    XCTAssertNotNil(sut.timePickerView.delegate)
}

The variable timerView is a pop-up custom view where users set their match timer.

Moving forward let’s unit test our table view methods:

func testViewDidLoad_whenViewControllerIsLoadedFromStoryboard_setsVariables() {
    // Verify initial view setup after loading
    XCTAssertNotNil(sut.title)                    // Check view controller title is set
    XCTAssertTrue(sut.timerView.isHidden)         // Timer view should be hidden initially
    XCTAssertNotNil(sut.timePickerView.delegate)  // Time picker should have delegate set
}

The variable timerView is a pop-up custom view where users set their match timer.

Moving forward let’s unit test our table view methods:

func testNumberOfSections_whenGatherModelIsSet_returnsTwoTeams() {
    // Verify table view has correct number of sections (Team A and Team B)
    XCTAssert(sut.playerTableView?.numberOfSections == Team.allCases.count - 1)
}

We have just two teams: Team A and Team B. The Bench team is not visible and not part of this screen.

func testTitleForHeaderInSection_whenSectionIsTeamAAndGatherModelIsSet_returnsTeamATitleHeader() {
    // Test header title for Team A section
    let teamASectionTitle = sut.tableView(sut.playerTableView, titleForHeaderInSection: 0)
    XCTAssertEqual(teamASectionTitle, Team.teamA.headerTitle)
}
    
func testTitleForHeaderInSection_whenSectionIsTeamBAndGatherModelIsSet_returnsTeamBTitleHeader() {
    // Test header title for Team B section
    let teamBSectionTitle = sut.tableView(sut.playerTableView, titleForHeaderInSection: 1)
    XCTAssertEqual(teamBSectionTitle, Team.teamB.headerTitle)
}

Our tableview should have two sections with both header titles being set to the team names (Team A and Team B).

For checking the number of rows, we inject a mocked gather model:

private let gatherModel = ModelsMockFactory.makeGatherModel(numberOfPlayers: 4)

static func makeGatherModel(numberOfPlayers: Int, gatherUUID: UUID = ModelsMock.gatherUUID) -> GatherModel {
    // Get all possible player skills and positions
    let allSkills = PlayerSkill.allCases
    let allPositions = PlayerPosition.allCases
    
    // Initialize empty array to store player-team assignments
    var playerTeams: [PlayerTeamModel] = []
    
    // Create specified number of players with random attributes
    // For each player
    ...
        // Randomly assign skill and position
        // Alternate between Team A and Team B
        // Create player model with incremental attributes
    ...
    
    return GatherModel(players: playerTeams, gatherUUID: gatherUUID)
}

Nil scenario when the section is invalid.

func testNumberOfRowsInSection_whenGatherModelIsNil_returnsZero() {
    // Test edge case when gather model is nil
    sut.gatherModel = nil
    XCTAssertEqual(sut.tableView(sut.playerTableView, numberOfRowsInSection: -1), 0)
}

func testCellForRowAtIndexPath_whenSectionIsTeamA_setsCellDetails() {
    // Set up test data for Team A
    let indexPath = IndexPath(row: 0, section: 0)
    let playerTeams = gatherModel.players.filter({ $0.team == .teamA })
    let player = playerTeams[indexPath.row].player
    
    // Get cell from table view
    let cell = sut.playerTableView.cellForRow(at: indexPath)
    
    // Verify cell content matches player data
    XCTAssertEqual(cell?.textLabel?.text, player.name)
    XCTAssertEqual(cell?.detailTextLabel?.text, player.preferredPosition?.acronym)
}
  
func testCellForRowAtIndexPath_whenSectionIsTeamB_setsCellDetails() {
    // Set up test data for Team B
    let indexPath = IndexPath(row: 0, section: 1)
    let playerTeams = gatherModel.players.filter({ $0.team == .teamB })
    let player = playerTeams[indexPath.row].player
    
    // Get cell from table view
    let cell = sut.playerTableView.cellForRow(at: indexPath)
    
    // Verify cell content matches player data
    XCTAssertEqual(cell?.textLabel?.text, player.name)
    XCTAssertEqual(cell?.detailTextLabel?.text, player.preferredPosition?.acronym)
}

func testPickerViewNumberOfComponents_returnsAllCountDownCases() {
    // Verify picker view has correct number of components
    XCTAssertEqual(sut.timePickerView.numberOfComponents, 
                    GatherViewController.GatherCountDownTimerComponent.allCases.count)
}

func testPickerViewNumberOfRowsInComponent_whenComponentIsMinutes_returns60() {
    // Test number of rows for minutes component
    let minutesComponent = GatherViewController.GatherCountDownTimerComponent.minutes.rawValue
    let numberOfRows = sut.pickerView(sut.timePickerView, numberOfRowsInComponent: minutesComponent)
    
    XCTAssertEqual(numberOfRows, 60)
}
  
func testPickerViewNumberOfRowsInComponent_whenComponentIsSecounds() {
    // Test number of rows for seconds component
    let secondsComponent = GatherViewController.GatherCountDownTimerComponent.seconds.rawValue
    let numberOfRows = sut.pickerView(sut.timePickerView, numberOfRowsInComponent: secondsComponent)
    
    XCTAssertEqual(numberOfRows, 60)
}

func testPickerViewTitleForRow_whenComponentIsMinutes_containsMin() {
    // Test title format for minutes component
    let minutesComponent = GatherViewController.GatherCountDownTimerComponent.minutes.rawValue
    let title = sut.pickerView(sut.timePickerView, titleForRow: 0, forComponent: minutesComponent)
    
    XCTAssertTrue(title!.contains("min"))
}
  
func testPickerViewTitleForRow_whenComponentIsSeconds_containsSec() {
    // Test title format for seconds component
    let secondsComponent = GatherViewController.GatherCountDownTimerComponent.seconds.rawValue
    let title = sut.pickerView(sut.timePickerView, titleForRow: 0, forComponent: secondsComponent)
    
    XCTAssertTrue(title!.contains("sec"))
}

func testSetTimer_whenActionIsSent_showsTimerView() {
    // Test timer view visibility when setting timer
    sut.setTimer(UIButton())
    XCTAssertFalse(sut.timerView.isHidden)
}

func testCancelTimer_whenActionIsSent_hidesTimerView() {
    // Test timer view visibility when canceling timer
    sut.cancelTimer(UIButton())
    XCTAssertTrue(sut.timerView.isHidden)
}

func testTimerCancel_whenActionIsSent_hidesTimerView() {
    // Test timer view visibility when canceling from overlay
    sut.timerCancel(UIButton())
    XCTAssertTrue(sut.timerView.isHidden)
}

func testTimerDone_whenActionIsSent_hidesTimerViewAndSetsMinutesAndSeconds() {
    // Test timer completion setup
    sut.timerDone(UIButton())
    
    // Get selected time components
    let minutes = sut.timePickerView.selectedRow(inComponent: 
        GatherViewController.GatherCountDownTimerComponent.minutes.rawValue)
    let seconds = sut.timePickerView.selectedRow(inComponent: 
        GatherViewController.GatherCountDownTimerComponent.seconds.rawValue)
    
    // Verify timer view state and time settings
    XCTAssertTrue(sut.timerView.isHidden)
    XCTAssertGreaterThan(minutes, 0)
    XCTAssertEqual(seconds, 0)
}

func testActionTimer_whenSelectedTimeIsZero_returns() {
    // Set up components
    let minutesComponent = GatherViewController.GatherCountDownTimerComponent.minutes.rawValue
    let secondsComponent = GatherViewController.GatherCountDownTimerComponent.seconds.rawValue
    
    // Set time to 00:00
    sut.timePickerView.selectRow(0, inComponent: minutesComponent, animated: false)
    sut.timePickerView.selectRow(0, inComponent: secondsComponent, animated: false)
    sut.timerDone(UIButton())
    sut.actionTimer(UIButton())
    
    // Verify time remains at 00:00
    XCTAssertEqual(sut.timePickerView.selectedRow(inComponent: minutesComponent), 0)
    XCTAssertEqual(sut.timePickerView.selectedRow(inComponent: secondsComponent), 0)
}

func testActionTimer_whenSelectedTimeIsSet_updatesTimer() {
    // Set up test components
    let minutesComponent = GatherViewController.GatherCountDownTimerComponent.minutes.rawValue
    let secondsComponent = GatherViewController.GatherCountDownTimerComponent.seconds.rawValue
    
    // Configure initial time (0:01)
    sut.timePickerView.selectRow(0, inComponent: minutesComponent, animated: false)
    sut.timePickerView.selectRow(1, inComponent: secondsComponent, animated: false)
    
    // Verify initial state
    sut.timerDone(UIButton())
    XCTAssertEqual(sut.actionTimerButton.title(for: .normal), "Start")
    
    // Start timer
    sut.actionTimer(UIButton())
    XCTAssertEqual(sut.actionTimerButton.title(for: .normal), "Pause")
    
    // Wait for timer completion
    let exp = expectation(description: "Timer expectation")
    DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
        XCTAssertEqual(self.sut.actionTimerButton.title(for: .normal), "Start")
        exp.fulfil()
    }
    
    waitForExpectations(timeout: 5, handler: nil)
}
func testActionTimer_whenTimerIsSetAndRunning_isPaused() {
    // Set up test components
    let sender = UIButton()
    let minutesComponent = GatherViewController.GatherCountDownTimerComponent.minutes.rawValue
    let secondsComponent = GatherViewController.GatherCountDownTimerComponent.seconds.rawValue
    
    // Configure initial time (0:03)
    sut.timePickerView.selectRow(0, inComponent: minutesComponent, animated: false)
    sut.timePickerView.selectRow(3, inComponent: secondsComponent, animated: false)
    
    // Start timer and verify initial state
    sut.timerDone(sender)
    XCTAssertEqual(sut.actionTimerButton.title(for: .normal), "Start")
    sut.actionTimer(sender)
    
    // Pause timer after 1 second
    let exp = expectation(description: "Timer expectation")
    DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
        self.sut.actionTimer(sender)
        XCTAssertEqual(self.sut.actionTimerButton.title(for: .normal), "Resume")
        exp.fulfil()
    }
    
    waitForExpectations(timeout: 5, handler: nil)
}

func testUpdateTimer_whenSecondsReachZero_decrementsMinuteComponent() {
    // Set up test components
    let sender = UIButton()
    let timer = Timer()
    let minutesComponent = GatherViewController.GatherCountDownTimerComponent.minutes.rawValue
    let secondsComponent = GatherViewController.GatherCountDownTimerComponent.seconds.rawValue
    
    // Set initial time to 1:00
    sut.timePickerView.selectRow(1, inComponent: minutesComponent, animated: false)
    sut.timePickerView.selectRow(0, inComponent: secondsComponent, animated: false)
    sut.timerDone(sender)
    XCTAssertEqual(sut.timerLabel.text, "01:00")
    
    // Update timer and verify decrement
    sut.updateTimer(timer)
    XCTAssertEqual(sut.timerLabel.text, "00:59")
}

In this test we checked if the seconds are decremented when the minutes component is reaching zero.

Having access to the outlets, we can easily verify the stepperDidChangeValue delegates:

func testStepperDidChangeValue_whenTeamAScores_updatesTeamAScoreLabel() {
    // Simulate Team A scoring
    sut.scoreStepper.teamAStepper.value = 1
    sut.scoreStepper.teamAStepperValueChanged(UIButton())
    
    // Verify Team A's score label is updated
    XCTAssertEqual(sut.scoreLabelView.teamAScoreLabel.text, "1")
    // Verify Team B's score label remains unchanged
    XCTAssertEqual(sut.scoreLabelView.teamBScoreLabel.text, "0")
}

func testStepperDidChangeValue_whenTeamBScores_updatesTeamBScoreLabel() {
    // Simulate Team B scoring
    sut.scoreStepper.teamBStepper.value = 1
    sut.scoreStepper.teamBStepperValueChanged(UIButton())
    
    // Verify Team B's score label is updated
    XCTAssertEqual(sut.scoreLabelView.teamAScoreLabel.text, "0")
    // Verify Team A's score label remains unchanged
    XCTAssertEqual(sut.scoreLabelView.teamBScoreLabel.text, "1")
}

func testStepperDidChangeValue_whenTeamIsBench_scoreIsNotUpdated() {
    // Simulate score change for Bench team
    sut.stepper(UIStepper(), didChangeValueForTeam: .bench, newValue: 1)
    
    // Verify no score labels are updated
    XCTAssertEqual(sut.scoreLabelView.teamAScoreLabel.text, "0")
    XCTAssertEqual(sut.scoreLabelView.teamBScoreLabel.text, "0")
}

Finally, the hardest and probably the most important method we have in GatherViewController is the endGather method. Here, we do a service call updating the gather model. We pass the winnerTeam and the score of the match.

It is a big method, does more than one thing and is private. (we use it as per example, functions should not be big and functions should do one thing!).

The responsibilities of this function are detailed below. endGather does the following:

• gets the score from scoreLabelViews
• computes the winner team by comparing the score
• creates the GatherModel for the service call
• shows a loading spinner
• does the updateGather service call
• hides the loading spinner
• handles success and failure
• for success, the view controller is popped to PlayerListViewController (this view should be in the stack)
• for failure, it presents an alert

How we should test all of that? (Again, as best practice, this function should be splitted down into multiple functions).

Let’s take one step at a time.

Creating a mocked service and injecting it in our sut:

// Set up mock networking components
private let session = URLSessionMockFactory.makeSession()
private let resourcePath = "/api/gathers"
private let appKeychain = AppKeychainMockFactory.makeKeychain()

// Configure mock endpoint and service
let endpoint = EndpointMockFactory.makeSuccessfulEndpoint(path: resourcePath)
sut.updateGatherService = StandardNetworkService(
    session: session, 
    urlRequest: AuthURLRequestFactory(endpoint: endpoint, keychain: appKeychain)
)

Testing the success handler. We use a protocol instead of the concrete class PlayerListViewController and we mock it in our test class:

// Protocol definition for view state toggling
protocol PlayerListTogglable {
    func toggleViewState()
}

// Main view controller conforming to protocol
class PlayerListViewController: UIViewController, PlayerListTogglable { .. }

private extension GatherViewControllerTests {
    // Mock implementation for testing
    final class MockPlayerTogglableViewController: UIViewController, PlayerListTogglable {
        weak var viewStateExpectation: XCTestExpectation?
        private(set) var viewState = true
        
        func toggleViewState() {
            viewState = !viewState
            viewStateExpectation?.fulfil()
        }
    }
}

This should be part of a navigation controller:

// Set up view controller hierarchy
let playerListViewController = MockPlayerTogglableViewController()
let window = UIWindow()
let navController = UINavigationController(rootViewController: playerListViewController)
window.rootViewController = navController
window.makeKeyAndVisible()

// Trigger view loading and verify initial state
_ = playerListViewController.view
XCTAssertTrue(playerListViewController.viewState)
// Set up expectation for state change
let exp = expectation(description: "Timer expectation")
playerListViewController.viewStateExpectation = exp
// Add test view controller to navigation stack
navController.pushViewController(sut, animated: false)

We check the initial viewState. It should be true.

The rest of the unit test is presented below:

// Set up mock score state
sut.scoreLabelView.teamAScoreLabel.text = "1"
sut.scoreLabelView.teamBScoreLabel.text = "1"

// Configure mock networking
let endpoint = EndpointMockFactory.makeSuccessfulEndpoint(path: resourcePath)
sut.updateGatherService = StandardNetworkService(
    session: session,
    urlRequest: AuthURLRequestFactory(endpoint: endpoint, keychain: appKeychain)
)
// Trigger gather end and handle alert
sut.endGather(UIButton())
let alertController = (sut.presentedViewController as! UIAlertController)
alertController.tapButton(atIndex: 0)
// Wait for and verify state change
waitForExpectations(timeout: 5) { _ in
    XCTAssertFalse(playerListViewController.viewState)
}

Because endGather is a private method, we had to use the IBAction that calls this method. And for tapping on OK in the alert controller that was presented we had to use its private API:

private extension UIAlertController {
    // Type definition for alert action handler
    typealias AlertHandler = @convention(block) (UIAlertAction) -> Void
  
    func tapButton(atIndex index: Int) {
          // Access private handler using key-value coding
          guard let block = actions[index].value(forKey: "handler") else { return }
          
          // Convert and execute handler
          let handler = unsafeBitCast(block as AnyObject, to: AlertHandler.self)
          handler(actions[index])
      }
}

We don’t have the guarantee this unit test will work in future Swift versions. This is bad.

Key Metrics

Lines of code

Unit Tests

Build Times

* tests were run on an 8-Core Intel Core i9, MacBook Pro, 2019

Conclusion

Model-View-Controller (MVC) remains one of the most widely adopted architectural patterns in iOS development, and for good reason. Throughout this article, we’ve explored its practical implementation in a real-world application.

In our demonstration, we took a straightforward approach by mapping each screen to a dedicated View Controller. While this implementation works for our sample application, it’s important to note that this simplified approach may not be suitable for more complex screens with numerous actions and responsibilities. In production applications, it’s often better to distribute responsibilities across multiple components, such as through the use of child view controllers.

We provided a comprehensive breakdown of each screen in our application, detailing:

• The functional role and purpose of each component
• The UI elements and their interactions
• The underlying data models and controller interactions
• Key implementation methods with practical code examples

Our experience with unit testing, particularly with the GatherViewController, revealed some challenges inherent to the MVC pattern. The need to rely on private APIs (such as with UIAlertController) highlighted potential maintenance risks, as these implementations could break with future iOS updates.

Despite these challenges, MVC remains a powerful architectural pattern when implemented thoughtfully. Its primary advantages include:

• Straightforward implementation for smaller applications
• Lower initial complexity compared to other patterns
• Strong integration with Apple’s frameworks
• Familiar structure for most iOS developers

While our metrics analysis is preliminary, we anticipate that MVC will show advantages in terms of code conciseness, as other architectural patterns typically introduce additional layers and complexity. However, a complete comparison with other patterns will be necessary to draw definitive conclusions.

In the upcoming articles in this series, we’ll explore alternative architectural patterns, providing a comprehensive comparison that will help you make informed decisions for your own iOS projects.

Thank you for following along with this deep dive into MVC! Be sure to check out the additional resources below for more information and practical examples.

Useful Links

• The iOS App — Football Gather — GitHub Repo Link
• The web server application made in Vapor — 
  GitHub Repo Link,
  ‘Building Modern REST APIs with Vapor and Fluent in Swift’ article link,
  ‘From Vapor 3 to 4: Elevate your server-side app’ article link
• Model View Controller (MVC) — article and GitHub Repo Link
• Model View ViewModel (MVVM) — article and GitHub Repo Link
• Model View Presenter (MVP) — article and GitHub Repo Link
• Coordinator Pattern — MVP with Coordinators (MVP-C) — article and GitHub Repo Link
• View Interactor Presenter Entity Router (VIPER) — article and GitHub Repo Link
• View Interactor Presenter (VIP) — article and GitHub Repo Link

Battle of the iOS Architecture Patterns: Model View Controller (MVC) was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

From Vapor 3 to 4: Elevate your server-side app

In this article, we will explore how to migrate an application developed in Vapor 3 to the latest version, Vapor 4.

Short recap

We saw together in how we can develop a basic REST API in Vapor 3.

We covered in this article (ℹ️ or you can read it on my personal website — link here) how to develop a basic REST API using Vapor 3.

The server-side app structure in Vapor 3 is as follows:

├── Public
├── Sources
│ ├── App
│ │ ├── Controllers
│ │ ├── Models
│ │ ├── boot.swift
│ │ ├── configure.swift
│ │ └── routes.swift
│ └── Run
│ └── main.swift
├── Tests
│ └── AppTests
└── Package.swift

Package.swift

• This file is the project’s manifest and defines all dependencies and targets for the app.
  The project is set to use Vapor 3.3.0:
  .package(url: "https://github.com/vapor/vapor.git", from: "3.3.0")

Public

• Contains all public resources, such as images.

Sources

• Contains two separate modules: App and Run.
  The App folder is where you put all your developed code.
  The Run folder contains the main.swift file.

Models

• This is where you add your Fluent models. In this app, the models are: User, Player, Gather.

Controllers

• Controllers contain the logic of your REST API, such as CRUD operations.
  They are similar to iOS ViewControllers but handle requests and manage models.

routes.swift

• Used to find the appropriate response for an incoming request.

configure.swift

• This file is called before the app is initialized. It registers the router, middlewares, database, and model migrations.

When the server app runs, the sequence is:
main.swift → app.swift (to create an instance of the app) → configure.swift (called before the app initializes) → routes.swift (handles route registration) → boot.swift (called after the app is initialized).

Migration

Package

A lot has changed from Vapor 3, and migrating to Vapor 4 is not as straightforward as it might seem.

Below, we present the differences in the Package.swift file. You can also check it out on GitHub.

Updating our Models

Vapor 4 harnesses the full potential of Swift and includes property wrappers at its core.
The Model protocol now replaces the previous SQLiteTypeModel that was extended in Vapor 3.
Additionally, models no longer need to implement Migration.

We also remove the SQLiteUUIDPivot protocol and update PlayerGatherPivot to implement the standard Model protocol.

The foreign and private keys are now defined using the @Parent property wrapper.

You can see below the transformations applied to the codebase:

• Gather model transformation — commit
• Player model transformation — commit
• Pivot model transformation — commit
• Token model transformation — commit
• User model transformation — commit

Here is an example of the updated PlayerGatherPivot model:

import Vapor
import FluentSQLiteDriver

// MARK: - Model
final class PlayerGatherPivot: Model {
    static let schema = "player_gather"
    @ID(key: .id)
    var id: UUID?
    @Parent(key: "player_id")
    var player: Player
    @Parent(key: "gather_id")
    var gather: Gather
    @Field(key: "team")
    var team: String
    init() {}
    init(playerID: Player.IDValue,
         gatherID: Gather.IDValue,
         team: String) {
        self.$player.id = playerID
        self.$gather.id = gatherID
        self.team = team
    }
}
// MARK: - Migration
extension PlayerGatherPivot: Migration {
    func prepare(on database: Database) -> EventLoopFuture {
        database.schema(PlayerGatherPivot.schema)
            .field("id", .uuid, .identifier(auto: true))
            .field("player_id", .int, .required)
            .field("gather_id", .uuid, .required)
            .field("team", .string, .required)
            .create()
    }
    func revert(on database: Database) -> EventLoopFuture {
        database.schema(PlayerGatherPivot.schema).delete()
    }
}

Updating our Controllers

Route collections still use the boot function, but the function’s parameter type has changed from Router to RoutesBuilder.

We no longer use Model.parameter. Instead, we now use :id as a parameter marker.

Fetching the authenticated user has changed from this in Vapor 3:

let user = try req.requireAuthenticated(User.self)
return try user.gathers.query(on: req).all()

To this in Vapor 4:

let user = try req.auth.require(User.self)

Regarding authentication, the middleware setup has also changed:

let tokenAuthMiddleware = Token.authenticator()
let guardMiddleware = User.guardMiddleware() // same as Vapor 3
let tokenAuthGroup = gatherRoute.grouped(tokenAuthMiddleware, guardMiddleware)

The token authentication middleware now implements a new protocol called ModelTokenAuthenticatable:

extension Token: ModelTokenAuthenticatable {
    static let valueKey = \Token.$token
    static let userKey = \Token.$user

    var isValid: Bool { true }
}

You can check all Vapor 4 controller transformations on GitHub:

• GatherController transformation - GitHub Link
• PlayerController transformation - GitHub Link
• UserController transformation - GitHub Link

The CRUD operations have undergone significant changes:

GET All Gathers

func getGathersHandler(_ req: Request) throws -> EventLoopFuture<[GatherResponseData]> {
    let user = try req.auth.require(User.self)
    return user.$gathers.query(on: req.db)
        .all()
        .flatMapEachThrowing {
            try GatherResponseData(
                id: $0.requireID(),
                userId: user.requireID(),
                score: $0.score,
                winnerTeam: $0.winnerTeam
            )
        }
}

Note that flatMapEachThrowing is used to apply a closure to each element in the sequence, which is wrapped in an EventLoopFuture.

CREATE a Gather

func createHandler(_ req: Request) throws -> EventLoopFuture {
    let user = try req.auth.require(User.self)
    let gather = try Gather(userID: user.requireID())
    return gather.save(on: req.db).map {
        let response = Response()
        response.status = .created
        if let gatherID = gather.id?.description {
            let location = req.url.path + "/" + gatherID
            response.headers.replaceOrAdd(name: "Location", value: location)
        }
        return response
   }
}

DELETE a Gather

func deleteHandler(_ req: Request) throws -> EventLoopFuture {
    let user = try req.auth.require(User.self)

    guard let id = req.parameters.get("id", as: UUID.self) else {
        throw Abort(.badRequest)
    }
    return Gather.find(id, on: req.db).flatMap {
        guard let gather = $0 else {
            throw Abort(.notFound)
        }
        return gather.delete(on: req.db).transform(to: .noContent)
    }
}

UPDATE a gather

func updateHandler(_ req: Request) throws -> EventLoopFuture {
    let user = try req.auth.require(User.self)
    let gatherUpdateDate = try req.content.decode(GatherUpdateData.self)

    guard let id = req.parameters.get("id", as: UUID.self) else {
        throw Abort(.badRequest)
    }

    return user.$gathers.get(on: req.db).flatMap { gathers in
        guard let gather = gathers.first(where: { $0.id == id }) else {
            return req.eventLoop.makeFailedFuture(Abort(.notFound))
        }

        gather.score = gatherUpdateDate.score
        gather.winnerTeam = gatherUpdateDate.winnerTeam

        return gather.save(on: req.db).transform(to: .noContent)
    }
}

GET players of a specified gather

func getPlayersHandler(_ req: Request) throws -> EventLoopFuture<[PlayerResponseData]> {
    let user = try req.auth.require(User.self)
    guard let id = req.parameters.get("id", as: UUID.self) else {
        throw Abort(.badRequest)
    }

    return user.$gathers.get(on: req.db).flatMap { gathers in
        guard let gather = gathers.first(where: { $0.id == id }) else {
            return req.eventLoop.makeFailedFuture(Abort(.notFound))
        }

        return gather.$players.query(on: req.db)
            .all()
            .flatMapEachThrowing {
                try PlayerResponseData(
                    id: $0.requireID(),
                    name: $0.name,
                    age: $0.age,
                    skill: $0.skill,
                    preferredPosition: $0.preferredPosition,
                    favouriteTeam: $0.favouriteTeam
                )
            }
    }
}

POST player to a specified gather

func addPlayerHandler(_ req: Request) throws -> EventLoopFuture {
      let user = try req.auth.require(User.self)
      let playerGatherData = try req.content.decode(PlayerGatherData.self)

      guard let gatherID = req.parameters.get("gatherID", as: UUID.self) else {
          throw Abort(.badRequest)
      }

      guard let playerID = req.parameters.get("playerID", as: Int.self) else {
          throw Abort(.badRequest)
      }

      let gather = user.$gathers.query(on: req.db)
          .filter(\.$id == gatherID)
          .first()

      let player = user.$players.query(on: req.db)
          .filter(\.$id == playerID)
          .first()

      return gather.and(player).flatMap { _ in
          let pivot = PlayerGatherPivot(
              playerID: playerID,
              gatherID: gatherID,
              team: playerGatherData.team
          )

          return pivot.save(on: req.db).transform(to: .ok)
      }
}

Models in Vapor 4

The application has the following registered models: User, Gather, Player, PlayerGatherPivot, and Token.

User Model

The User model has three main properties:

• id: A UUID that serves as the primary key.
• username: A unique name created during registration.
• password: The hashed password of the user.

An inner class, User.Public, is defined to control what public information (just the username) is exposed through methods such as GET.

The one-to-many relationships with Gather (a user can create multiple gatherings) and with Player (a user can create multiple players) are implemented using the Fluent @Children property wrapper:

final class User: Model {
    static let schema = "users"

    @ID(key: .id)
    var id: UUID?

    @Field(key: "username")
    var username: String

    @Field(key: "password")
    var password: String

    @Children(for: \.$user)
    var gathers: [Gather]

    @Children(for: \.$user)
    var players: [Player]

    init() {}

    init(id: UUID? = nil,
         username: String,
         password: String) {
        self.id = id
        self.username = username
        self.password = password
    }
}

We use extensions to wrap our functions for transforming a normal User to User.Public and vice versa:

// MARK: - Public User
extension User {
    final class Public {
        var id: UUID?
        var username: String

        init(id: UUID?, username: String) {
            self.id = id
            self.username = username
        }
    }
}

extension User.Public: Content {}

extension User {
    func toPublicUser() -> User.Public {
        return User.Public(id: id, username: username)
    }
}

Token Model

The Token model defines a mapping between a generated 16-byte data (the actual token) that is base64 encoded and the user ID.

To generate the token, we use the CryptoRandom().generateData function, which relies on OpenSSL RAND_bytes to generate random data of the specified length.

The authentication pattern for the server application is Bearer token authentication.
Vapor simplifies this process by requiring the implementation of the BearerAuthenticatable protocol and specifying the key path of the token key:
static let tokenKey: TokenKey = \Token.token.

final class Token: Model {
    static let schema = "tokens"

    @ID(key: .id)
    var id: UUID?

    @Field(key: "token")
    var token: String

    @Parent(key: "user_id")
    var user: User

    init() {}

    init(id: UUID? = nil,
         token: String,
         userID: User.IDValue) {
        self.id = id
        self.token = token
        self.$user.id = userID
    }
}

// MARK: - Authenticable
extension Token: ModelTokenAuthenticatable {
    static let valueKey = \Token.$token
    static let userKey = \Token.$user

    var isValid: Bool { true }
}

Gather Model

The Gather model represents our football matches.

It has a parent identifier (the user ID) and two optional string parameters: the score and the winning team.

final class Gather: Model {
    static let schema = "gathers"

    @ID(key: "id")
    var id: UUID?

    @Parent(key: "user_id")
    var user: User

    @OptionalField(key: "score")
    var score: String?

    @OptionalField(key: "winner_team")
    var winnerTeam: String?

    @Siblings(through: PlayerGatherPivot.self, from: \.$gather, to: \.$player)
    var players: [Player]

    init() {}

    init(id: UUID? = nil,
         userID: User.IDValue,
         score: String? = nil,
         winnerTeam: String? = nil) {
        self.id = id
        self.$user.id = userID
        self.score = score
        self.winnerTeam = winnerTeam
    }
}

Player Model

The Player model is defined similarly to the Gather model:

• userID: The ID of the user who created this player (the parent).
• name: Combines the first and last names.
• age: An optional integer to store the player's age.
• skill: An enum specifying the player's skill level (beginner, amateur, or professional).
• preferredPosition: Represents the position on the field that the player prefers.
• favouriteTeam: An optional string parameter to record the player's favorite team.

final class Player: Model {
    static let schema = "players"

    @ID(custom: \.$id)
    var id: Int?

    @Parent(key: "user_id")
    var user: User

    @Field(key: "name")
    var name: String

    @OptionalField(key: "age")
    var age: Int?

    @OptionalField(key: "skill")
    var skill: Skill?

    @OptionalField(key: "position")
    var preferredPosition: Position?

    @OptionalField(key: "favourite_team")
    var favouriteTeam: String?

    @Siblings(through: PlayerGatherPivot.self, from: \.$player, to: \.$gather)
    public var gathers: [Gather]

    convenience init() {
        self.init(userID: UUID(), name: "")
    }

    init(id: Int? = nil,
         userID: User.IDValue,
         name: String,
         age: Int? = nil,
         skill: Skill? = nil,
         preferredPosition: Position? = nil,
         favouriteTeam: String? = nil) {
        self.id = id
        self.$user.id = userID
        self.name = name
        self.age = age
        self.skill = skill
        self.preferredPosition = preferredPosition
        self.favouriteTeam = favouriteTeam
    }
}

Relationships

Vapor 3

The many-to-many relationship between gathers and players (where one gather can have multiple players and one player can be in multiple gathers) is implemented using Fluent pivots.

To achieve this, we create a new model class that extends SQLiteUUIDPivot (SQLite is the database we are currently using) and specify the key paths of the tables:

static var leftIDKey: LeftIDKey = PlayerGatherPivot.playerId
static var rightIDKey: RightIDKey = PlayerGatherPivot.gatherId

In our model classes, we can create convenient methods to access the gathers that a player has participated in, and conversely, the players that are part of a given gather:

extension Player {
    var gathers: Siblings {
        return siblings()
    }
}

extension Gather {
    var players: Siblings {
        return siblings()
    }
}

Migrating to Vapor 4

final class PlayerGatherPivot: Model {
    static let schema = "player_gather"

    @ID(key: .id)
    var id: UUID?

    @Parent(key: "player_id")
    var player: Player

    @Parent(key: "gather_id")
    var gather: Gather

    @Field(key: "team")
    var team: String

    init() {}

    init(playerID: Player.IDValue,
         gatherID: Gather.IDValue,
         team: String) {
        self.$player.id = playerID
        self.$gather.id = gatherID
        self.team = team
    }
}

 // MARK: - Migration
extension Gather: Migration {
    func prepare(on database: Database) -> EventLoopFuture {
        database.schema(Gather.schema)
            .field("id", .uuid, .identifier(auto: true))
            .field("user_id", .uuid, .required, .references("users", "id"))
            .foreignKey("user_id", references: "users", "id", onDelete: .cascade)
            .field("score", .string)
            .field("winner_team", .string)
            .create()
    }
}

extension Player: Migration {
    func prepare(on database: Database) -> EventLoopFuture {
        database.schema(Player.schema)
            .field("id", .int, .identifier(auto: true))
            .field("user_id", .uuid, .required, .references("users", "id"))
            .foreignKey("user_id", references: "users", "id", onDelete: .cascade)
            .field("name", .string, .required)
            .field("age", .int)
            .field("skill", .string)
            .field("position", .string)
            .field("favourite_team", .string)
            .create()
    }
}

Controllers

The service logic and routing are managed with RouteCollections.

In the boot function, we define the service paths and specify the methods to handle incoming requests.

For all collections, we define the resource path as api/{resource}. For example: api/users, api/gathers, or api/players.

Thus, if a GET request is made to https://foo.net/api/{resource}, Vapor will look for the corresponding route and method. Remember to register it in routes.swift.

UserController

• POST /api/users/login — Login functionality for users
• POST /api/users — Registers a new user
• GET /api/users — Gets the list of users
• GET /api/users/{userId} — Gets user by their ID
• DELETE /api/users/{user_id} — Deletes a user by the given ID

Code snippet:

extension UserController {
    func createHandler(_ req: Request) throws -> EventLoopFuture {
        let user = try req.content.decode(User.self)
        user.password = try Bcrypt.hash(user.password)

        return user.save(on: req.db).map {
            let response = Response()
            response.status = .created

            if let userID = user.id?.description {
                let location = req.url.path + "/" + userID
                response.headers.replaceOrAdd(name: "Location", value: location)
            }

            return response
        }
    }
}

Before saving the user in the database, we hash the password using BCryptDigest.

After the user is saved, we retrieve the ID and return it as part of the Location response header, adhering to RESTful API practices by returning status codes instead of the actual resource.

The newly created resource can be associated with the unique ID provided in the Location header field. (https://restfulapi.net/http-status-codes/).

The full implementation can be found on GitHub.

GatherController

The GatherController contains the following methods:

GET /api/gathers — Retrieves all gathers for the authenticated user

POST /api/gathers — Creates a new gather for the authenticated user.

• The model for creation data is a subset of the actual Gather model, containing the score and the winner team, both parameters being optional.
• This is similar to the User’s create method; if successful, we return the gather ID as part of the Location header.

DELETE /api/gathers/{gather_id} — Deletes the gather by its ID

PUT /api/gathers/{gather_id} — Updates the gather associated with the given ID.

• We search through all saved gathers to find a match for the given ID.
• If successful, we update the score and winner team of the gather.
• Finally, we return 204.

POST /api/gathers/{gather_id}/players/{player_id} — Adds a player to a gather.

• Many-to-many relationship.
• We search for a gather with the given ID, similar to the update method.
• If found, we retrieve it and create a new pivot.
• Finally, we save the pivot model in the database and return 200.

GET /api/gathers/{gather_id}/players — Returns the players for the given gather.

• Similar to the update and add player methods, we search for the gather with the given ID.
• If found, we return all players associated with that gather.

Code snippet:

func addPlayerHandler(_ req: Request) throws -> EventLoopFuture {
    let user = try req.auth.require(User.self)
    let playerGatherData = try req.content.decode(PlayerGatherData.self)

    guard let gatherID = req.parameters.get("gatherID", as: UUID.self) else {
        throw Abort(.badRequest)
    }

    guard let playerID = req.parameters.get("playerID", as: Int.self) else {
        throw Abort(.badRequest)
    }

    let gather = user.$gathers.query(on: req.db)
        .filter(\.$id == gatherID)
        .first()

    let player = user.$players.query(on: req.db)
        .filter(\.$id == playerID)
        .first()

    return gather.and(player).flatMap { _ in
        let pivot = PlayerGatherPivot(playerID: playerID,
                                      gatherID: gatherID,
                                      team: playerGatherData.team)

        return pivot.save(on: req.db).transform(to: .ok)
    }
}

Conclusion

Vapor is an excellent framework for server-side programming, offering rich APIs for your web applications. More importantly, it is built on top of Swift, integrating the new features of the language into its core. This allows you to harness the true power of Swift, including features like property wrappers.

In this article, we examined a practical example of how to migrate an older application written in Vapor 3 to the latest version, Vapor 4.

The migration wasn’t as straightforward as we expected; many changes occurred between these versions.
The most notable change is the Fluent Models, which have now been moved to their own package in Vapor 4.

For a detailed overview of all changes, you can check this specific commit on GitHub.

Useful Links

• My repository with the example used in this article
• Vapor GitHub Repository
• Fluent ORM Repository
• Upgrading to Vapor 4
• The Swift Dev Blog Articles
• Article on Ray Wenderlich — Getting Started with Server-Side Swift
• Vapor 4 Book
• Interesting talks by Tim Condon (member of Vapor’s Core Team)
• Vapor’s Discord Server

Stubbing your network responses with WireMock

Motivation

While working on unit tests for network responses, I was searching for a robust alternative to OHHTTPStubs when I discovered WireMock. What caught my attention was that it’s written in Java, runs as a standalone process, and offers a straightforward implementation.

Best of all, I wouldn’t need to make my project dependent on a third-party library by importing it directly into my unit test files.

Understanding Stubbing vs Mocking

Let’s start with stubbing: A stub provides predefined, consistent behavior. Think of it as a simple input-output mechanism — when you call method X, you’ll always get result Y. In our case, when working with API requests, we’ll create JSON files that serve as predetermined responses for specific endpoints.

Here’s a simple example:

POST /users {"firstName": "John", "lastName": "Smith"}

When this request is made, our JSON file register-stub.json will consistently return a 200 OK response. It's predictable and straightforward.

Mocking, on the other hand, is more sophisticated. Mocks are what you configure as part of your test expectations, allowing you to verify behavior and interactions. They’re more flexible and can be programmed to respond differently based on various conditions.

Let’s look at a practical example with WireMock:

{
    "request": {
        "method": "POST",
        "url": "/api/users/login/success",
        "headers": {
            "Accept": {
                "equalTo": "application/json"
            },
            "Content-Type": {
                "equalTo": "application/json"
            }
        },
        "basicAuthCredentials": {
            "username": "demo-user",
            "password": "41bd876b085d6031cb0e04de35b88d77f83a4ba39f879fee40805ac19e356023"
        }
    },
    "response": {
        "status": 200,
        "headers": {
            "Content-Type": "application/json; charset=utf-8"
        },
        "bodyFileName": "happy-path/response-200-users-login.json"
    }
}

Example mappings.user-login

{
    "request": {
        "method": "POST",
        "url": "/api/users/login/success",
        "headers": {
            "Accept": {
                "equalTo": "application/json"
            },
            "Content-Type": {
                "equalTo": "application/json"
            }
        },
        "basicAuthCredentials": {
            "username": "demo-user",
            "password": "41bd876b085d6031cb0e04de35b88d77f83a4ba39f879fee40805ac19e356023"
        }
    },
    "response": {
        "status": 200,
        "headers": {
            "Content-Type": "application/json; charset=utf-8"
        },
        "bodyFileName": "happy-path/response-200-users-login.json"
    }
}

And __files/happy-path/response-200-users-login.json:

{
    "id": "5D38234E-D67D-4DCF-BDB4-B9B7D21BA092",
    "token": "v2s4o0XcRgDHF/VojbAmGQ==",
    "userID": "07C3E7A9-7B0B-4CD8-97E0-93AEC7093862"
}

Practical Use Case: Testing Your Networking Layer

Let’s dive into a real-world scenario: You’ve just finished developing your networking framework, and now it’s time to ensure its reliability through comprehensive unit tests. This is where WireMock really shines.

To set the stage, here’s how the standard endpoint of your application might be structured:

/// A standard implementation of the Endpoint protocol that represents
/// a network endpoint configuration
struct StandardEndpoint: Endpoint {
    /// The path component of the URL (e.g., "/api/users")
    var path: String
    
    /// Optional query parameters to be added to the URL
    /// Example: ["page": "1", "limit": "10"]
    var queryItems: [URLQueryItem]? = nil
    
    /// The URL scheme (defaults to "https")
    var scheme: String? = "https"
    
    /// The host domain (defaults to "foo.com")
    var host: String? = "foo.com"
    
    /// Optional port number for the URL
    /// Example: 8080 would result in foo.com:8080
    var port: Int? = nil

    /// Initializes a new endpoint with the given path
    /// - Parameter path: The URL path component
    init(path: String) {
        self.path = path
    }
}

Now that we understand the basics, let’s create our test environment. We’ll use the mocks we discussed earlier (EndpointMock and URLSessionMockFactory) to set up our test scenario. Here's how we can structure our test file for maximum clarity and effectiveness:

You create your Mocks (EndpointMock and URLSessionMockFactory) as defined in the previous section. The tests file can be defined as below:

import XCTest
@testable import FootballGather

/// Test suite for the LoginService class that handles user authentication
final class LoginServiceTests: XCTestCase {
    /// Mocked URLSession for simulating network requests
    private let session = URLSessionMockFactory.makeSession()
    
    /// API endpoint path for user login
    private let resourcePath = "/api/users/login"
    
    /// Mocked keychain for storing authentication tokens
    private let appKeychain = AppKeychainMockFactory.makeKeychain()
    
    /// Cleans up any stored data after each test
    override func tearDown() {
        appKeychain.storage.removeAll()
        super.tearDown()
    }
    
    /// Tests that a login request completes successfully and stores the token
    func test_request_completesSuccessfully() {
        let endpoint = EndpointMockFactory.makeSuccessfulEndpoint(path: resourcePath)
        let service = LoginService(
            session: session,
            urlRequest: StandardURLRequestFactory(endpoint: endpoint),
            appKeychain: appKeychain
        )
        let user = ModelsMockFactory.makeUser()
        let exp = expectation(description: "Waiting response expectation")
        
        service.login(user: user) { [weak self] result in
            switch result {
            case .success(let success):
                XCTAssertTrue(success)
                XCTAssertEqual(self?.appKeychain.token!, ModelsMock.token)
                exp.fulfill()
            case .failure(_):
                XCTFail("Unexpected failure")
            }
        }
        
        // Wait for async operation to complete
        wait(for: [exp], timeout: TestConfigurator.defaultTimeout)
    }
    
    // other methods
}

Where:

• session — Is a mocked URLSession having an ephemeral configuration
• resourcePath — Is used for creating the endpoint URL for the User resources
• appKeychain — Is a mocked storage that acts as a Keychain for holding the token passed in the requests, after authentication. All data is hold in memory in a cache dictionary.

In the test method, we define the mocks we are going to use in the login method.

The actual method is defined below:

/// Authenticates a user and stores their token in the keychain
/// - Parameter user: The user credentials model for authentication
/// - Returns: A boolean indicating successful authentication
/// - Throws: ServiceError or network-related errors
func login(user: UserRequestModel) async throws -> Bool {
    // Prepare the HTTP request
    var request = urlRequest.makeURLRequest()
    request.httpMethod = "POST"
    
    // Create and set Basic Authentication header
    let basicAuth = BasicAuth(
        username: user.username,
        password: Crypto.hash(message: user.password)!
    )
    request.setValue(
        "Basic \(basicAuth.encoded)",
        forHTTPHeaderField: "Authorization"
    )
    
    do {
        // Perform the network request
        let (data, _) = try await session.data(for: request)
        
        // Validate response data
        guard !data.isEmpty else {
            throw ServiceError.expectedDataInResponse
        }
        
        // Decode the login response
        let loginResponse = try JSONDecoder().decode(
            LoginResponseModel.self,
            from: data
        )
        
        // Store the authentication token
        appKeychain.token = loginResponse.token
        
        return true
    } catch let decodingError as DecodingError {
        // Handle JSON decoding errors
        throw ServiceError.unexpectedResponse
    }
    // Other errors will propagate automatically
}

For authentication, we send the username and password hash in the request header, using base64 encoding with a colon separator (:). This follows the standard basic access authentication principle.

Upon successful authentication, the server returns a unique UUID token that we’ll use for subsequent network calls. This token is securely stored in the user’s keychain and includes an expiration mechanism for enhanced security.

Our unit test focuses on the “happy path” scenario, verifying two key aspects: successful request completion and proper token storage in the app’s keychain.

Setting Up WireMock for Testing

To ensure reliable testing, we need to properly initialize WireMock before our test suite runs and gracefully shut it down afterward. Here’s how to set this up:

First, in Xcode, follow these steps:

1. Open your project scheme (⌘ + <)
2. Click ‘Edit Scheme’
3. In the left panel, select ‘Test’
4. Navigate to ‘Pre-actions’
5. Add the following startup script:

java -jar "${SRCROOT}/../stubs/wiremock-standalone-2.22.0.jar" --port 9999 --root-dir "${SRCROOT}/../stubs" 2>&1 &

Here’s the folder structure we’re using in this example:

For proper cleanup, add this shutdown command to the Post-actions section:

curl -X POST http://localhost:9999/__admin/shutdown

With this setup in place, you can now run your unit tests and watch them pass successfully.

Integrating with Continuous Integration

Here’s a sample GitHub Actions workflow configuration (Note: You may need to adjust this based on your specific needs):

name: iOS Tests
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: macos-latest
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup Java for WireMock
      uses: actions/setup-java@v3
      with:
        distribution: 'temurin'
        java-version: '11'
    
    - name: Start WireMock
      run: ./scripts/start-wiremock.sh
    
    - name: Select Xcode
      uses: maxim-lobanov/setup-xcode@v1
      with:
        xcode-version: latest-stable
    
    - name: Run Tests
      run: ./scripts/run-tests.sh
      
    - name: Stop WireMock
      if: always()  # Ensures this runs even if tests fail
      run: ./scripts/stop-wiremock.sh

You can take the scripts from here.

Conclusion

Throughout this article, we’ve explored how WireMock provides a robust solution for testing network interactions in iOS applications. We’ve covered everything from basic request stubbing to practical implementation in a login scenario, demonstrating how WireMock can be integrated into your testing workflow without adding dependencies to your main project.

Key takeaways from our exploration:

• WireMock runs as a standalone Java process, keeping your test code clean and dependency-free
• It provides powerful stubbing capabilities for simulating various network scenarios
• The setup integrates smoothly with both local development and CI/CD pipelines
• You can effectively test both success and error scenarios in your networking layer

For practical examples of implementation, you can explore the complete source code in my GitHub repository:

• Networking Unit Tests — GitHub link
• WireMock Stubs — GitHub link

WireMock’s capabilities extend far beyond what we’ve covered here. You can simulate various network conditions, inject failures, define complex response patterns using regex, and leverage extensive logging capabilities for debugging. Whether you’re working on a simple networking layer or a complex API-driven application, WireMock provides the tools you need for comprehensive testing.

References

• For a comprehensive overview of network stubbing options in Swift, check out this excellent guide on Medium
• Martin Fowler’s seminal article “Mocks Aren’t Stubs” provides essential background on test double patterns