A new and refreshing look on app-architecture for apps in Swift (and Xcode) from the perspective of a UX-designer.
On the one hand it supports user flows which require users to go through several views to reach their goal. And on the other hand it combines modularity and reusability with the practicality of storyboards in Xcode.
Additionally, this way of structuring your code also allows you to communicate more effectively with the various types of members of a scrum-team, including the less technical members (because of the visual advantages of using storyboards), while at the same time preventing merge conflicts in Git when team members work on different features simultaneously.
This is the type of project that originated from a couple of completely unrelated things coming together. During my time at Noodlewerk, next to designing apps, I was also building them. Not having much experience developing native apps for iOS, I was trying to learn as much as possible about fulfilling the role of an iOS-developer. So I was not only learning a lot about Swift, but also about workflows, including Git and working together with others in an Agile way.
At that time I was working on Feed Me and I was right at the point that I needed to think about sustainable architecture for the app. I happened to be reading ‘Get Agile!’ by Pieter Jongerius et al (of Fabrique), and I came across this talk from Niels van Hoorn about Protocol Oriented Coordinators which was all about a way to provide structure in the code of a single view. It was the combination of these three things that made me come up with coordinating flows with protocols.
The reason behind the need for custom-made architecture can be traced back to the interaction qualities from the UX-vision; Feed Me needed to be guiding and have as little friction as possible.
For example, this resulted in the flow for child profile creation being divided into multiple views with only one question per view (as shown in the image above), making the cognitive load as low as possible. From a usability perspective this was the right way to go, but from a technical point of view it made things a bit more complex than preferred; with this strategy doing one thing (creating a profile for a child) has been divided over multiple views with multiple view controllers and, if I had used Niels’ Protocol Oriented Coordinators, multiple coordinators.
Instead of having one coordinator for each view, I devised a way to have one coordinator for one user flow, even when that flow has multiple views. By doing so, hierachically the different elements are related as shown in the scheme below. This also required me to create a lifecycle for such a coordinator with multiple options for the start and end of the lifecycle. If you are interested, I have distilled the logic of the coordinators into a separate Xcode-project.