So why would this be useful? Well I'm a bit of a stickler for encapsulation.When I'm building, but more importantly debugging, my view models I like to know how data is flowing through them.With strict separation between inputs and outputs I know that any side effects are only triggered as a result of values coming out of the outputs.Likewise I also know that the only thing that could trigger those outputs are the inputs and reacting to the inputs is only able to happenfrom within the view model. This separation makes reasoning about the flow of data much easier, at least for me.

To dig into this concept, let's take a look at an example view model for authenticating a user:

class AuthViewModel {
    // MARK: - Outputs
    //..

    // MARK: - Lifecycle
    init() {
        //...
    }
}

Outputs

To represent outputs Combine gives us a Publisher type. We can subscribe to them and use them to make our apps do things.At the end of a Publisher you will eventually find one or more .sink { ... } calls, these are where our side effects live.This includes things like updating the UI or saving information to a database.

Let's add an output we can use to perform a side effect based on the success or failure of an authentication attempt

class AuthViewModel {
    // MARK: - Outputs
    let signInResult: AnyPublisher<Result<Token, Error>, Never>

    // MARK: - Lifecycle
    init() {
        //...
    }
}

Here we have signInResult using the Result type as its output. When authentication is successful it will emit a .success(Token) value,when it fails it will output a .failure(Error) value.

So how do we go about triggering the work and eventually get a value from this output? We need an input!

Inputs… ?

But didn't we already decide Combine doesn't have any input types? It does have ways to model inputs, they just come with some baggage.

The types Combine gives us to send values are called Subjects. But, they are both input and output (Publisher).This means that while we can use them to trigger our authentication attempt we need to be careful about how we use them if we care about encapsulation.

Let's introduce a Subject and get our view model actually doing something:

class AuthViewModel {
    // MARK: - Outputs
    let signInResult: AnyPublisher<Result<Token, Error>, Never>

    // MARK: - Inputs
    let signIn = PassthroughSubject<(username: String, password: String), Never>()

    // MARK: - Lifecycle
    init() {
        signInResult = signIn
            .flatMap { input in
                return API
                    .authenticate(input.username, input.password)
                    .materialize()
            }
            .eraseToAnyPublisher()
    }
}

A PassthroughSubject does exactly what it says on the label. It passes values through that it receives via it's send function fulfilling its function as an input. It then uses those values as the source for its function as a Publisher, or output.

Now we have defined an input we can use it to attempt to authenticate and, finally, emit the result through our output. Let's take a look at what some code using our view model might look like:

let viewModel = AuthViewModel()

viewModel
    .signInResult
    .sink { result in
        print(result) // output: success(Token(value: "foobar"))
    }
    .store(in: &cancellables)

viewModel.signIn.send((username: "iankeen", password: "super_secret_password")) // input

Not bad, however remember Subjects are both input and output. This means we have also left the door open for code like this:

viewModel
    .signIn
    .sink { result in
        somethingUnexpected(with: result)
    }
    .store(in: &cancellables)

Consider the situation where you happen to be tracking down a bug that occurs when your users attempt to authenticate.Because we have exposed a Subject we have to check all the subscriptions to the signInResult output but also any subscriptions to the signIn input!This makes things harder than they should be…

Let's take a look at a simple approach to get our encapsulation back:

class AuthViewModel {
    // MARK: - Outputs
    let signInResult: AnyPublisher<Result<Token, Error>, Never>

    // MARK: - Inputs
    private let signIn = PassthroughSubject<(username: String, password: String), Never>()

    // MARK: - Lifecycle
    init() {
        signInResult = signIn
            .flatMap { input in
                return API
                    .authenticate(input.username, input.password)
                    .materialize()
            }
            .eraseToAnyPublisher()
    }

    // MARK: - Public Functions
    func signIn(username: String, password: String) {
        signIn.send((username, password))
    }
}

Much better! We now have closed off the ability for unintended side effects by giving signIn a private access level.Consumers of the view model can now use the signIn(username:password:) function to perform an authentication attempt.

Now we could stop here and it would be perfectly fine, but having to maintain a Subject and a function bothers me justenough to potentially over-engineer an alternative… strap yourself in.

Inputs!… for real this time

What we want is a type that exposes a way to send values publicly, but derive streams using them internally.My first thought was to try using PropertyWrappers since we can take advantage of the _value syntax to gain the encapsulation we want:

@propertyWrapper
struct Input<Parameters> {
    struct SendProxy {
        let send: (Parameters) -> Void
    }

    var wrappedValue: Parameters { fatalError("Send values via the $projectedValue") }
    var projectedValue: SendProxy { .init(send: subject.send) }

    init() { }

    let subject = PassthroughSubject<Parameters, Never>()
}

There's a fair bit going on in this little snippet so let's unpack it quickly…

The reason I first thought PropertyWrappers might be a good solution is because they allow us to expose things differently.We can use the publicly visible members (wrappedValue and projectedValue) to expose the parameters for the input and a way to send them.We can them use the restricted members (the _underscore accessor) to give the enclosing type exclusive access to the Subject.

We don't really want the wrappedValue here, it's just a means to expose a generic parameter.The projectedValue exposes a SendProxy which is just a way for use to provide only the send function to code outside the view model.

Clear as mud? Let's take a look at how we might use this in our view model and hopefully it'll make sense:

class AuthViewModel {
    // MARK: - Outputs
    let signInResult: AnyPublisher<Result<Token, Error>, Never>

    // MARK: - Inputs
    @Input var signIn: (username: String, password: String)

    // MARK: - Lifecycle
    init() {
        signInResult = _signIn // underscore accessor let's us use the `Subject` exclusively
            .subject
            .flatMap { input in
                return API
                    .authenticate(input.username, input.password)
                    .materialize()
            }
            .eraseToAnyPublisher()
    }
}

We can now sue the following syntax to send values:

viewModel.$signIn.send((username: "...", password: "..."))

The PropertyWrapper itself is a little crazy, but the view model and the call site is a little cleaner I think.Unfortunately there is actually a pretty big downside to this approach, PropertyWrappers can't be enforced in protocols.

Consider this:

protocol AuthViewModelType {
    // MARK: - Outputs
    var signInResult: AnyPublisher<Result<Token, Error>, Never> { get }

    // MARK: - Inputs
    @Input var signIn: (username: String, password: String) { get } // Property 'signIn' declared inside a protocol cannot have a wrapper
}

Since we can't enforce @Input it means code that only knows about the AuthViewModelType wouldn't have visibility to call the $signIn.send function.

This is a bit of a show stopper. I don't usually use protocols for view models but for other Combine friendly dependencies I might create I want to be able to enforce strict input/outputs.

Take two, let's try using a concrete type:

struct AnyConsumer<Output> {
    private let subject = PassthroughSubject<Output, Never>()

    func send(_ value: Output) {
        subject.send(value)
    }
}

I'm calling this AnyConsumer because it feels like a nice parallel with AnyPublisher. This type allows us to expose just the send function making this type input only just like we want;however, if we make the subject private nothing is going to be able to access it. It feels like we are stuck in a catch 22.

Let's go with it for now and update the rest of our code; first let's make our protocol enforce our strict input:

protocol AuthViewModelType {
    // MARK: - Outputs
    var signInResult: AnyPublisher<Result<Token, Error>, Never> { get }

    // MARK: - Inputs
    var signIn: AnyConsumer<(username: String, password: String)> { get }
}

The next step is to update our view model to conform to these changes:

class AuthViewModel: AuthViewModelType {
    // MARK: - Outputs
    let signInResult: AnyPublisher<Result<Token, Error>, Never>

