The UIKit framework makes it trivial to navigate between view controllers. You can perform a segue if you use storyboards or you can programmatically navigate from one view controller to the next. This is convenient, but there's also a cost. If you use the API the UIKit framework offers you to navigate between view controllers, then you have less control and flexibility. This can become a significant problem as your project grows.

The previous episode zoomed in on the drawbacks of the UIKit framework. The coordinator pattern can help us work around these limitations. Coordinators are in some ways similar to view models. A coordinator is nothing more than an object that removes a responsibility from a view controller. It is responsible for navigation and defines the flow of the application.

If you're familiar with Cocoacasts, then you may know that I'm allergic to string literals randomly scattered in a project. Open AppCoordinator.swift and navigate to the showQuotes() method.

With the foundation in place, it's time to use the coordinator to navigate between view controllers. Remember that the goal is to put the coordinator in charge of (1) instantiating view controllers and (2) navigating between view controllers. This means that we need to make a few changes.

In the previous episodes, we applied the coordinator pattern to a typical Model-View-Controller application. A coordinator handles navigation and, as a result, simplifies the implementation of the view controllers of the project. View controllers are no longer tightly coupled, which increases their reusability. That brings us to the focus of this episode. What are the benefits and possibilities of reusable, loosely coupled view controllers?

The AppCoordinator class is responsible for navigation. It defines the flow of the application and instantiates the view controllers of the project. View controllers no longer need to worry about navigation, which makes them focused and lightweight. There is a cost to this shift in responsibilities, though. As the project grows, the complexity of the AppCoordinator class increases.

We refactored the AppCoordinator class in the previous episode. The purchase flow is no longer managed by the AppCoordinator class. We created a child coordinator, the BuyCoordinator class, which is responsible for managing the purchase flow.

At the end of the previous episode, we discovered and resolved a memory issue. When the user completes the purchase flow, the BuyCoordinator instance is deallocated by removing it from the array of child coordinators.

I hope this series has convinced you of the value of the coordinator pattern. You should have a good understanding of the pattern by now and be able to adopt it in a project. In the remainder of this series, we cover more advanced aspects of the coordinator pattern. In this and the next episodes, we zoom in on horizontal and vertical flows. Let's start by discussing the differences between horizontal and vertical flows.

We successfully converted the horizontal purchase flow to a vertical purchase flow in the previous episode. The BuyCoordinator and VerticalBuyCoordinator classes have quite a bit in common. In this episode, we add the ability to the BuyCoordinator class to manage both flows by merging the VerticalBuyCoordinator class into the BuyCoordinator class.

In the previous episodes, we added support for a vertical purchase flow. Most applications are a puzzle of horizontal and vertical flows. Combining horizontal and vertical flows allows for flexible and dynamic application flows.

The Photos project exclusively uses storyboards to design and create view controllers. In this episode, I show you that the coordinator pattern isn't limited to storyboards. You can also use the coordinator pattern if you prefer XIB files over storyboards. If you prefer to use neither, then that's possible too. It doesn't matter how you design and create the view controllers of your project.

If you're familiar with Cocoacasts, then you should know that I'm a big proponent of dependency injection. I tend to discourage developers from using the singleton pattern if the goal is creating an object that is easily accessible from anywhere in the project. That's not what the singleton pattern is about. You can learn more about the singleton pattern by reading Are Singletons Bad.

There's a common scenario we haven't covered in this series. How do you use a tab bar controller in combination with coordinators? The coordinator pattern is a flexible design pattern and there are several options for using a tab bar controller in combination with coordinators.

Earlier in this series, I mentioned that the coordinator pattern works well with the Model-View-ViewModel pattern. The resulting pattern is commonly referred to as MVVM-C or the Model-View-ViewModel-Coordinator pattern. In this episode, we refactor the PhotosViewController class. It currently uses the Model-View-Controller pattern. We update the implementation of the PhotosViewController class to use the Model-View-ViewModel pattern instead. I won't cover the details of the MVVM pattern in this episode, though. The MVVM pattern is covered in detail in Mastering MVVM With Swift.

In the [previous episode](https://cocoacasts.com/mastering-navigation-with-coordinators-the-model-view-viewmodel-coordinator-pattern) of [Mastering Navigation With Coordinators](https://cocoacasts.com/series/mastering-navigation-with-coordinators), we refactored the `PhotosViewController` class. It now uses the MVVM pattern instead of the MVC pattern. We migrated the project from the MVC-C pattern to the MVVM-C or Model-View-ViewModel-Coordinator pattern.

There are several options for sending messages from a view controller to its coordinator. Up until now we exclusively used closures to notify the coordinator. Another option is delegation and that's the pattern we explore in this episode.