RouterService is a navigation/routing/dependency injection framework where all navigation is done through Routes. Based on the system used at Airbnb presented at BA:Swiftable 2019.

RouterService is meant to be as a dependency injector for modular apps where each targets contains an additional "interface" target. The linked article contains more info about that, but as a summary, this starts from the principle that a feature target should never directly depend on another one. Instead, a feature only has access to another feature's interface, which contains RouterService's Route objects. RouterService then takes care of executing this Route and injecting the necessary dependencies.

The final result is:

• An app with a horizontal dependency graph (very fast build times)
• Dynamic navigation (any screen can be pushed from anywhere)

Alongside a interfaced modular app, the RouterService framework attempts to improve build times by completely severing the connections between ViewControllers. This is how a RouterService app operates:

• You have a Dependency protocol, which can be any class instance needed by anyone at any point. (additional parameters like a screen's "context" are not dependencies)
• A Feature is a class that creates instances of a ViewController, given a list of said dependencies. They are not public. Here's an example:

Target: HTTPClientInterface, who imports RouterServiceInterface:

import RouterServiceInterface

protocol HTTPClientProtocol: Dependency {}

Target: HTTPClient, who imports HTTPClientInterface:

import HTTPClientInterface

class HTTPClient: HTTPClientProtocol { ... }

Target: Profile, who imports HTTPClientInterface and RouterServiceInterface, but not their concrete targets:

import HTTPClientInterface
import RouterServiceInterface

enum ProfileFeature: Feature {
    struct Dependencies {
        let client: HTTPClientProtocol
        let routerService: RouterServiceProtocol
    }

    static var dependenciesInitializer: AnyDependenciesInitializer {
        return AnyDependenciesInitializer(Dependencies.init)
    }

    static func build(
        dependencies: ProfileFeature.Dependencies,
        fromRoute route: Route?
    ) -> UIViewController {
        return ProfileViewController(...)
    }
}

Because the feature is isolated from the concrete client and other features, changes made to these targets will not recompile the Profile target, as the real instances will be injected in runtime by the RouterService. That's a big build time improvement!

Instead of pushing features by directly creating instances of their ViewControllers, in RouterService, the navigation is done completely through Routes. By themselves, Routes are just Codable structs that can hold contextual information about an action (like the previous screen that triggered this route, for analytics purposes). However, the magic comes from how they are used: Routes are paired with RouteHandlers: classes that define a list of supported Routes and a method that returns which Feature should be pushed when a certain Route is executed. For example, to expose the ProfileFeature shown above to the rest of the app, the hypothetical Profile target could expose routes through its interface, and define a public ProfileRouteHandler like this:

Target: ProfileInterface, which depends on RouterServiceInterface:

struct ProfileRoute: Route {
    static let identifier: String = "profile_mainroute"
    let analyticsContext: String
}

Target: Profile, as seen before, but now also depending on ProfileInterface:

import ProfileInterface
import RouterServiceInterface

public final class ProfileRouteHandler: RouteHandler {
    public var routes: [Route.Type] {
        return [ProfileRoute.self]
    }

    public func destination(
        forRoute route: Route,
        fromViewController viewController: UIViewController
    ) -> AnyFeature {
        guard route is ProfileRoute else {
            preconditionFailure()
        }
        return AnyFeature(ProfileFeature.self)
    }
}

Now, to push a new Feature, all a Feature has to do is import its next feature's interface target and call the navigate(_:) method from the RouterServiceProtocol (which is accessible through the Feature's dependencies -- note how it is added as a dependency in the ProfileFeature example), sending the desired Route to be navigated to.

import SomeLoginInterface

let loginRoute = SomeLoginRouteFromTheLoginFeature()
dependencies.routerService.navigate(
    toRoute: loginRoute,
    fromView: self,
    presentationStyle: Push(),
    animated: true
)

Again, as Profile does not directly imports the concrete SomeLogin target, changes made to it will not recompile Profile unless the interface itself is changed.

If all features are isolated, how do you start the app?

While the features are isolated from the other targets, you should have a "main" target that imports everything and everyone. From there, you can create a concrete instance of your RouterService and register everyone's RouteHandlers and Dependencies.

import HTTPClient
import Profile
import Login

class AppDelegate {

   let routerService = RouterService()

   func didFinishLaunchingWith(...) {
       routerService.register(dependency: HTTPClient(), forType: HTTPClientProtocol.self)

       routerService.register(routeHandler: ProfileRouteHandler())
       routerService.register(routeHandler: LoginRouteHandler())

       //Your usual UIWindow stuff
       //...
       window.rootViewController = routerService.navigationController(withInitialFeature: ProfileFeature.self)

       return true
   }
}

For more information and examples, check the example app provided inside this repo.

All Routes are Codable, but what if more than one route can be returned by the backend?

For this purpose, RouterServiceInterface provides a type-erased AnyRoute that can decode any registered Route from a specific string format. This allows you to have your backend dictate how navigation should be handled inside the app.

AnyRoute is Decodable, so you should first add it to your backend's response model:

struct ProfileResponse: Decodable {
    let title: String
    let route: AnyRoute
}

But before decoding ProfileResponse, you need to inject a RouterService that contains the desired routes registered into the JSONDecoder() by using the relevant method from RouterServiceProtocol:

let decoder = JSONDecoder()

routerService.injectContext(toDecoder: decoder)

decoder.decode(ProfileResponse.self, from: data)

The string format expected by the framework is a string in the route_identifier|parameters_json_string. For example, to decode the ProfileRoute shown in the beginning of this README, ProfileResponse should look like this:

{
    "title": "Profile Screen",
    "route": "profile_mainroute|{\"analyticsContext\": \"Home\"}"
}

pod 'RouterService'