    // MARK: - Inputs
    let signIn = AnyConsumer<(username: String, password: String)>()

    // MARK: - Lifecycle
    init() {
        signInResult = signIn
            .subject // 'subject' is inaccessible due to 'private' protection level
            .flatMap { input in
                return API
                    .authenticate(input.username, input.password)
                    .materialize()
            }
            .eraseToAnyPublisher()
    }
}

Just as we expected, while we gained the encapsulation benefits of a strict input type the view model isn't able to access the underlying Subject to use the values coming in.

We need a way to expose thee Subject but only to our view model. As it turns out we can actually use PropertyWrappers again to accomplish that!

We can bring back our @Input PropertyWrapper in a new form. This time it will work with AnyConsumer to expose the Subject to the enclosing type but will be hidden from everything else.

Lets update AnyConsumer and see what that looks like:

@propertyWrapper
struct Input<Output> {
    let wrappedValue: AnyConsumer<Output>

    var subject: PassthroughSubject<Output, Never> { wrappedValue.subject }
}

struct AnyConsumer<Output> {
    fileprivate let subject = PassthroughSubject<Output, Never>()

    func send(_ value: Output) {
        subject.send(value)
    }
}

Now we can Combine (pun intended) our @Input PropertyWrapper with our AnyConsumer to restrict access to each side of the underlying Subject.

We have exclusive access for the view model to read the input:

class AuthViewModel: AuthViewModelType {
    // MARK: - Outputs
    let signInResult: AnyPublisher<Result<Token, Error>, Never>

    // MARK: - Inputs
    @Input var signIn = AnyConsumer<(username: String, password: String)>()

    // MARK: - Lifecycle
    init() {
        signInResult = _signIn
            .subject
            .flatMap { input in
                return API
                    .authenticate(input.username, input.password)
                    .materialize()
            }
            .eraseToAnyPublisher()
    }
}

And, as before, anything using the view model can only see and call .send:

viewModel.signIn.send((username: "...", password: "..."))

Wrap up

So after all that we have ended up with something that allows us to nicely encapsulate access to two sides of a Subject.Is the extra abstraction worth it over our original private subject/function solution? There are a couple of nice advantages our final solution has that I can think of

Less typing: that's always a nice win. Using AnyConsumer we don't have to maintain a private subject as well as an additional function to get into the send function.

An explicit type: having this not only draws a nice parallel with other output types like AnyPublisher but it gives us an anchor point for things like UI bindings.Think about how you might write a button binding today:

someButton.combine.tap // example tap publisher
    .sink { [unowned self] in
        self.viewModel.signIn()
    }

Using AnyConsumer we could rewrite this subtly:

someButton.combine.tap
    .bind(to: viewModel.signIn)
    .store(in: &cancellables)

The change is minor but again it's slightly more concise and we can remove the burden of things like managing memory semantics and capture lists from our users.

That's all I have for now, but I'd love to hear any thoughts on this :)

This property wrapper can be used in conjunction with an identifier and the view modifier named matchedGeometryEffect to coordinate the animation of a part of the screen when updates occur.This was in Whats new in SwiftUI around the 19minute mark.

Unfortunately the example was super brief and only showed moving an element from within the same view body.

Let's quickly recap with an example, firstly without @Namespace and matchedGeometryEffect:

struct MyView: View {
    @State var left = true

    var body: some View {
        VStack {
            Button("Toggle", action: { withAnimation { left.toggle() } })
            HStack {
                if left {
                    Color.red.frame(width: 100, height: 100)
                    Spacer()

                } else {
                    Spacer()
                    Color.blue.frame(width: 100, height: 100)
                }
            }
            .padding()
        }
    }
}

The result looks like this:

As you can see using withAnimation around the state change gives us a nice fade by default.Now let's see what happens when we add @Namespace and matchedGeometryEffect:

struct MyView: View {
    @State var left = true
    @Namespace var namespace // 1) Add namespace

    var body: some View {
        VStack {
            Button("Toggle", action: { withAnimation { left.toggle() } })
            HStack {
                if left {
                    Color.red.frame(width: 100, height: 100)
                        .matchedGeometryEffect(id: "box", in: namespace) // 2) Add `matchedGeometryEffect` inside namespace
                    Spacer()

                } else {
                    Spacer()
                    Color.blue.frame(width: 100, height: 100)
                        .matchedGeometryEffect(id: "box", in: namespace) // 3) Same here, making sure they use the same `id`
                }
            }
            .padding()
        }
    }
}

SwiftUI now animates between these 2 different boxes seamlessly as though you were simply moving the same box.

Animating across Views

One thing that was not shown was how to perform animations like this across different views. For example what happens if we refactor our example like this:

struct MyView: View {
    @State var left = true

    var body: some View {
        VStack {
            Button("Toggle", action: { withAnimation { left.toggle() } })
            if left { LeftView() }
            else { RightView() }
        }
    }
}

struct LeftView: View {
    var body: some View {
        HStack {
            Color.red.frame(width: 100, height: 100)
            Spacer()
        }
        .padding()
    }
}
struct RightView: View {
    var body: some View {
        HStack {
            Spacer()
            Color.blue.frame(width: 100, height: 100)
        }
        .padding()
    }
}

Turns out integrating @Namespace and matchedGeometryEffect it's not immediately obvious, my first instinct was to just pass the @Namespace along like so:

struct MyView: View {
    @State var left = true
    @Namespace var namespace

    var body: some View {
        VStack {
            Button("Toggle", action: { withAnimation { left.toggle() } })
            if left { LeftView(namespace: _namespace) }
            else { RightView(namespace: _namespace) }
        }
    }
}

struct LeftView: View {
    @Namespace var namespace

    var body: some View {
        HStack {
            Color.red.frame(width: 100, height: 100)
                .matchedGeometryEffect(id: "box", in: namespace)
            Spacer()
        }
        .padding()
    }
}
struct RightView: View {
    @Namespace var namespace

    var body: some View {
        HStack {
            Spacer()
            Color.blue.frame(width: 100, height: 100)
                .matchedGeometryEffect(id: "box", in: namespace)
        }
        .padding()
    }
}

However this just resulted in the default fade animation...

The reason is @Namespace only has a single init() and it's wrappedValue is read-only.So by using the @Namespace property wrapper we are actually creating different instances in the left/right views rather than using the one we pass in.

However for this to work we still need to pass in the namespace since matchedGeometryEffect needs one. If we look at the namespace parameter of matchedGeometryEffect it actually wants a Namespace.ID which happens to be the wrappedValue from @Namespace. This means we should be able to just pass the Namespace.ID instead, let's try:

struct MyView: View {
    @State var left = true
    @Namespace var namespace

    var body: some View {
        VStack {
            Button("Toggle", action: { withAnimation { left.toggle() } })
            if left { LeftView(namespace: namespace) }
            else { RightView(namespace: namespace) }
        }
    }
}

struct LeftView: View {
    var namespace: Namespace.ID

    var body: some View {
        HStack {
            Color.red.frame(width: 100, height: 100)
                .matchedGeometryEffect(id: "box", in: namespace)
            Spacer()
        }
        .padding()
    }
}
struct RightView: View {
    var namespace: Namespace.ID

    var body: some View {
        HStack {
            Spacer()
            Color.blue.frame(width: 100, height: 100)
                .matchedGeometryEffect(id: "box", in: namespace)
        }
        .padding()
    }
}

Success!

Recap

Using these features you can create some fantastic interactions with very little code. The same interactions with UIKit would involve numerous additional types and fairly complex code to create the same transitions.

