I am continuing the series of articles about the RouteComposer library that we use. In this article, I want to talk about the Coordinator Pattern. I was prompted to write this article by a discussion in one of the previous articles about the Coordinator Pattern.

The Coordinator Pattern, having been introduced recently, is gaining more and more popularity in the iOS developer community, and, in general, it is clear why. Out-of-the-box tools that UIKit provides are a rather unstandardised mess.

I previously raised issues in handling the fragmentation in the ways of building the view controller into the stack. …

In my previous article I brought you through RouteComposer— the library we use in our iOS applications that handles composition, navigation and deep-linking tasks. In this article I will go over some tricky elements of the library.

How the Router parses the configuration:

The Router goes by the chain of steps starting from the first step. If the Finder of this step says that the UIViewController of this step does not exist, it moves on to the next one. It does this until one of the finders say that it has found the UIViewController described in the chain. …

In this article I want to share the experience that we have been successfully using for several years in our iOS applications, 3 of which are currently in the Appstore (Saks Fifth Avenue, Gilt, Appytoy). This approach has proved itself to be effective and we recently segregated it from the rest of the code and designed it into a separate RouteComposer library, which is the main focus of this article. It also can be used as the universal replacement for the Coordinator pattern.

https://github.com/saksdirect/route-composer

But, for starters, let’s try to figure out what is meant by the composition of the view controllers in iOS. …