Remember that to 'link' elements with matchedGeometryEffect you need to:

• Ensure they are in the same Namespace by using the same instance.
• Ensure they have the same id.

And SwiftUI will take care of the rest!

Coordinators

You've likely all heard about, and possibly tried, Coordinators, a fantastic pattern by Soroush Khanlou. I used this pattern myself for a long time. It solved the problem of decoupling navigation from View Controllers so that they could potentially be reused under any number of different scenarios.

As I used this pattern more and more I would often feel some recurring, nagging, issues. I began to notice things like:

• I was never able to settle on a single abstraction that I liked to use the pattern across any application... there were always subtle differences.
• There was often state to manage with regard to adding and removing children as they execute ("sub" Coordinators).
• This often meant you needed to know when a child Coordinator would be finished so you could clean them up.

The more I thought about this I began to realize that each Coordinator not only managed a specific Container Controller but that it's behaviour ended up copying its Containers behaviour. It felt like I was reinventing something that already existed over and over. Navigation based Coordinators ended up mostly pushing things. Tab based Coordinators were mostly managing an array of child Coordinators.

I was essentially writing Coordinators to do the jobs that the UIKit Containers already do 🤔

Container Controllers as Coordinators

I decided to try subclassing Containers to act as Coordinators, and once I did something pretty cool happened...

• I no longer had to think about an abstraction: if I wanted a stack based Coordinator I simply subclassed UINavigationController. If I needed a tab based one I could subclass UITabBarController and load it up with my UINavigationController subclasses.
• The state for managing the 'graph' is gone as the subclasses deal with this by design. Now all they contain are the functions for moving between View Controllers or other Containers.
• I don't really care about when a flow is 'complete' anymore. When a ViewController is 'popped' from the stack, for example, it simply cleans itself up.

I now found I was able to build each Coordinator, in isolation, and not have to think about how it interacted with other Coordinators.

Consider a simple app with a couple of tabs. A tab with a list of friends and a tab with a list of messages between you and those friends. Let's look at what this might look like using Containers as Coordinators.

First we have our View Controllers for the lists of friends and messages:

class FriendListViewController: UITableViewController {
  //..
}
class MessageListViewController: UITableViewController {
  //..
}

We know that we will want stack based navigation for each tab so let's build our UINavigationController subclasses for each of them:

class FriendListNavigationController: UINavigationController {
  init() {
    super.init(nibName: nil, bundle: nil)

    let viewController = FriendListViewController()
    viewController.title = "Friends"
    setViewControllers([viewController], animated: false)
  }
}

class MessageListNavigationController: UINavigationController {
  init() {
    super.init(nibName: nil, bundle: nil)

    let viewController = MessageListViewController()
    viewController.title = "Messages"
    setViewControllers([viewController], animated: false)
  }
}

Finally let's create our UITabBarController subclass to manage these:

class HomeTabController: UITabBarController {
  init() {
    super.init(nibName: nil, bundle: nil)

    let users = FriendListNavigationController()
    users.tabBarItem = .init(title: "Users", image: nil, selectedImage: nil)

    let messages = MessageListNavigationController()
    messages.tabBarItem = .init(title: "Messages", image: nil, selectedImage: nil)

    setViewControllers([users, messages], animated: false)
  }
}

If we now compose all of these layers together at run time we end up with an application that looks something like:

Friends Tab	Messages Tab

Notice that the UINavigationController related properties like title are handled by the UINavigationController subclasses and the UITabBarController related properties like tabItem are handled by the UITabbarController subclasses. This further decouples the individual View Controllers from the context they are being shown in.

Now that we have decoupled the hierarchy, what about navigation?

The Responder Chain

Unless you have a lot of experience with building for macOS you may have never explicitly used the Responder Chain on iOS, except perhaps the becomeFirstResponder() function.

The Responder Chain is based on the class UIResponder. All the common UIKit objects you use inherit from this including UIViewController, UIView, UIWindow, and UIApplication. There are a lot of interesting members on this class but for our needs we are only interested in one:

open var next: UIResponder? { get }

Why is this one so interesting? Well, if all the items in our view hierarchy implement this it means we basically have a linked list. From any place in the hierarchy we can walk back up the Responder Chain all the way back to the UIApplicationDelegate.

By default, next will be:

• For UIViews, the superview or the UIViewController if it's the root view.
• For UIViewControllers, the containing/presenting view controller or the UIWindow if it's the root View Controller.
• For UIWindows, the UIApplication
• For UIApplications, the UIApplicationDelegate if it is a UIResponder

We can even alter the chain by overriding next in our subclasses if needed! This gives us an incredibly powerful mechanism, so how can we take advantage?

Tapping into UIResponder

Now we know what the Responder Chain is; how can we use it for navigation? Well it turns out that we can extend UIResponder with our own custom functions. We can then override these functions elsewhere to perform whatever action is required.

Knowing this, let's look at how we can navigate to a friend's details when a user taps one from the list. First let's add our UIResponder extension

extension UIResponder {
  @objc func selectedFriend(_ friend: Friend) {
    guard let next = next else {
      // This gives us a nice piece of diagnostic information in the event
      // this action travels along the chain and isn't handled by anything
      return print("⚠️ Unhandled action: \(#function), Last responder: \(self)")
    }

    next.selectedFriend(friend)
  }
}

This will expose a selectedFriend(_:) function to anything on the Responder Chain. Now that we have a way to send the message, let's do so from our friends list:

class FriendListViewController: UITableViewController {
  //..

  override func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
    selectedFriend(data[indexPath.row])
  }
}

Finally we need something to act on this message, so let's do that from our UINavigationController subclass:

class FriendListNavigationController: UINavigationController {
  //..

  override func selectedFriend(_ friend: Friend) {
    let viewController = FriendDetailsViewController(friend: friend)
    viewController.title = friend.name
    pushViewController(viewController, animated: true)
  }
}

And that's it! Our FriendListViewController sends a message out that a certain friend needs to be shown and nothing more. The message travels along the responder chain until it hits our UINavigationController subclass that contains the override. Our subclass then constructs the appropriate View Controller and pushes it on to the stack.

We have performed all the work of a Coordinator without re-inventing the wheel.

Reusing View Controllers

After putting in the work to decouple our View Controllers, how we can leverage this new pattern in our app? Let's look at how we might reuse our friends list to select a friend to use when creating a new message.

You can think of the Containers as the things that provide context or meaning to a View Controllers actions. Our existing FriendListNavigationController translates our selectedFriend action into showing a friends details on the current stack. The context here being the 'friends tab'.

For this feature we have a new context, so let's create a new Container to deal with it:

class NewMessageNavigationController: UINavigationController {
  init() {
    let viewController = FriendListViewController()
    viewController.title = "Select Recipient"
    setViewControllers([viewController], animated: false)
  }

  override func selectedFriend(_ friend: Friend) {
    let viewController = MessageComposerViewController(recipient: friend)
    viewController.title = friend.name
    setViewControllers([viewController], animated: true)
  }
}

So within this Container we start by showing the friends list, however this time when the user selects someone we will reset the stack to show the composer with the selected friend. We have used our existing friends list in a new context with very little code.

The only thing left to do is update our existing MessageListNavigationController Container to launch this new one:

class MessageListNavigationController: UINavigationController {
  init() {
    super.init(nibName: nil, bundle: nil)

    let viewController = MessageListViewController()
    viewController.title = "Messages"
    viewController.navigationItem.rightBarButtonItem = .init(title: "New", style: .plain, target: self, action: #selector(composeNewMessage))
    setViewControllers([viewController], animated: false)
  }

  //..

  @objc private func composeNewMessage() {
    let container = NewMessageNavigationController()
    present(container, animated: true, completion: nil)
  }
}

We have updated the existing Container to attach a navigation item that launches our new message composer Container. Notice that the View Controllers are still bissfully unaware of how they are being used. It is the Containers that contain the details about how they all come together.

Other interesting uses

There are a few other interesting things the Responder Chain allows us to do.

UIViews

The fact that smaller components like UIView are UIResponders means they can also participate in both sending and acting on our custom actions. A UITableViewCell subclass, for example, could call our selectedFriend action rather than the View Controller.

Error Handling

We could also use this as a way to unify error handling. For example you might consider an extension like:

extension UIResponder {
  @objc func handleError(_ error: Error) {
    guard let next = next else {
      return print("⚠️ Unhandled action: \(#function), Last responder: \(self)")
    }

    next.handleError(error)
  }
}

Using this you can propagate errors from anywhere in your hierarchy back to a single place, like your UIWindow. Remember, the UIWindow can be a custom subclass just like your other Containers. You can present a generic error alert from there by overriding handleError.

IBAction

You can also add @IBAction to your UIResponder extensions; doing this will allow you to call them with UIButton taps with no code at all.

Pay it forward!

Finally don't forget you are dealing with a linked list! Just because you override one of these custom actions doesn't mean you have to end the chain. You might want to update your UI based on the fact that an error occured but not mess with the default handling you have in your UIWindow i.e.:

class MyViewController: UIViewController {
  //..

  override func handleError(_ error: Error) {
    // do something with this controllers appearance

    next?.handleError(error) // pass the message along!
  }
}

Caveats

There are a few things you need to know if you would like to give this pattern a try.

Swift

This is an Objective-C mechanism (You may have noticed the @objc on our UIResponder extensions) and as such pure Swift code is not 'visible'. This means that, by default, you cannot pass along things like structs. To work around this we can box our Swift value in an Objective-C compatible object:

public class ResponderBox: NSObject {
  @nonobjc private let value: Any

  @nonobjc public init<T>(_ value: T) {
    self.value = value
    super.init()
  }

  @nonobjc public func value<T>(_: T.Type = T.self) -> T {
    guard let value = value as? T else {
      fatalError("Invalid value. Expected \(T.self), found \(type(of: self.value))")
    }

    return value
  }
}

The unfortunate downside is that you'll need two UIResponder functions to make this work, taking our selectedFriend example we would need to update it to be:

extension UIResponder {
  @objc func selectedFriend(_ friend: ResponderBox) {
    guard let next = next else {
      return print("⚠️ Unhandled action: \(#function), Last responder: \(self)")
    }

    next.selectedFriend(friend)
  }
  func selectedFriend(_ friend: Friend) {
    selectedFriend(.init(friend))
  }
}

For the objects sending the action nothing changes. They can still call selectedFriend(someFriendStruct). This function will then box up the struct and call out to the Objective-C compatible version.

For the objects wanting to act on this they would instead now override the ResponderBox version and extract the underlying struct with code like:

override func selectedFriend(_ friend: ResponderBox) {
  let friend: Friend = friend.value()

  // use friend struct
}

This is a small inconveience, however the good news is you can't really mess this up. For sending it doesn't matter if you accidentally called the ResponderBox version as they both result in the action being sent along the Responder Chain. As for the overrides, you can only override the ResponderBox version thanks to the @objc annotation. If you tried to override the struct version the compiler would give you an error.

Modals

In the same way I only move forward using the Containers, I also only move backwards using them. One of the rules I follow is that "the Container that presented something should also dismiss it". However iOS throws a spanner in that by default because regardless of what does the presenting, the window's rootViewController is the value returned by the presented items next value.

What this means in our example is; Our presented NewMessageNavigationController would return the HomeTabController as its next responder instead of the MessageListNavigationController that presented it.

Luckily we can work around this also using View Controller Containment:

class ResponderController: UIViewController {
  private let nextOverride: UIResponder
  private let child: UIViewController

  init(containing: UIViewController, nextResponder: UIResponder) {
    self.nextOverride = nextResponder
    self.child = containing
    super.init(nibName: nil, bundle: nil)
  }
  required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
  }

  override func viewDidLoad() {
    super.viewDidLoad()
    addChild(child)
    view.addSubview(child.view)

    child.view.frame = view.bounds
    child.view.autoresizingMask = [.flexibleWidth, .flexibleHeight]

    child.didMove(toParent: self)
  }
  override var next: UIResponder? {
    return nextOverride
  }
}

extension UIViewController {
    func presentModal(_ viewControllerToPresent: UIViewController, animated flag: Bool, completion: (() -> Void)? = nil) {
        let wrapper = ResponderController(containing: viewControllerToPresent, nextResponder: self)
        present(wrapper, animated: flag, completion: completion)
    }
}

By overriding next we can maintain a Responder Chain that matches how we actually construct the UI hierarchy. All you need to do is use presentModal(_:animated:completion:) instead of the usual present(_:animated:completion:) function.

Recap

If you made it this far you probably have the idea but just to recap the rules I like to use when working with this pattern:

• Only Containers perform transitions; this includes push/pop, present/dismiss.
• Containers configure properties on a View Controller relevant to their duties; this includes properties like title, navigationItems and tabBarItems

Much like the more common Coordinator pattern this certainly isn't a silver bullet. However I have had really good success using it a number of apps so I'd love to hear your feedback if you decide to try it. There are some quirks but overall I find it easier to lean into UIKit rather than try to fight it.

Why use Rx?

If so many people struggle with it why use it at all? A perfectly valid question.

In our profession, there are so many ways to solve a problem and Rx is no different. Rx has a steep learning curve and it often isn't clear if one way of solving something is better than another. Figuring the subtleties out will take time, but it is very rewarding when you do.

The reason I use Rx is that, in my opinion, its greatest strength lies in the ability to take inputs from many sources, tame the often complex logic needed to combine them and leave you with outputs that update whenever the inputs do.

What this means is that, if you are following principles like SRP, you often don't need Rx for the individual, lower level components, but its power becomes quite clear in higher level ones.

With that in mind, let's get started...

Use it sparingly

The most problematic Rx codebases I have worked on and heard people complain about are the ones that have made or tried to make every single part reactive. The more Rx you use the bigger and scarier your stack traces are. Stepping through a long reactive chain is hard and the .debug() operator only gets you so far.

As I alluded to earlier, my solution to this is only using Rx in the higher level components such as view models and view controllers.

But... how do we make all these non-Rx things work in Rx?

Wrap components in Rx

We can build components, such as an API layer, using more widely understood paradigms like closures to deliver things asynchronously. For example:

class APIClient {
    func perform<T: APIOperation>(_ operation: T, complete: @escaping (Result<T.Response>) -> Void) -> Cancellable {
        //use URLSession to perform request and attempt conversion of data to T.Response
    }
}

To make this work nicely with Rx we only need a few lines of code:

extension APIClient: ReactiveCompatible { }

extension Reactive where Base == APIClient {
    func perform<T: APIOperation>(_ operation: T) -> Observable<T.Response> {
        return .create { observer in
            let task = self.base.perform(operation) { result in
                switch result {
                case .success(let value):
                    observer.onNext(value)
                    observer.onCompleted()
                case .failure(let error):
                    observer.onError(error)
                }
            }
            return Disposables.create(with: task.cancel)
        }
    }
}

With this, our APIClient can now easily be used in Rx chains. So what is the benefit of doing it this way?

Debugging is now much easier, we can set breakpoints within our non-Rx code and step through without all the additional noise Rx adds to our stack traces. We can now also write tests using the standard XCTest frameworks. Finally, we have a much more portable component. There's nothing stopping us from using this same API layer in other apps that may not use Rx.

You don't need most traits

RxSwift provides a wide range of traits. Traits are wrappers around a standard Observable that provide additional semantics/behaviours. This might sound great, we want to leverage Swifts' type system after all right? It's quite common to see code using a Single rather than an Observable for the API layer example above.

The problem with these different traits is that they do not always compose well together. There are a number of custom extensions floating around to help translate between them. You can avoid jumping through all these hoops by simply sticking with a standard Observable. There's no downside to avoiding traits.

Keen-eyed readers will have spotted the "(most)" in the heading. There is an exception to this one! You 100% should be using RxCocoa traits like Driver when you expose values for your view to consume as well as ControlEvent or ControlProperty which you encounter when using properties like UIButton.rx.tap. This is because those traits are designed specifically to interact with your UI. They will ensure values are shared and that everything happens on the main thread.

Avoid subjects

There are a number of shifts you need to make in how you think about data when learning Rx. One of the biggest is learning to construct streams such that the values coming out of them are the result of combining and/or transforming the values being sent in. A simplistic way to think about streams is like a mapping function (A) -> B, or (A, B) -> C

Quite often when that shift has not yet been made you will see code that falls back on subjects to bridge the gap. Subjects are objects in Rx that are both input and output. They can be subscribed to but also incoming values to be sent to them.

Let's look at one such example of a view model for performing a search:

class SearchViewModel {
    // MARK: - Input
    let searchText = PublishSubject<String>()

    // MARK: - Output
    let results: Driver<[SearchResultViewModel]>
    let resultCount: Driver<String>

    init(searchService: SearchService) {
        let searchResults = searchText
            .throttle(0.3, scheduler: MainScheduler.instance)
            .distinctUntilChanged()
            .flatMapLatest { query in
                return searchService.search(query: query).catchErrorJustReturn([])
            }
            .asDriver(onErrorJustReturn: [])
            .startWith([])

        results = searchResults.map { results in
            return results.map { result in
                return SearchResultViewModel(searchResult: result)
            }
        }

        resultCount = searchResults.map { "\($0.count) result(s)" }
    }
}

On its own, this looks really quite straight forward. searchText receives some text and we use that to do our search. From that, we can define 2 other streams, one for our list of results and one for a string showing the count.

However, because searchText is both input and output we have accidentally introduced an additional output to our view model. There is no way for us to prevent something else from subscribing to searchText and executing other code. If this is something you need to do then you should either

• Subscribe directly to the underlying input source (i.e. the text field); or
• Create another explicit output for this behaviour

By not creating a clear separation between input and output it becomes harder to debug where values may be coming from. It's also harder to reason about what the inputs and outputs for your system actually are.

Now let's see how we might refactor the same view model to remove the use of subjects:

class SearchViewModel {
    struct Input {
        let searchText: Observable<String>
    }

    // MARK: - Output
    let results: Driver<[SearchResultViewModel]>
    let resultCount: Driver<String>

    init(searchService: SearchService, inputs: Input) {
        let searchResults = inputs.searchText
            .throttle(0.3, scheduler: MainScheduler.instance)
            .distinctUntilChanged()
            .flatMapLatest { query in
                return searchService.search(query: query).catchErrorJustReturn([])
            }
            .asDriver(onErrorJustReturn: [])
            .startWith([])

        results = searchResults.map { results in
            return results.map { result in
                return SearchResultViewModel(searchResult: result)
            }
        }

        resultCount = searchResults.map { "\($0.count) result(s)" }
    }
}

The changes here are incredibly subtle, we have required that the input is passed via the constructor. This change gives me more fine-grained control over what my inputs and outputs are. I now have a single starting point to search for bugs relating to both text coming in and search results going out.

It's worth noting that there are, of course, other ways you can go about removing/encapsulating the subjects.

Again, there are exceptions to this one too but I'm not going to go into that here… If you absolutely feel that you need to use subjects, at the very least ensure you are encapsulating them so they are not publicly exposed for any random code to interact with. I would, however, encourage you to try and avoid them if you can!

Limit DisposeBags to View Controllers

Another issue you will see before the shift I mentioned has been made is DisposeBags in places they don't belong. A DisposeBag is something that holds subscriptions. Subscriptions are what you get when you use functions like subscribe, drive or bind. These subscriptions are also where your apps side-effects are contained.

These subscriptions should be limited to your view controllers. Other components like view models should not contain subscriptions because they should not contain side-effects.

Interestingly enough, this problem is quite often seen when subjects are also being misused, as mentioned above. It is common to see subscriptions calling functions like onNext directly. This is a sign that your stream outputs are not being modelled as transformations of their inputs.

As with the others, there are rare exceptions to this one too. If, for some reason, a stream does not have an output you may need a single private subscription to ensure the stream is enabled. However, as with the other exceptions, do your best to avoid this situation.

Summary

So to quickly sum up the tips:

• Limit Rx to higher level components like view models and view controllers.
• Build lower level components without Rx then add Rx wrapper extensions.
• Limit yourself to Observable and Driver.
• Write your Rx without subjects as much as possible.
• DisposeBags really only belong in view controllers.

I would strongly suggest anyone who is new to Rx or is feeling overwhelmed by it to simplify their use with these tips. As you get more comfortable with Rx you will start to get a good sense of when and how these tips apply as well as when they don't.

{
    "identifier": "A13424B6",
    "name": "Robert C. Martin"
}

{
    "identifier": "A161F15C",
    "title": "Clean Code",
    "authorIdentifier": "A13424B6"
}

Swifts Codable features enable us to quickly create matching models:

struct Author: Codable {
    let identifier: String
    let name: String
}

struct Book: Codable {
    let identifier: String
    let title: String
    let authorIdentifier: String
}

Thanks to Codable this is all we have to do to get JSON mapping to type-safe models for free!

There are, however, a couple of subtle issues that could cause problems as we progress. The identifiers are defined as Strings. This isn't wrong but it could lead to a scenario like:

func allBooks(by authorIdentifier: String) -> [Book] {
    //.. lookup books by id
}

let bobsBooks = allBooks(by: "Robert C. Martin") // oops!

This would compile and although the call-site seems to read correctly it would never return anything because the function expects an authors identifier not their name. Let's look at a type we can use instead of String to improve the type-safety here.

Identifier

We can't change the fact that the server is sending us Strings but we can change how those strings are represented locally using a wrapper and phantom-types.

Usually when we define a generic type like Identifier we also use that T elsewhere in the type, something like let value: T. However when the T is only present as part of the declaration it is called a phantom type.

What's the point then? Why make something generic if we aren't using the type? Well we actually are using the type, just not in the usual way. Let's take a look:

struct Identifier<T> {
    let value: String
}

Updating our models to use this new type, they become:

struct Author: Codable {
    let identifier: Identifier<Author>
    let name: String
}

struct Book: Codable {
    let identifier: Identifier<Book>
    let title: String
    let authorIdentifier: Identifier<Author>
}

and our function now becomes:

func allBooks(by authorIdentifier: Identifier<Author>) -> [Book] {
    //.. lookup books by authorIdentifier.value
}

let bobsBooks = allBooks(by: "Robert C. Martin") // failure!! (the good kind)

We have now made it impossible to incorrectly pass a String. We must provide an Identifier instead otherwise it will not compile even though they are all still Strings underneath.

This is what makes phantom types so useful. In this instance we are adding type-safety to an ordinary String using a generic placeholder. We can now use Identifier for not only our Book and Author models but any other model with an identifier as well.

Codable support

There is a new problem our new Identifier has introduced. Codable, by default, uses the same structure as the type. This means the JSON representation of an identifier would be:

{"value": "A13424B6"}

This is wrong, we still want the JSON representation to be a String so it works seamlessly with our API. Let's fix the Codable behaviour:

extension Identifier: Codable {
    init(from decoder: Decoder) throws {
        self.value = try String(from: decoder)
    }
    func encode(to encoder: Encoder) throws {
        try value.encode(to: encoder)
    }
}

Now when we convert between the model and JSON it will be a regular String rather than a nested object.

Adding new data to the API

Listing books and authors is working really well. Now it's time to allow our users to submit new entries. The only problem is our API is responsible for determining the identifiers of new data so we want to send JSON containing everything but the object identifier.

There are different ways we could tackle this:

• We could maintain a separate model that excludes the identifier. This is tedious and fragile but perhaps we could leverage a codegen solution to help? This is a big dependency to add if you aren't already using one though.
• We could provide a dummy identifier and remove it from the JSON before sending it to our API. This isn't very nice though, using dummy values in production code seems like something just begging to break and/or corrupt things.

Since we are creating new types today let's look at another one that can be used to solve this problem.

Identified

What we need is a way to define two versions of our models. One with an identifier when data is sent down and one without an identifier when we send data up.

We can't use the type system to remove properties... but we can use it to add them.

struct Identified<T> {
    let identifier: Identifier<T>
    let value: T
}

Using this type we can remove the identifier property from our models.

struct Author: Codable {
    let name: String
}

struct Book: Codable {
    let title: String
    let authorIdentifier: Identifier<Author>
}

We can then define the two version of a model we need. When we are receiving books from the API we can use Identified for each instance. When we want to add a new book we simply use Book as-is.

Having a type like Identified gives us the flexibility we want without needing to maintain parallel models or hack out unwanted values before sending data.

Codable support

As with Identifier the default Codable behaviour for Identified would result in the wrong JSON:

{
    "identifier": "A13424B6",
    "value": {
        "name": "Robert C. Martin"
    }
}

We need to fix the Codable behaviour so everything is still flattened when in it's JSON form:

extension Identified: Codable where T: Codable {
    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: AnyCodingKey.self)

        self.identifier = try container.decode(Identifier<T>.self, forKey: AnyCodingKey(stringValue: "identifier")!)
        self.value = try T.init(from: decoder)
    }

    func encode(to encoder: Encoder) throws {
        var container = encoder.container(keyedBy: AnyCodingKey.self)

        try container.encode(identifier, forKey: AnyCodingKey(stringValue: "identifier")!)
        try value.encode(to: encoder)
    }
}

The AnyCodingKey type is used to allow us to dynamically decode certain parts of the data without needing all new types:

struct AnyCodingKey: CodingKey {
    var stringValue: String
    var intValue: Int?

    init?(intValue: Int) {
        self.intValue = intValue
        self.stringValue = "\(intValue)"
    }
    init?(stringValue: String) {
        self.intValue = nil
        self.stringValue = stringValue
    }
}

The end!

There are many ways to skin a cat, but hopefully this has shown a couple of interesting way to solve some common problems using wrapper types and some pretty nifty Swift features.

There are a lot of additions that can be made to improve the ergonomics of these types also such as:

• ExpressibleBy* conformance
• Supporting values other than String

But I'll leave these as an exercise for the reader 🤘

You can grab a playground with all the code here

If you have any feedback feel free to reach out!

One example might be that you have some additional data you want to add to your model that can only be created on device. There are a couple of options, you might have server/client representations of the model and convert one to the other. Alternatively you could just make the property optional.

The former may not be an option, if you have a large number of properties that can be painful to maintain for the sake of 1-2 client side differences. This makes the latter seem more desirable but it requires you make the type conform to Codable also... or does it?

Turns out you can actually skip certain properties, and you don't actually need to make them Codable at all!

Example

Lets say you have a User model that you will receive from your server, but you also have some ClientData that your app might want to add afterwards, but never get from, or send to, the server.

All you need to do is define a custom CodingKey which omits the properties you want left out of encoding and decoding and give it a default value, like so:

struct User: Codable {
   private enum CodingKeys: String, CodingKey {
      case id, name, age
   }

   let id: String
   var name: String
   var age: Int
   var clientData: ClientData? = nil
}

That's it!

You can now encode an instance of User and the clientData won't be part of the resulting Data. Conversely when you decode incoming data clientData will simply use the default value.

Pretty simple right? - it's generally a better idea to model your data as strictly as possible... for example if clientData is required then this may not be ideal - but its a handy trick when you need it.

Big thanks to Christina Moulton for teaching me this trick 🤘

The data I want to end up with looks something like:

struct User {
    let firstName: String
    let lastName: String
    let age: Int?
}

There are multiple ways to go about collecting this data, I could simply give each screen an optional property:

class FirstNameViewController: UIViewController {
    private var firstName: String?

    // ...
}

This would get the job done, but there are a few problems to overcome...

• What about the A/B testing? We would very quickly end up with our screens having a number of the same optional properties.
• How do we keep track of and consolidate all of these properties at the end?

An alternate approach would be to have a second version of our model with optional properties, such as:

struct PartialUser {
    let firstName: String?
    let lastName: String?
    let age: Int?
}

This is an improvement, we now have all the pieces in one place. We can create a User.init that accepts this model to produce a complete User instance for us:

extension User {
    init(from partial: PartialUser) {
        // ...
    }
}

However it comes with it own set of problems...

• We have to keep it in sync with the 'real' model
• This init can look a little messy having to deal with both required and optional properties
• What do we do when a required value is missing?

It's worth noting that neither of these solution scale well for other uses, there is a lot of associated boilerplate that we would need to replicate for each specific use case.

We could try to solve the scaling problem with a Dictionary... what about using [String: Any]? While this scales fine it's a step backwards in safety.

String keys are problematic, they are prone to typos and will easily fall out of sync. We could look at using a String enum but then we've re-introduced our scaling issue again!

On the value side Any strips all our type information and we would then have to cast values back top the desired types again anyway.

What we need is something that combines the last two attempts. It should scale like a dictionary but gives us the type safety of an explicit model.

Lets stick with the Dictionary for now. Can we improve on String keys? Turns out Swift KeyPaths are a great solution to this!

var partialUser: [PartialKeyPath<User>: Any] = [:]

By using a PartialKeyPath we are able to restrict the keys to only properties on User like so:

partialUser[\User.firstName] = "Ian"

This is great! Now if our User model changes this dictionary will scale perfectly with it. New properties will be available as they are added and changes to existing properties will cause the compiler to complain.

What about the pesky Any? Right now you could replace the String value "Ian" with something like an Int of 42 and it would still compile (though it will fail when you try and extract it). Is there a different type we can use here to fix that?

Sadly no...

But there is hope! Let's build a new type that will solve this problem and make this solution more generic (pun intended 😄)

Partial

Let's start by putting in the KeyPath based Dictionary we have already to keep track of our changes:

struct Partial<T> {
    private var data: [PartialKeyPath<T>: Any] = [:]

    //...
}

This gives us a generic type that we can now use with any type we want:

var partial = Partial<User>()

Next, we can use a generic function to ensure the dictionary is updated with the correct types:

mutating func update<U>(_ keyPath: KeyPath<T, U>, to newValue: U?) {
    data[keyPath] = newValue
}

We use a full KeyPath here so we can gain access to the generic type of the value of the property. This works because KeyPath is a subclass of PartialKeyPath. With this function we can now update the data using:

partial.update(\.firstName, to: "Ian")

And because we now have access to the properties type we can restrict the value being set. For instance we can no longer pass 42. It's also worth noting that we can pass nil to erase any stored value too! We now have a type safe, scalable, setter!

We can use these same features to also build out the getter:

func value<U>(for keyPath: KeyPath<T, U>) throws -> U {
    guard let value = data[keyPath] as? U else { throw Error.valueNotFound }
    return value
}

Here we are encapsulating the casting of Any to the desired type and adding error handling. We also add in an overload to allow us to deal with optionals in a consistent way.

Dragons! 🐉

I should point out that there is one potential gotcha with the current implementation... when you use update(_:to:) you are only associating a single KeyPath with a single value. What this means is that if you are working with data like:

struct Pet {
    let name: String
}
struct User {
    let name: String
    let pet: Pet
}

And you update the value like so:

var partial = Partial<User>()
partial.update(\.pet, to: Pet(name: "Rover"))

This only creates a pairing of the pet KeyPath and the Pet object, you cannot then extract the nested data using:

let petName = try partial.value(for: \.pet.name)

This will fail because the inner Dictionary does not have an entry for \.pet.name... only \.pet. You need to ensure you are first extracting the data using a KeyPath you have already used then accessing the data from that:

let pet = try partial.value(for: \.pet)
let petName = pet.name

To correct this we can add an overload for value(for:) that first extracts the stored property then allows us you use KeyPaths to dig further down:

func value<U, V>(for keyPath: KeyPath<T, U>, _ inner: KeyPath<U, V>) throws -> V {
    let root = try value(for: keyPath)
    return root[keyPath: inner]
}

Using this you could then do

let petName: String = try partial.value(for: \.pet, \.name)

This is great because once you have the 'root' object the inner KeyPath can dig down any number of nested levels.

Putting it all together

This is what our full Partial looks like. I've also added some overloads to better handle optionals too:

struct Partial<T> {
    enum Error: Swift.Error {
        case valueNotFound
    }

    private var data: [PartialKeyPath<T>: Any] = [:]

    mutating func update<U>(_ keyPath: KeyPath<T, U>, to newValue: U?) {
        data[keyPath] = newValue
    }
    mutating func update<U>(_ keyPath: KeyPath<T, U?>, to newValue: U?) {
        data[keyPath] = newValue
    }
    func value<U>(for keyPath: KeyPath<T, U>) throws -> U {
        guard let value = data[keyPath] as? U else { throw Error.valueNotFound }
        return value
    }
    func value<U>(for keyPath: KeyPath<T, U?>) -> U? {
        return data[keyPath] as? U
    }
    func value<U, V>(for keyPath: KeyPath<T, U>, _ inner: KeyPath<U, V>) throws -> V {
        let root = try value(for: keyPath)
        return root[keyPath: inner]
    }
    func value<U, V>(for keyPath: KeyPath<T, U?>, _ inner: KeyPath<U, V>) -> V? {
        guard let root = value(for: keyPath) else { return nil }
        return root[keyPath: inner]
    }
}

And we can now extend our original User model like so:

extension User {
    init(from partial: Partial<User>) throws {
        self.firstName = try partial.value(for: \.firstName)
        self.lastName = try partial.value(for: \.lastName)
        self.age = partial.value(for: \.age)
    }
}

Wrapping up

Sadly we are not able to provide a default implementation for the convenience init yet. I've explored a few ways of getting this to work however the core issue is that there is, currently, no way of converting to or from KeyPaths to other types.

It's a shame but regardless, I think this is an interesting use of KeyPaths. I also like the feel of this solution when compared to the other attempts because of the ability to exactly mirror the underlying model and the resulting compiler safety.

UPDATE: I forgot to mention that while there is no way to provide a default implementation for the convenience init you can of course use a tool like Sourcery to do this for you until KeyPaths get some love.

Let me know what you think!

Quick recap

There are a number of types that already conform to Codable out-of-the-box. At the time of writing these are: String, Int, Double, Date, Data and URL. The nice part about Codable is, if your type is made up of other Codables then you get Codable for free. So that means you can define types like:

struct User: Codable {
    let name: String
    let url: URL
}

and

enum AuthState: String, Codable {
    case loggedIn
    case loggedOut
}

And Codable just works - no extra code is required.

You can store AuthState for example with something like:

let state: AuthState = .loggedIn
let data = try JSONEncoder().encode(state)
data.write(to: configFile)

How great is that?!

Limitations

The enum is interesting. The reason this works is because we have given it a RawValue of String. Swift can use that to infer a String for each case and since String is Codable we get it for free, but what if we wanted to change the enum slightly?

enum AuthState: Codable {
    case loggedIn(User)
    case loggedOut
}

We decide its better to store the logged in user with the logged in state and since User is Codable this should just work too right?

Unfortunately this isn’t the case (no pun intended)… the enum is no longer RawRepresentable and since there is no RawValue anymore Swift doesn’t know how to encode/decode each case.

Manually implementing Codable

To make this change work we will need to implement Codable ourselves. Lets start by creating the CodingKeys the enum will use to provide a unique key for each case:

extension AuthState {
    private enum CodingKeys: String, CodingKey {
        case loggedIn, loggedOut
    }
}

Next, lets implement the Encodable part:

extension AuthState {
    func encode(to encoder: Encoder) throws {
        var container = encoder.container(keyedBy: CodingKeys.self)

        switch self {
        case .loggedIn(let user): try container.encode(user, forKey: .loggedIn)
        case .loggedOut:          try container.encode(CodingKeys.loggedOut.stringValue, forKey: .loggedOut)
        }
    }
}

You can see the Encodable part benefits from exhaustive switching, we encode cases with an associated value using their CodingKey as the ‘key’ and the associated value as the ‘value’. For cases without an associated value we use the CodingKey as both the ‘key’ and ‘value’.

Finally lets look at the Decodable code:

extension AuthState {
    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)

        if let user = try container.decodeIfPresent(User.self, forKey: .loggedIn) {
            self = .loggedIn(user)
        } else if let _ = try container.decodeIfPresent(String.self, forKey: .loggedOut) {
            self = .loggedOut
        } else {
            throw DecodingError.valueNotFound(AuthState.self, .init(codingPath: container.codingPath, debugDescription: ""))
        }
    }
}

For Decodable we unfortunately aren’t able to leverage exhaustive switching. So we need to attempt to decode each case one by one. For cases with an associated value this means attempting to decode the associated value for the key. For cases without associated values we attempt to decode the String value. Finally if nothing succeeds we throw a DecodingError.

This is perfectly fine and will work as-is, so we could just leave it here and be done. While the Encodable code is about as concise as we can make it this Decodable code is a little wordy.

Let's look at how we might clean this up a little.

Creating a reusable way to decode enums

If we look at the current solution to decoding its essentially the same as iterating through all possible cases attempting to decode the required data for each case. It stops as soon as a something is decoded, if nothing was decoded we throw an error.

Lets build something that uses that pattern:

typealias Decode<Result: Decodable, Key: CodingKey> = (KeyedDecodingContainer<Key>) throws -> Result?

func decode<Result: Decodable, Key>(using container: KeyedDecodingContainer<Key>, cases: [Decode<Result, Key>]) throws -> Result {
    guard let result = try cases.lazy.flatMap({ try $0(container) }).first
        else { throw DecodingError.valueNotFound(Result.self, .init(codingPath: container.codingPath, debugDescription: "")) }

    return result
}

This allows us to supply an array of closures, each one uses the container to attempt to decode the data for its specific case. Using this we end up with Decodable code that looks like this:

extension AuthState {
    init(from decoder: Decoder) throws {
        self = try decode(using: decoder.container(keyedBy: CodingKeys.self), cases: [
            { container in
                guard let value = try container.decodeIfPresent(User.self, forKey: .loggedIn) else { return nil }
                return .loggedIn(value)
            },
            { container in
                guard let _ = try container.decodeIfPresent(String.self, forKey: .loggedOut) else { return nil }
                return .loggedOut
            },
            ]
        )
    }
}

Now we have something that does the same thing as the original pattern, and while it now takes care of the error handling for us it doesn’t really read any better (in fact you could argue its actually worse 😭).

What we want to end up with is a function that fits our Decode signature. However because we need to provide more data we will need to create a curried function that eventually returns our Decode function.

The code we already have actually covers our two scenarios, so we can use them as the basis for our new curried functions.

Without associated values

Here is our function for dealing with cases without associated values. We are passing in the case we want, assuming decoding is successful, as well as the CodingKey it should be stored under.

func value<Result: Decodable, Key: CodingKey>(_ case: Result, for key: Key) throws -> Decode<Result, Key> {
    return { container in
        guard let _ = try container.decodeIfPresent(String.self, forKey: key) else { return nil }
        return `case`
    }
}

Now we can use the statement value(AuthState.loggedOut, for: .loggedOut) in place of the closure for this case.

With associated values

Handling cases with associated values lets us use one of Swifts many cool features. Cases with associated values behave like constructor functions and can be referenced the same way. An example should make this clearer:

// notice we have omitted the associated value for this case
AuthState.loggedIn // (User) -> AuthState

Well that is convenient, thats the exact function we need to infer all the extra details from the original closure!

func value<Result: Decodable, Key: CodingKey, T: Decodable>(_ function: @escaping (T) -> Result, for key: Key) throws -> Decode<Result, Key> {
    return { container in
        guard let value = try container.decodeIfPresent(T.self, forKey: key) else { return nil }
        return function(value)
    }
}

Now our associated value closure can be replaced with value(AuthState.loggedIn, for: .loggedIn).

Final Solution

Putting it all together re can rewrite our Decodable code:

extension AuthState {
    init(from decoder: Decoder) throws {
        self = try decode(using: decoder.container(keyedBy: CodingKeys.self), cases: [
            value(AuthState.loggedIn, for: .loggedIn),
            value(AuthState.loggedOut, for: .loggedOut),
            ]
        )
    }
}

I think that looks much nicer now.

Caveats

It’s worth noting that while this works great for local serialization it may not be in the format you need if you intend on sending this to a server. For instance our cases, when converted to json become:

.loggedIn(User(name: "Ian Keen", url: URL(string: "http://iankeen.tech/")!)) becomes:

{"loggedIn":{"name":"Ian Keen","url":"http://iankeen.tech/"}}

.loggedOut becomes:

{"loggedOut":"loggedOut"}

You may need to tweak the format a little to suit your server api requirements.

Wrapping up

Its a shame this doesn’t fit into the automagical Codable bucket, hopefully it is something we will get in the future. For now I think this is a decent solution for keeping this cleaner.

To see the full code checkout this playground.

Example

Lets look at a simple login screen:

Breaking down View and ViewController

Lets take a high level look at this screens functionality:

• Contains UI elements
• Lays out UI elements
• Performs Facebook login
• Performs Google login
• Toggles the loading indicator
• Toggles the email login input
• Toggles the keyboard
• Resizing based on the keyboard
• Performs email login

This is pretty standard list for a screen like this and its common to see all of this contained in the view controller. Over time having a controller handling all these responsibilities can make it harder to understand as well as harder to change.

Blurred lines

Our first step to separating our code is to figure out what belongs where. What we want to do is group the items in our list in terms of how the screen looks vs what the screen does. This defines our UIView and UIViewController respectively.

This can be harder than it sounds…

As we move through each item you may notice some don’t really fit completely in a single category. Lets look at a few:

• Toggling the loading indicator: This is made up of how that should look but it can show or hide based on what the screen does.
• Toggling the email login elements: This is a state transition so you might think to put that in the controller - however because it is a view state transition that doesn’t rely on any outside logic it should really live in the view in this instance. Remember, theres no reason a view can’t react to things like button taps!
• Dealing with the keyboard can be especially tricky since it exists outside the immediate view hierarchy. Just use your best judgement when it comes to elements like this.

Now that we’ve had a think about these things lets break our original items out further to create our new lists.

How it looks (UIView)

• Contains UI elements
• Appearance for social logins
• Appearance for email login
• Toggle appearance based on social/email state
• Animate the loading indicator in/out
• Show/hide keyboard

What it does (UIViewController) *

• Performs Facebook login
• Performs Google login
• Performs email login
• Show/hide loading indicator
• Resize when keyboard shows/hides

* NOTE: view controllers accept user input and trigger actions like logging in. However you should not put all the code that performs these actions there. Please use separate service objects in conjunction with this technique.

We can see that what this screen really does is much more than we originally thought. However now that we have a clearer separation of concerns we can break the original view controller down into a separate view and controller that handle their own, distinct, roles.

So once we have moved the view code into a custom UIView how do we bring that into a UIViewController?

Code UI

You have no doubt used a number of overrides in UIViewController . viewDidLoad, viewDidAppear etc.. however there is a lesser known override called loadView.

Custom Views

loadView allows you to insert a custom UIView that the UIViewController will use as its view simply by assigning it, for example:

override func loadView() {
    self.view = MyCustomView()
}

Accessing the custom view

How that our custom view is loaded we want typed access to it. The most straight forward way to do this is with a computed property:

var customView: MyCustomView { return view as! MyCustomView }

Now in your UIViewController you access the typed version of the view via the new customView property instead of self.view (the ! is safe here as we can guarantee view will always be MyCustomView)

Bonus

Here is a nice generic UIViewController subclass I like to use to simplify this pattern.

class ViewController<T: UIView>: UIViewController {
    // MARK: - View Separation
    var customView: T { return view as! T }

    // MARK: - Lifecycle
    override func loadView() {
        self.view = T()
    }
}

With this you can define your view controllers as:

class MyViewController: ViewController<MyView> {
   //you now get a `customView` property typed as `MyView` for free
}

Storyboard / Nib UI

The process for storyboards and nibs are the same.

Custom Views

Open the storyboard or nib, find your view controllers view in Interface Builders document outline.

In the identity inspector update the view class to the type of your custom view.

Accessing the custom view

As with the code based method, we will want typed access to our custom view. We use a computed property again however this time it will be an IBOutlet:

@IBOutlet private var customView: MyCustomView!

Finally we just need to hook the IBOutlet from the UIViewController to the custom UIView.

Results

So what have we achieved?

We have defined a clearer separation of concerns between a view and a controller. Now our view can focus solely on how a screen looks and the controller can focus on what a screen does.

This is a technique you can use regardless of whether you build your UIs with code, nibs or storyboards and it will work with any architecture or pattern.

Speaking of patterns… this one is called MVC 😄

You can download a project with an example of all three UI methods here

I have no specific plans for what is going to end up here - but hopefully others may find some of the content useful...

✌ see you soon