Architecture on A+ programming moments

Interface Builder is declarative too. Where’s the love?

Sat, 02 Nov 2019 10:48:00 +0000

I’ve long been the proponent of using Interface Builder exclusively for the layout, in iOS apps. It always felt as the most natural way to build UI components: you tuck and nip stuff around while always having the result rendered in front of you. You can add any data you want, use any device size, test with CGSize.zero or .infinitum or whatever you want.

When you are working in IB, runtime is not involved and you need to think only about what data are getting in and how to present them. You describe the layout and let the framework render it in runtime based on that description / declaration.

This is the same thing that SwiftUI does. So why it seems that SwiftUI is more or less universally loved while IB was often ridiculed? I’ve come to conclusion is down to two factors.

Interface Builder is part of Xcode which is an IDE; a complex, multi-purpose programming tool that apart from allowing you to write your code, deals with a lot of other stuff you take for granted:

size and position of its windows
what files were open and where they were shown
last chosen scheme and target device/simulator
state of open panels and navigators
and dozens of other small bits of state
and dozens of other functionality and complexity you don’t (nor should) think about

IDEs try to save their own state very often, in order to prepare for eventual crash and restart (every single complex app will eventually crash). IB is one module inside Xcode but which, as visual layout builder, has a whole heap of its own state on top of Xcode’s already large pile.

The first hard knock against IB was decision by Xcode creators to save parts of that state inside .storyboard or .xib file. So every time you touch anything in IB canvas, you’ll more than likely drag it a bit and Xcode will helpfully save that change of its canvas state, behind the scene.

The position and even size of any view inside IB canvas area is utterly irrelevant change for the component itself but nonetheless it altered the file, which leads you to commit that change into git repository (or discard changes every minute or so). Which leads to merge conflicts if at least two developers in the team position the said component differently on their IB canvas. Which happens every damn time as some devs use 13in MacBook and others use 27in iMacs so they need to shuffle stuff around to make the best use of the available screen estate.

For the life of me, I can’t understand why IB canvas state is not saved somewhere in the .xcuserdata folder, which is already added to everyone’s .gitignore file. But it is what it is and that boat has sailed.

The second knock against Interface Builder is the whole storyboard nonsense. It’s the worst idea ever brought into the UIKit. Just look at any storyboard-based app and count the UISegue hacks required to pass data around. It’s not possible to declare the data instances you want to pass through the app. Not even in small apps, certainly not in more complex one. Apple’s recommended approach seems to be: use IB to connect UIViewControllers but then switch to code editor – an entirely different mental context – to write String-based glue code to prepareForSegue and what not. I dread to think how much developer time was spent chasing that pipe dream, inside and outside of Apple.

When you couple these two factors together, it’s not hard to realize why all the hate and ridicule. Shared app screens in storyboards means multiple developers working on same storyboard file, having constant merge conflicts throughout each working day. It’s a nightmare honestly; it’s perfectly understandable that large teams abandoned usage of storyboards as preached by Apple.

The sad part is that usually meant abandoning Interface Builder entirely and doing everything in code. Which then lead to writing Auto Layout constraints in code, which is a special type of masochism in my book. Which lead to people hating Auto Layout too, because making sense of constraints in code requires excruciating levels of mental effort.

Sane approach to using Interface Builder:

One UIVC per .storyboard file, to declare big-picture layout, usually to declare containers for minor, more specific components.
Instantiate those UIVCs in code and inject their data dependencies at that very moment, when you need them.
Each minor component’s layout is declared in its own .xib file.
Load instances of each component in code and populate the containers in the UIVC.

This approach lets you use Interface Builder only for what it does best: declare the layout of single self-contained pieces of UI. Then in code, you implement data flow and behavior. That’s it; look at SwiftUI and Instant Previews – when you strip away the hype, that is what remains.

As you then extend your app and add new features, existing xibs and storyboards are rarely touched. Hence less maintenance, easier testing and more productive developer teams.

coordinatingResponder with no Coordinators in sight

Thu, 10 Jan 2019 18:11:00 +0000

The best aspect of the Coordinator library is coordinatingResponder messaging (see the explanation in the README). Once you get used to it, it’s a pain to revert back to other techniques — all of them require more code than this. There’s really nothing clearer and simpler to output some data or continue user scenario than calling a method like accountLogin() from previous post.

All my UI code is already written with this in mind thus it’s only natural I want to apply that everywhere:

iOS apps – check! (of course)
tvOS apps – check!
watchOS apps – nope :s (for now) since there’s no UIKit
app extensions – yeah, che…ehm, not so fast.

While it seems possible to set anything you want as the value of NSExtensionPrincipalClass in extension’s Info.plist file, it turns out thât class must be subclass of UIViewController. During the extension’s loading process, UIKit is explicitly targeting UIViewController’s methods, it expects that .view is present etc.

Thus I can’t use Coordinator subclass as principal class for the extension. Why would I even want that?

I have already built a series of UIViewControllers that display content of incoming push notifications when received inside the app. They are controlled by a single Coordinator instance. I wanted to use all that code to display thât same content outside the app; say when you perform 3D Touch over the notification in Notification Center.

The app I’m working on has multiple push notification categories. To avoid building separate ContentExtension target for each category, I specify an array of category values (you can do that for UNNotificationExtensionCategory in extension’s Info.plist) and use just one target; then switch over the category value and load appropriate UIVC instance inside the Coordinator. Coordinator I have is already properly wired to read stuff the UI needs from shared Core Data, to call web service APIs etc.

All of that already works, inside the main app. Because of app extension limitation, I had to resort to custom container UIViewController which acts as Coordinator. Which lead me to this revelation, so obvious in hindsight:

you don’t need Coordinator to get the benefit of coordinatingResponder messaging

coordinatingResponder messaging already works with embedded child controllers regardless of UIVC being inside Coordinator or not. But if Coordinating protocol is not even present, this file from the library can’t be used as it is.

But this can:

public extension UIResponder {
	@objc public var coordinatingResponder: UIResponder? {
		return next
	}
}

extension UIViewController {
	override open var coordinatingResponder: UIResponder? {
		guard let parentController = self.parent else {
			guard let presentingController = self.presentingViewController else {
				return view.superview
			}
			return presentingController as UIResponder
		}
		return parentController as UIResponder
	}
}

That is all the code you need.

I will, of course, continue using Coordinators in my iOS/tvOS apps. They are really good tool to manage data flows without the UIViewController overhead.

But if for any reason you can’t or don’t want to use them, you can use just the code above to still get the main benefit of the library. I love flexible programming techniques like that.

Coordinator: the missing pattern in UIKit

Wed, 26 Dec 2018 15:11:00 +0000

I’ve been evangelizing the use of Coordinator pattern for last two years or so, to anyone that would listen. At the same time, I continually improved and used my open source Coordinator implementation in actual live apps, some of which are fairly complex. Main goal was to integrate it so firmly into UIKit that it feels not like 3rd party code but like it actually is UICoordinator.

Over time I realized the main hurdle for people is simply picturing why they need it and where does it fit into UIKit.

So my ask for today — give me 15-ish minutes of your time and read on.

Where does Coordinator pattern fits in the UIKit?

The two main building blocks of iOS app’ UIs are UIView and UIViewController.

UIView is the canvas, the tactile surface. It’s where your app presents stuff and it gets user (inter)actions back. Or it seems so, because that’s not really true: in iOS, apps do not have ownership of the screen. iOS runtime does.

Entire UIKit is built on this defining characteristic (from developer point of view): you neither control the input nor directly receive the output. You get UIWindow instance from the iOS and you add various UIView subclasses to it but they will actually be drawn and shown as iOS decides to do so. Not at the moment when you added them. Nor can you force them to be visible, since iOS can decide to replace parts or all of your window with something else (notifications, phone calls etc).

In the same vein, you will indirectly be notified that something happened on those views either through UIResponder methods and properties or by implementing various delegate protocols like UITextFieldDelegate, UITableViewDelegate etc. Or by employing target-action pattern of UIControl which is essentially the same thing — post-festum delivery of the results and actions that already happened.

So when you look at the whole data-input → display → interaction & output chain, you as developer only get access to certain links in that chain. The chain points are obvious in the input direction — you set properties and call methods. Output direction is a bit foggy — stuff reaches your chain links through UIResponder, which is parent class of both UIView and UIViewController. That fact alone, should give you a hint: UIViewController is an extension of UIView. It always has one associated UIView instance – if you remove that instance, UIVC is useless. It can’t exist and it can’t work and immediately crashes. Because of this, you can’t look into these two as separate entities. They are one.

UIViewController is part of the input chain for the UIView. It feeds data and/or other views into its .view. It is also part of the output chain since through UIViewController is how you get notified when was view loaded by iOS, when is about to appear, when it actually appeared etc.

Each pairing of UIViewController and UIView represent one UI unit in the overall UI of the app. One self-containing piece of UI.

Missing bit here is where the data is coming from. Is UIViewController fetching the data or is being given the data it should display? The onus here is entirely on the iOS developer: your UIViewController should never directly fetch data.¹ No network access, no data access (within the bounds of common sense).

UIViewController, in nutshell, is very clear and straight-forward implementation of MVC pattern: it is mediator between data of any kind and one UIView. It has two distinct roles:

receives data and configure / deliver it to the .view (or its subviews it knows about)
responds to / handles actions and events that occurred in the .view and/or its subviews
routes that response back into data storage or into some other UIViewController instance.

No, I did not make off-by-one error.

That 3rd item should not be there but it unfortunately is; in the form of show, showDetailViewController, performSegue, present & dismiss, navigationController, tabBarController etc. These methods and properties should never be found inside your UIViewController code.

That UIKit has thrown all that pile of navigation and routing responsibilities into UIViewController is its most serious architectural mis-step.

Content UIViewController instance should not care nor it should know about any other instance of UIVC or data sources, network, API etc.

Container UIViewController instance should know about its direct children UIVCs but it should ignore their .views.

UIVC instance should only care about having an input (data) and output (events and actions).

It does not care who/what sent that input.
It does not care who/what handles its output.

Coordinator is the missing piece here. It is an object that should handle all that outside stuff. It is an object which

instantiates UIVCs
feeds the input into them
receives the output from them

It order to do so, it also:

keeps references to any data sources in the app
implements data and UI flows it is responsible for

If you imagine your app’s UI as a house then each UIView/UIViewController pair is like one room in it: surface of the walls with paintings and cabinets and chairs and power plugs and light switches and anything else you may have visible in a room. Stuff you can interact with. Coordinators are the wiring and plumbings and (possibly) doors and windows – stuff that interconnect one room with other rooms in the house.

Why I think my Coordinator implementation is the best fit for UIKit apps?

Because I made it a subclass of UIResponder + minimally extended UIResponder and UIViewController in order to add some plumbing between UIViewController and Coordinator classes.

That same plumbing allows you to send a method call upwards through the output chain of UIView and UIViewController subclasses that is guaranteed to travel all the way up to the UIWindow and UIApplicationDelegate, which UIKit already does for some of its functionality.

When you call show(vc)² inside any UIViewController, it will magically bubble up to say UINavigationController container which will do push and execute its familiar slide from the right³ side. It’s irrelevant where UIVC which called show(vc) is located in the UI stack — is it direct child of UINC or is maybe embedded 3 levels deeper. It will bubble up all the way to UINC. This magic is sadly available only in UIViewControllers and for few of its methods like show and showDetailViewController.

So what I did is extended this super-power to UIView and my Coordinator class as well, by piggy-backing on UIResponder existing behavior and supplementing it so you can define any method you want and have it callable from anywhere in the UI stack.

Thus by declaring a method like this:

extension UIResponder {

@objc dynamic func accountLogin(username: String,
        password: String,
        onQueue queue: OperationQueue? = nil,
        sender: Any?,
        callback: @escaping (User?, Error?) -> Void)
{
    coordinatingResponder?.accountLogin(username: username,
        password: password,
        onQueue: queue,
        sender: sender,
        callback: callback)
}

}

you can

Call accountLogin() from anywhere: view controller, view, button’s event handler, table/collection view cell, UIAlertAction etc.
That call will be passed up the responder chain until it reaches some Coordinator instance which overrides that method. If none does, it gets to UIApplicationDelegate (which is the top UI point your app is given by iOS runtime) and nothing happens.
Through the callback closure, Coordinator can pass the results back down the chain.
At any point in this chain, not just the Coordinator, you can override this method, do whatever you want and continue the chain (or not, as you need).

There is no need for Delegate pattern (although nothing stops you from using one). No other pattern is required as well but you can use them if you wish / need to.

By reusing the essential component of UIKit design — the responder chain — any sort of data can travel up and down the coordinatingResponder chain. No downsides of any kind, only benefits.

Imagine a typical login scenario that some AccountCoordinator may implement:

Create an instance of LoginViewController and display it.
Receive username/password from LoginViewController through the mentioned accountLogin() method.
Send them to AccountManager which is some non-UI object keeping track what User is logged in.
If AccountManager returns an error, deliver that error back to LoginViewController
If AccountManager returns a valid User instance, replace LoginViewController with UserProfileViewController

In this scenario, LoginVC does not know that AccountManager exists nor it ever references it directly. It also does not know that AccountCoordinator nor UserProfileVC exist. It only cares about its input (optional AccountError instance) and internally managing few private UITextFields and UIButton and some UILabels.

AccountCoordinator does not care how LoginVC works. It has no idea about any controls inside it. It also has no idea what AccountManager does inside its login(user, pass, callback: ...) method. Is it using URLSession, accessing Core Data stack — it does not know nor it cares. It’s just plumbing, the conduit between input and output points of LoginVC and AccountManager.

AccountManager, for its part, does not care about neither LoginVC nor AccountCoordinator. It does not know they even exist. It has a method which takes two Strings and a callback argument which is a closure with User and AccountError as arguments. It does not care who calls that method and who is actually owning that closure it should execute.

Coordinator pattern is the missing piece in iOS SDK. It enables loose or no coupling at all between otherwise unrelated objects (like LoginVC and AccountManager).

Clear input + clear output for any data or UI layer in your app. When everything is so boxed-in, then it’s easy to maintain and unit test, is it not?

Give the Coordinator micro-library a fair try. It has decently complex demo app showcasing all that’s relevant.

I don’t even use it as CocoaPod although you can use it that way. It’s only 4 short Swift files (it’s heavily-commented) hence I usually just copy the Coordinator folder directly into my project.

It is useful in apps of any size but it truly shines in really large apps, with dozens and dozens of UIViewControllers, multiple back-ends and APIs. It’s perfect tool to handle deep linking to any screen in the app, route push notifications, Handoff requests and what not. I really wish it exists as part of UIKit.

Comments and questions and pull requests are welcome on GitHub or on Twitter.

This was the catalyst for my infamous rant from last year. ↩︎
Architectural problem I mentioned earlier with show(vc) method is not the method itself but that vc instance — the fact that you need to instantiate some other VC and populate its input data which means having access to that data in the first place. ↩︎
Trailing side, more precisely speaking. ↩︎

App Architecture, the book review

Tue, 29 May 2018 13:09:40 +0000

objc.io’s App Architecture,
by Chris Eidhoff, Matt Gallagher and Florian Kugler

I was waiting for an opportunity to dive into this book ever since Chris and Florian announced it months ago. I love their style of explanations. I’m a day-one subscriber to Swift Talk. I used the code and examples from their Code Data book for years. Plus having Matt Galagher was cherry on the top as I was reading Matt’s articles for a decade or so, since ObjC days. Hence…high expectations. 🙂

Topic of the book is near and dear to my heart in the last two years with pretty strong opinions.

···

Initial chapter which introduces and explains various architecture patterns is all talk, no code. It was rather dry to plow through and to be honest – I did not understand half of it. Unless you already know this stuff, it’s really hard to visualize and comprehend the concepts presented in bullet-point form.

Only when I got to the actual one architecture per chapter part I found examples of significant new concepts highlighted with code snippets. In hindsight, I believe that first chapter should have been the last since then it would be a summary of the concepts explained in the previous chapters. By then, you would already have much better grasp of the terminology and concepts behind them.

Another issue I have with the book is the big jump in complexity from MVC chapter to MVVM chapter. Not only is ViewModel introduced but also Coordinators and reactive programming with observables and subscribers and such. This is unfortunate since it clouds the benefits of introducing just ViewModel. Or just Coordinator.

After you get through all this, there is a chapter somewhat misleadingly titled “Implementing ViewModel without reactive programming” since it still uses Rx, only less so. Only after that one, there’s a sub-chapter which removes all of Rx and uses KVO-based bindings which is more akin to regular UIKit modus operandi. I think that if the order was reversed – by gradually introducing ViewModel, then Coordinator, then Rx – it would be easier to understand.

I’m teaching beginner iOS in Swift for the last several years and know first-hand that such big jumps can be highly discouraging for the students. This book is certainly not for the beginners – it targets experienced developers – but the issue is the same on any knowledge level.

MVC is the bread and butter of UIKit. All documentation and every beginner tutorial on the net is explaining MVC thus by the time you need a book like this you should know UIKit by heart. In other words – the first chapter should be entirely familiar to the reader. If, then, the second out of six architectures introduces so much new stuff, a reader may ask itself: ”jiminy, what awaits me further in the book..?”. And indeed a lot more awaits. I first thought I could go through this book in a day or two but it took me far more than that.

If you persevere though, you will be rewarded with rather good implementations of the same project in each architecture. To get the most out of the book I recommend to read the book on an iPad and look into the code on the Mac, so you can see the full context of the code and not just a snippet which could be put into the book.

Despite the critique so far, I recommend this book as required reading for developers tasked with implementing large apps with dozens and dozens of UIViewControllers. You will see all the pros and cons of each pattern over the fairly simple yet just complex enough app.

You’ll clearly see the differences in approach and – most importantly to me – magnitude of code size required for each. Which translates into magnitude of time spent to write and maintain said code.

Some additional commentary…

···

Networking chapter uses MVC as starting point to present how network-sourced data can be implemented

inside the UIViewController
inside the Model

The first approach should never be used in any kind of apps, no matter how simple it is. Authors pretty much concur, only say it more verbosely and less harshly. Networking code has no place inside the UI layer of an app, period.

The second one is more sensible but IMO still wrong. I recently spoke at NSBudapest about proper architectural design of the non-UI app parts (recording is from my Mac, while I stood in front of it thus the audio is a bit bad). Data model and transformations should be clearly separated from data sourcing and data delivery. This is all part of the general LAYERS architecture approach I promote and it’s a much larger topic.

···

Regarding conference-speaker-favorites – VIPER, Redux and their derivatives – book authors have this to say:

Attempts to bring “Clean Architecture” to Cocoa usually claim to manage “massive view controllers,” but ironically, do so by making the code base even larger.

👏🏻👍🏻

However, I would add that some of the architectures in the book also fall into this category; particularly TEA and MAVB. There is so much overhead added to each model/UI component that the cost of on-boarding new developers to a project using them is really, really high. Nothing in the UIKit and Apple’s documentation and guides prepares you for this. Thus I’m not sold on their practical use outside of academic curiosity.

It’s not that I believe that anything other than MVC is bad. It’s that architecture pattern alone is just part of the picture as the book authors readily accept (emphasis mine):

TEA is a pattern attributed to the Elm community, and it reportedly emerged naturally from the constraints of the language and the target environment.

Also this:

MVVM requires explicit framework support for the binding between the view and the view-model, whereas presenters traditionally propagate changes manually between the two.

(Hence the forced use of Rx to add such functionality into UIKit)

Then this:

TEA and other patterns with a declarative view layer suffer from the same problem: UIKit’s view state changes independent of your view state or model.

Etc.

Implicit design constraints of UIKit is what makes these architectures and frameworks non-starters for me. The best architecture for particular framework is the one that gives you the least amount of headache and requires the least overhead. As I said many times before –

if you need to fight or largely augment the framework to get what you want, it’s likely you chose the wrong framework (or platform)

I had some hopes for MVC+ViewState since I like the big picture idea but the sheer amount of code overhead gave me a headache. An architecture like that is applicable only to carefully designed system, top to bottom, front end to backend. In contracting world, where dev companies like mine are hired to write a front-end using dozen of incompatible systems that somehow need to work together, maintaining such a large state graph would drive anyone insane.

Just look at the ViewStateStore.swift in MVC+VS project and imagine something like this being maintained for an app with 6 APIs, 11 Coordinators and 100+ View Controllers where some screens have 10+ UIVCs embedded into one scene. Where at any moment there are half a dozen of (somewhat) parallel asynchronous actions being performed. No freaking way until Apple adds support for ViewState to all UIKit components (which I can’t see happening).

Again – I am very grateful this book exists. It helped to clear out any lingering doubts I had about my chosen approach. It further solidified my belief that MVC (with Coordinators) is the best architecture for UIKit apps. I understand the benefits of the more esoteric architectures but each comes with an increasingly steeper cost of code size and complexity. If you’re single developer or a team of 3-5 people – using those other architectures will drag you down for no good reason. If you have a larger team, then by all means: go for it if you want. Honestly though, even with 100 developers I would say that MVC-C or MVVM-C (without Rx Swift) is still the better choice.

Build tabs-based UI using Coordinators

Sun, 18 Feb 2018 16:39:40 +0000

UITabBarController is one of the staples of UIKit. Available since the beginning in the Phone and iTunes apps, among other ones. Thus every iPhone customer knows how to use them and what to expect from them.

The essential characteristics:

each tab is a world of its own
each tab can have a navigation controller inside
entirely separate from navigation controllers inside other tabs
when switching back and forth, tab content keeps its place

This is one of those system components that was built because Apple devs needed them way back and never really got improved. Using them got significantly worse with the introduction of UIViewController transitions in iOS 7 and their API which uses fromViewController and toViewController. Trouble here is that you usually want transition from one content controller to another, but fromVC and toVC returned are actually the container controllers, like NC and TC. So you need to hunt down into the hierarchy to find what you are actually working with.

Tabs were the worst here, since you have content VC inside NC inside TC. I never liked this and over time abandoned use of tab-based apps. Since discovering Coordinators, I realized I can actually replicate the tabs with

just one single instance of UINavigationController and
keeping content VCs for each tab into separate Coordinators
using coordinatingResponder messages to switch tabs

Here’s how to do it.

Fair warning: understanding this article requires good knowledge of how Coordinator library works and is used.

Tabs

First – you need to subclass UINavigationController which is fairly easy and painless to do, despite Apple’s warnings that it’s not designed for that.

The reason to subclass is so you can add the tabs. Simplest way (for me) is with UICollectionView but implement them any way you want. But you need to do this in code, since IB does not even shows the .view of the NC component.

final class NavigationController: UINavigationController {
	static var tabsBaseHeight: CGFloat = 64

	private weak var tabsCollectionView: UICollectionView!
}

You’ll need the data source for the tabs:

	private lazy var tabs: [Tab] = setupDataSource()

In viewDidLoad – or loadView if you like living on the edge – create the tabs CV and register the corresponding cell:

override func viewDidLoad() {
	super.viewDidLoad()

	addTabs()
	tabsCollectionView.register(TabCell.self)
	tabsCollectionView.dataSource = self
	tabsCollectionView.delegate = self
}

TabCell is anything you want it to be. Just an image, icon + text, only text etc.

addTabs is fairly large method, which is why I always recommend to extract it out from viewDidLoad:

func addTabs() {
	let layout = TabLayout()
	let cv = UICollectionView(frame: .zero, collectionViewLayout: layout)
	cv.translatesAutoresizingMaskIntoConstraints = false
	if #available(iOS 11.0, *) {
		cv.contentInsetAdjustmentBehavior = .never
	} else {
		self.automaticallyAdjustsScrollViewInsets = false
	}

	view.addSubview(cv)
	cv.heightAnchor.constraint(equalToConstant: NavigationController.tabsBaseHeight).isActive = true
	cv.leadingAnchor.constraint(equalTo: view.leadingAnchor).isActive = true
	cv.trailingAnchor.constraint(equalTo: view.trailingAnchor).isActive = true
	cv.bottomAnchor.constraint(equalTo: view.bottomAnchor).isActive = true

	tabsCollectionView = cv

	cv.backgroundColor = .clear
	cv.backgroundView = {
		let e = UIBlurEffect(style: UIBlurEffectStyle.extraLight)
		let v = UIVisualEffectView(effect: e)
		v.isUserInteractionEnabled = false
		return v
	}()
}

As an added bonus, notice how I replicated the default system blur behavior, behind the tabs. Pro-tip and a task: you’ll need to account for iPhone X’ safeAreaInsets here, at the bottom.

TabLayout is the simplest possible subclass of horizontal UICollectionViewFlowLayout.

Tap on a cell in the CV will initiate the tab/content change:

extension NavigationController: UICollectionViewDelegate {
	func collectionView(_ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath) {
		let t = tabs[indexPath.item]
		tabTapped(t.id, onQueue: .main, sender: self)
}

More on what’s tabTapped(...) in a minute. We need to build the tab content first.

Coordinators

If you are familiar with Coordinator-based architecture, you’ll know it always starts from ApplicationCoordinator, which spawns any other coordinator. The root VC here is usually UINavigationController…or its subclass. ;)

Thus using my Coordinator library:

final class AppCoordinator: NavigationCoordinator {

	init(rootViewController: NavigationController?) {
		super.init(rootViewController: rootViewController)
	}

	private var navigationController: NavigationController {
		return rootViewController as! NavigationController
	}

}

Let’s imagine this app is a shopping app, like in my Coordinator example app. Tabs can be modeled (inside ApplicationCoordinator) like this:

	enum Section {
		case sales
		case catalog
		case cart
		case account
		case popup
	}

	///	Currently active (shown) Coordinator
	var section: Section = .catalog

Each of these sections == one Coordinator of the same name and each will also be a subclass of NavigationCoordinator. This is the key since:

each Coordinator will re-use the ApplicationCoordinator’s rootViewController (which is our subclass of UINC)
NavigationCoordinator naturally keeps the viewControllers array of content VCs it created
when it’s brought up it will replace whatever is currently shown in rootVC with that array

The last bit is what replicates the illusion of tabs keeping their content and context. UINC is just a vehicle to show the content VCs, they are actually kept around by NavigationCoordinator.

So how do you perform this switch of viewControllers from one Coordinator to another? Using coordinatingResponder, of course.

coordinatingResponder messaging

Declare and implement the default message behavior:

extension UIResponder {

	@objc dynamic func tabTapped(_ tabID: String, onQueue queue: OperationQueue, sender: Any?) {
		coordinatingResponder?.tabTapped(tabID, onQueue: queue, sender: sender)
	}
}

Then on ApplicationCoordinator implement the switching:

override func tabTapped(_ tabID: String, sender: Any?) {

	switch tabID {
	case Tab.IDSales:
		setupActiveSection(.sales)
	case Tab.IDCatalog:
		setupActiveSection( .catalog )
	case Tab.IDCart:
		setupActiveSection( .cart )
	case Tab.IDAccount:
		setupActiveSection( .account )
	default:
		break
	}
}

setupActiveSection() is pretty app-specific but its general purpose is two-fold:

load or re-activate appropriate coordinator
update local section property

What it does not do in this case: it’s not stopping the already active Coordinator, which stays in memory kept by childCoordinators property. Hence all its viewControllers also stay in memory.

The first task is the interesting one. Here’s possible implementation for the Catalog section:

func showCatalog(_ page: CatalogCoordinator.Page? = nil) {
	let identifier = String(describing: CatalogCoordinator.self)

	//	if Coordinator is already created...
	if let c = childCoordinators[identifier] as? CatalogCoordinator {
		c.dependencies = dependencies
		//	restore all the viewControllers
		c.activate()
		//	then just display new page
		if let page = page {
			c.display(page: page)
		}
		return
	}

	//	otherwise, create the coordinator
	let c = CatalogCoordinator(rootViewController: rootViewController)
	//	populate dependencies
	c.dependencies = dependencies
	//	setup first Page (content VC) to show
	if let page = page {
		c.page = page
	}
	//	start it
	startChild(coordinator: c, completion: {})
}

Here’s what activate() method on the NavigationCoordinator is doing:

	open override func activate() {
		super.activate() // rootViewController.parentCoordinator = self

		rootViewController.delegate = self
		rootViewController.viewControllers = viewControllers
	}

As you can see, it takes over the ownership of the NC and installs its own set of content VCs. Thus by simply calling showCatalog(), showCart(), showAccount() etc – you can easily switch between the tabs.

There are few more details here I skipped, like making sure that proper tab is visually selected. But they are minor implementation detail.

Pay attention that CatalogCoordinator’s root VC is the same NavigationController instance already created on ApplicationCoordinator. Thus entire app is using just one single UINavigationController instance. You can’t get simpler view hierarchy than this.

If you also make that instance the UIViewControllerTransitioningDelegate…well, just imagine the possibilities. :)

Much ado about iOS app architecture

Sun, 05 Nov 2017 16:09:40 +0000

I started as indie developer in 2008, making fairly simple apps with just several screens in them so I did not need to think much about app architecture and was happy to use MVC as Apple recommends. In last two years, I did multiple large scale projects, big apps with dozens and dozens of more or less interconnected parts. This naturally led me to research the topic of architecture quite a bit.

Cocoa Touch is (I suspect) deliberately very simple: there’s Target-Action pattern, Dependency Injection, Delegate and MVC. That’s about it, really. Apparently it’s way too simple for some.

Of those patterns, MVC is most visible; it used to be the only kid on the UI block when the platform was simpler; that block became very crowded with acronyms like MVP, MVVM, VIPER, Redux, Cake and specialized roles with names like Router, Presenter etc, unidirectional this and that…

Most of these have truly noble goals, on paper. They aim to cleanly separate data model, model-view communication, view itself and also the controller that connects the view and the model. They aim to turn the views into declarative API where you puzzle the pieces and the rest of the app follows along.

Diving deeper and deeper into all this I increasingly felt that people are over-complicating what UIKit has to offer — an API proven to work and perform well on its target platform. People were not trying to improve UIKit, they were actively fighting against it.

Why does every single article, describing any of these new architectures, starts with a variant “Apple’s (sic!) MVC leads to a bloated M(assive)VC”.

🙄

When I read that, I see: here’s another wannabe who never bothered to learn how to properly Delegate. Who never learned to use container controllers and compartmentalize functionality into embedded controllers.

PSA: No one is forcing you to implement multiple DataSources in one Controller. To initiate network calls in viewDidLoad. To parse JSONs in UIViewController. To hard-wire Views with Singleton instances.

If you do that, it’s your fault; don’t blame MVC.

…

This pisses me off a lot lately, since I’ve already seen it.

I spent my first 15 professional dev years in front-end web development. I witnessed how simple, declarative world of HTML/CSS and original baby Javascript morphed over the years into increasingly complicated quagmire of “advanced something” until most front-end developers forgot how CSS selector specificity work. How property value inheritance works. Developers couldn’t be bothered to learn it because apparently they can’t do shit without variables.

I can’t shake the feeling these same kind of Javascript architects descended into iOS in full force and with them brought the habits of creating new amazing · best · evar library every few months.

Or maybe they are J2EE devs. It would be a crime to paraphrase that comment thus I’m simply going to quote it (emphasis mine):

No. VIPER is what happens when former enterprise Java programmers invade the iOS world. It imposes so much abstraction and structure that maintainability of code is reduced, not improved. I mean, honestly, can anyone really look at this and think, “yes, all these extra classes and protocols really improve my ability to reason through this code”?

Just look at the section starting with “Implement Expiration Date Business Logic in the Interactor”. The following protocols and classes are involved in reading a date out of a UIDatePicker and displaying it in a UITextField:

CreateOrder_FormatExpirationDate_Request
CreateOrder_FormatExpirationDate_Response
CreateOrder_FormatExpirationDate_ViewModel
CreateOrderInteractorInput
CreateOrderInteractorOutput
CreateOrderInteractor
CreateOrderPresenterInput
CreateOrderPresenterOutput
CreateOrderPresenter
CreateOrderViewControllerInput
CreateOrderViewController

For the love of god, why?! Does no one remember how Java’s Spring Framework ended up with AbstractSingletonProxyFactoryBean? That way lies madness.

(I deeply bow, n0damage.)

So much wasted effort to present new approaches as better alternative to UIKit, while building on top of UIKit.

Rules of engagement for maintainable projects

Let’s turn the mood of this post into some positive action. Here’s something I learned while working on half a dozen “enterprise”-level apps.

(picked up from Reddit)

1. Write as little code as possible

This is funny but also true - strive to write as less code as possible. Really is that simple.

If you make this your no.1 rule, things become very, very easy to decide. Many chiq new architecture approaches fall flat when faced with this rule.

2. Don’t fight the SDK / tools

Use patterns that iOS frameworks – especially UIKit – are already based on.
MVC, Delegate, Dependency Injection, Target / Action
Extend MVC with Coordinators and coordinatingResponder methods to handle data flow
This lets UIVCs have just one job to do.

On the topic of tools:

Writing UI in code violates the rule 1
Use .storyboard / .xib for the UI as much as possible. Do not write UI in code unless really, really, really necessary.
Do not use storyboards for data flow. Use them as glorified .xib, housing one or two View Controllers.

3. Don’t replace system frameworks

Use frameworks that Apple made, don’t augment nor replace them unless absolutely necessary.

One example: if there’s one thing iOS community does not lack are attempts to rewrite or even entirely replace Auto Layout. While I am fascinated by these libraries and learn a ton looking at that code, I would never used them in any serious personal app and absolutely never in client project.

I consider Auto Layout one of the top 5, maybe top 3 technologies to ever come out of Apple. It’s beautiful, easy to work with and there’s nothing I can’t do with it. It’s Apple’s choice for UI layout and you should master it, not avoid it.

Let’s not repeat the CSS mistake from 10 years ago.

4. Lean on Swift expressivity

Extract away the implementation details as much as possible, to keep the code DRY as much as possible. Swift is wonderfully expressive, use that to your advantage.

But mind the rules no. 2 and 3: I’ve seen some fascinating Swift code which almost entirely rewrites how essential components like UITableView and UICollectionView are fed and controlled. To the point of needing to re-learn how to work with those components.

If you do that, you are increasing the steepness of the knowledge curve for new team members, increase time to explain how app works, add yourself (needless?) tasks each June when Apple adds new fancy abilities on top of those system components.

5. Use as little 3rd party dependencies as possible

Swift is powerful and extensible, but you can’t always avoid using a 3rd party open-source library. My most recent projects use just a handful of 3rd party libs, each with very specific purpose.

The ones I use the most are wrappers around low level C-based system frameworks: Crypto, Keychain.
Then also those that help with tedious and error prone tasks, like JSON parsing where I currently prefer Marshal but will see what Swift 4’s Codable brings along.
Then there’s TinyConstraints, the tiniest possible helper for Auto Layout in code, for very rare cases I need to do that.

6. Use consistent code formatting

...one style to rule them all.

Always place the code elements at the same place
Use the same order
MARK:-up consistently and liberally

Order of stuff in my UIVCs:

Delegates
Init / deinit
UI outlets
Dependencies (if any)
Local data source
Embedded Controllers (if any)
Notification tokens
Commented-out list of coordinatorResponder methods that particular file is overriding
Any additional stuff

If I can’t figure out all the inputs just by scanning the top of the file, it’s not good.

When in doubt

Q: Should I write clever or obvious code?

A: Always be obvious!

URLSession and Operation, sitting in a tree

Tue, 31 Oct 2017 10:49:40 +0000

I don’t choose lightly to go against Apple recommendations on how to use their frameworks thus I spent quite a bit of time pondering the conundrum explained in the last post.

Let me try to paint a picture of the problem…

On one hand I have this chain of values where || indicates that URLSessionDataTask is private property populated with value created inside Operation.

APIwrapper
	⤷ URLSession
	⤷ OperationQueue
			⤷ Operation
					⤷ NetworkPayload
					⤷ URLSession, |URLSessionDataTask|

On the other hand, I have URLSessionDelegate working like this:

APIwrapper                ↰
⇣	⤷ URLSession            ⇡
⇣		⤷ URLSessionDelegate ⤴︎
⇣						⇣
⤷		func urlSession(..., dataTask: URLSessionDataTask...)

This one instance of URLSession is kept on API client wrapper, it’s passed into each Operation but all the data I get through it are received in a completely different chain of objects.

The only unique bridge between the delegate callbacks chain and the Operation is the URLSessionDataTask instance. It’s the very same instance in both chains. Thus I need to use it as bridge: take the data received in the URLSessionDelegate callbacks and attach them to the Task instance there; later read them inside the Operation.

This is what I end up with:

Extend URLSessionTask with a bunch of closure properties
Closures are set inside the Operation, so they have access to its scope and thus to NetworkPayload
Those closures will receive input from URLSessionDelegate callbacks, passing in the received data

Again and again, I am very, very grateful to whoever added associated objects to Objective-C runtime, since it allows me to overcome Swift’s (current) inability to declare stored properties in type extension:

extension URLSessionTask {
	public typealias NetworkTaskErrorCallback = (NetworkError) -> Void
	...

	private struct AssociatedKeys {
		static var error 	= "Error"
		...
	}

	public var errorCallback: NetworkTaskErrorCallback {
		get {
			return objc_getAssociatedObject(self, &AssociatedKeys.error) as? NetworkTaskErrorCallback ?? {_ in}
		}
		set {
			objc_setAssociatedObject(self, &AssociatedKeys.error, newValue, .OBJC_ASSOCIATION_RETAIN)
		}
	}

	...
}

Thus inside NetworkOperation I will declare the closure(s):

func setupCallbacks() {
	guard let task = task else { return }

	task.errorCallback = {
		[weak self] error in
		self?.payload.error = error
		self?.finish()
	}
	...
}

and execute them from the appropriate URLSessionDelegate callback:

final func urlSession(_ session: URLSession,
					  task: URLSessionTask,
					  didCompleteWithError error: Swift.Error?) {
	guard 
		let dataTask = task as? URLSessionDataTask 
	else { return }

	if let e = error {
		dataTask.errorCallback( .urlError(e as? URLError) )
		return
	}
	dataTask.finishCallback()
}

I now have a fully working solution that allows me to use Operations for network requests, while still adhering to Apple’s recommendations of (generally) using one URLSession per app.

Thoughts on URLSession architecture

Thu, 19 Oct 2017 23:09:40 +0000

In my talk / post about LAYERS architecture I specifically pointed out how I deal with networking: I have downgraded it to pure, self-contained one-off utility.

In short – I have an Operation subclass which receives URLRequest + URLSessionConfiguration as input, creates an instance of URLSession inside the Op, execute the request and it all goes away once result is delivered. Each network request gets its own URLSession, 1 to 1.

This turned out to be the most controversial part; I received few direct and a bit more indirect feedback about this. Using URLSession in such a way is exactly what Apple recommends not to do (jump to ~ 32:40):

I know this and for the longest time I was going with one URLSession story in all my apps. Heck, it was trivial to update my current networking micro-library to allow such usage.

On the other hand, I do like Operations a lot. They give me so much flexibility, especially when I need to temporary pause the stream of requests to either fetch some session cookie or new OAuth access token. While that’s ongoing, all the incoming requests can easily be queued-up in the OperationQueue and later authenticated as needed.

Here’s the rub: the intricate way URLSession / URLSessionDataTask API is designed does not work well with Operations. That’s not obvious if you use the most popular form:

let task = localURLSession.dataTask(with: urlRequest, completionHandler: {
	[weak self] data, response, error in
	...
})

because that can be wrapped into Operation, very easily.

With huge caveat: it works as long as you don’t need to handle any sort of AuthenticationChallenge, say if your development API server is using self-signed SSL certificate. In which case completionHandler form is useless since you need to use URLSessionDelegate form:

let localURLSession = URLSession(configuration: urlSessionConfiguration, delegate: self, delegateQueue: nil)

let task = localURLSession.dataTask(with: urlRequest)

in order to handle the challenge. The very next slide in the same talk from WWDC17 mentions that particular fact:

Look at the last part: URLSession will still make authentication-related delegate callbacks even if you use completionHandler form for the DataTask. It does do that but it’s totally useless, because no matter what you do in the delegate callback, your completionHandler will always receive the same result, this SSL error:

Printing description of e._userInfo:
{
    NSErrorClientCertificateStateKey = 0;
    NSErrorFailingURLKey = "https://HOST/PATH";
    NSErrorFailingURLStringKey = "https://HOST/PATH";
    NSErrorPeerCertificateChainKey =     (
        "<cert(0x7fcbb48c1000) s: *.OTHERHOST.com i: RapidSSL SHA256 CA - G2>",
        "<cert(0x7fcbb48c1800) s: RapidSSL SHA256 CA - G2 i: GeoTrust Primary Certification Authority - G3>",
        "<cert(0x7fcbb48bd000) s: GeoTrust Primary Certification Authority - G3 i: GeoTrust Primary Certification Authority - G3>"
    );
    NSLocalizedDescription = "An SSL error has occurred and a secure connection to the server cannot be made.";
    NSLocalizedRecoverySuggestion = "Would you like to connect to the server anyway?";
    NSURLErrorFailingURLPeerTrustErrorKey = "<SecTrustRef: 0x608000109b40>";
    NSUnderlyingError = "Error Domain=kCFErrorDomainCFNetwork Code=-1200 \"(null)\" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, kCFStreamPropertySSLPeerTrust=<SecTrustRef: 0x608000109b40>, _kCFNetworkCFStreamSSLErrorOriginalValue=-9802, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9802, kCFStreamPropertySSLPeerCertificates=(\n    \"<cert(0x7fcbb48c1000) s: *.OTHERHOST.com i: RapidSSL SHA256 CA - G2>\",\n    \"<cert(0x7fcbb48c1800) s: RapidSSL SHA256 CA - G2 i: GeoTrust Primary Certification Authority - G3>\",\n    \"<cert(0x7fcbb48bd000) s: GeoTrust Primary Certification Authority - G3 i: GeoTrust Primary Certification Authority - G3>\"\n)}";
    "_kCFStreamErrorCodeKey" = "-9802";
    "_kCFStreamErrorDomainKey" = 3;
}

If I do this in the callback:

func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {

	if challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust {
		let trust = challenge.protectionSpace.serverTrust!
		let host = challenge.protectionSpace.host
		guard session.serverTrustPolicy.evaluate(trust, forHost: host) else {
			completionHandler(.rejectProtectionSpace, nil)
			return
		}

		let credential = URLCredential(trust: trust)
		completionHandler(.useCredential, credential)
		return
	}

	completionHandler(.performDefaultHandling, nil)
}

I expect it to accept my decision and trust the server, not give me the error. Otherwise what’s the point of making the callback then?

(This is the moment I hope someone will point out some glaring mistake I made here…)

UPDATE, Oct 23rd

Correct ATS incantation in Info.plist is the answer here, I have no idea why my previous attempts at it did not work. Here’s what I added in this test project so that completionHandler(.useCredential, credential) above works as expected:

<key>NSAppTransportSecurity</key>
<dict>
	<key>NSExceptionDomains</key>
	<dict>
		<key>self-signed.badssl.com</key>
		<dict>
			<key>NSExceptionAllowsInsecureHTTPLoads</key>
			<true/>
		</dict>
	</dict>
</dict>

Or in Xcode:

Going full-on URLSessionDelegate

Ok, let’s go entirely with delegate form and implement all of the callbacks. This is perfectly possible only if both URLSession instance and URLSessionDataTask instance are inside the Operation subclass which is acting as URLSessionDelegate.

Back in the Apple corner, they say I need to have one URLSession instance, which means it must be outside the Operation. However, once URLSession.delegate is assigned to something – that’s final. I can’t change it from one Operation to another. Understandably so since there’s no way to control where incoming data chunks end up if various Operations start stealing the delegate.

So the only solution seems to be: forget about concurrent network requests and execute them one by one. Does not sound right to me.

What I don’t grasp here is why there’s no such thing as URLSessionTask.delegate which will handle task specific stuff, like receiving data, response headers etc, for that specific request.

Also: if there should be one instance which handles session-level Auth challenges – like server trust – why then keep asking me to handle for each task in that same session. All the tasks are using the very same server. Honestly, I can imagine some MitM attack vector here so I sort of understand why they ask each time. But then – what’s the point on having the delegate on the URLSession level and not on the URLSessionTask?

The API design forces me to create some higher-level object to act as URLSessionDelegate which then forces me to build some convoluted structure of keeping track which URLSessionDataTask are active so I can route data received here:

func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive response: URLResponse, completionHandler: @escaping (URLSession.ResponseDisposition) -> Void) {}

func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive data: Data) {}

into proper DataTask instances I keep…somewhere…

I don’t understand how to do concurrent network requests using URLSessionDelegate + replicate what OperationQueue/Operation gives me if I need to use the same session + delegate instance for all the tasks.

Ability to have totally independent network operations is way more important to me than adhering to these best practices.

UPDATE, Oct 23rd

I may have a solution here. Still need to test it in real project and see are there any drawbacks.

Highly maintainable app architecture

Fri, 15 Sep 2017 15:10:40 +0000

Maintainable can mean different things, depends on many factors: project size, goal, 3rd-party service dependence and availability. But perhaps most importantly it depends on the size of the team at hand. Situation is quite different if you have 1 or 5 or 50 developers on the project. Thus it helps to get some bearings where I’m coming from.

Most of my iOS projects are done by me, as one-man team. In last few years I worked on dozen-ish 3rd party client projects. The deal usually has two parts: I develop the app and support it for a while after publishing. However, the client can take over the maintenance at any time, usually when they deem the cost of my retainer too large compared to how much ongoing development there is.

Thus when client forms a team to maintain the app, I need to handover the code. It’s rare to even call it a team since it’s usually just one person, often someone who is coming to iOS/Swift as a developer on other platforms. If you are in the contract / freelancing world, I’m sure this is familiar to you. This talk will be most beneficial to you but the key takeaways here and architecture approach I’m presenting is equally applicable to larger teams, say when you add new employee.

Another important factor is that I rarely have a chance to work with closely integrated front / backend. Quite often the back-end is already “done” and client is unwilling or unable to invest in large (if any) updates. Thus I need an architecture that can adapt to any craziness I will encounter in the backend systems.

Lastly, app I’m making is regularly part of a larger ecosystem of services and front-ends made by multiple companies which may not have the best communication channels between them. So it happens that changes appear in the systems my app is depending on, without me ever being consulted about the impact. It happens, more often than I would like.

Thus this talk in essence is how to navigate these waters without ripping all your hair along the way. When speaking about app architecture, I can’t think of any better way to explain one than to build an app using it.

I’ll use an example of the clothing shop app, loosely based on the work done for one of my favorite local clients in Serbia.

(Everything mentioned here, including the demo app, is MIT licensed and available on my GitHub profile).

UI·UX + Data

So what’s an app made of, that it needs architecture? From the most big-picture aspect, there are two parts:

UI & UX = how the app will fulfill its purpose from the point of the Customer
Data = how the app will do what it needs to do from the point of the Owner (Provider)

UI without the actual live data is Dribbble.com. Beautiful, inspiring, lifts your spirit and brightens your day. Every interaction is amazing and life is awesome.

And then you di…err, experience the joy of enterprise-company production data.

Production data is Excel (and I mean this in the nicest way). Often unstructured and denormalized, available to you in formats invented and (possibly) abandoned before most of you got out from high school. (It was a crazy world out there before the JSON took over.)

(In the example app, I have created few JSON files as base data set loaded from remote server, deliberately structured differently than the nice clean model used in the app.)

Thus when spec-ing out your app architecture, ignore the production data and tailor-build data model for the given UI and workflows.

I start with a good clean data model which:

best supports what the app needs to do
fits nicely into the UIKit (and iOS SDK in general)

Base your app on the data types your platform gives you and use them in the best possible way. I dug my own hole too many times before learning not to care in what format the data is coming from.

It’s much easier to transform data from one structure to another than to cram badly architected data into UI components.

Thus I hide all the complexity of original data I’m given. The task of transforming data is certainly not easy nor particularly light on the CPU. I need to compartmentalize this task into a narrow, self-sufficient module, independent from anything else in the app.

Data Manager

I start with Data Manager.

This is central module, the heart of the architecture. It has knowledge about high-level data types in the app: Product, Season, Color etc. It knows how to convert into them and from them.

If you are using data persistence (Core Data, Realm etc), DataManager is the module which imports into the local storage. Also prepares reading from the local storage, if preparation is needed.

It does not care nor knows where the source data is coming from. It makes no assumption is it local .plist file, API web service which returns JSON or whatever. That’s some other object’s business and DataManager will call that object to receive the data it will work with.

Raw data usually comes from web service APIs for which you need to write wrappers.

API wrapper(s)

Wrapper is very thin native client around web service API. It speaks with the server and knows the intricate details of that communication.

final class IvkoService {
	static let shared = IvkoService()

	private init() {
		urlSessionConfiguration = {
			let c = URLSessionConfiguration.default
			...
			return c
		}()

		queue = {
			let oq = OperationQueue()
			oq.qualityOfService = .userInitiated
			return oq
		}()
	}

	fileprivate var urlSessionConfiguration: URLSessionConfiguration
	fileprivate var queue: OperationQueue
}

If API needs download / upload of files, it works with local files and returns a path, success info. If it’s JSON-based API, API client will convert from Data to JSON. If it’s some String, it converts the binary blob it received to String with proper encoding.

If the service requires OAuth, it transparently handles that entire process. If the service is based on web session cookies, API wrapper handles cookie storage and management.

Data Manager knows nor cares about any of that.

How to model APIs?

Take for example the Spotify web API. As you look closely, all these endpoints:

have a common prefix
have one identifying path component
(may) have one or more parameters

Swift has a perfect tool to model these API endpoints: enum with associated values. From the demo app:

enum Path {
	case promotions
	case seasons
	case products
	case details(styleCode: String)
}

API wrapper is entirely unaware of app’s data model. It knows nothing about Product, Color, Season etc. Data Manager must convert from those types into String, Int, Double, Bool or any collection of those.

A series of enum methods are then used to transform that data into fully-qualified URLRequest instance, tailored for particular API service.

enum Path {
...

private var method: Method {
	return .GET
}

private var headers: [String: String] {
	var h: [String: String] = [:]

	switch self {
	default:
		h["Accept"] = "application/json"
	}

	return h
}

You can switch per self inside these methods and do custom processing for each case, as needed.

This one creates the URL part:

private var fullURL: URL {
	var url = IvkoService.shared.baseURL

	switch self {
	case .promotions:
		url.appendPathComponent("slides.json")
	case .seasons:
		url.appendPathComponent("seasons.json")
	case .products:
		url.appendPathComponent("products.json")
	case .details:
		url.appendPathComponent("details")
	}

	return url
}

This collects all parameters into a dictionary:

private var params: [String: String] {
	var p : [String: String] = [:]

	switch self {
	case .details(let styleCode):
		p["style"] = styleCode
	default:
		break
	}

	return p
}

Which is then encoded as needed, either into query string or as JSON if it goes in the HTTPBody. Or anything custom you may need, this is where you do it.

private var encodedParams: String {
	switch self {
	case .details:
		return queryEncoded(params: params)
	default:
		return ""
	}
}

private func queryEncoded(params: [String: String]) -> String {
	if params.count == 0 { return "" }

	var arr = [String]()
	for (key, value) in params {
		let s = "\(key)=\(value)"
		arr.append(s)
	}

	return arr.joined(separator: "&")
}

private func jsonEncoded(params: JSON) -> Data? {
	return try? JSONSerialization.data(withJSONObject: params)
}

Finally this method uses all the previous ones to build the final URLRequest value:

fileprivate var urlRequest: URLRequest {
	guard var components = URLComponents(url: fullURL, resolvingAgainstBaseURL: false) else { fatalError("Invalid URL") }

	switch method {
	case .GET:
		components.query = queryEncoded(params: params)
	default:
		break
	}

	guard let url = components.url else { fatalError("Invalid URL") }
	var r = URLRequest(url: url)
	r.httpMethod = method.rawValue
	r.allHTTPHeaderFields = headers

	switch method {
	case .POST:
		r.httpBody = jsonEncoded(params: params)
		break
	default:
		break
	}

	return r
}

API wrapper then initiates a network call to fetch data and when it receives the response, it converts that response into a base type form that’s suitable for further processing: String, JSON, properly typed numbers (Decimal, Int etc)…which it then feeds back into the DataManager.

typealias ServiceCallback = ( JSON?, IvkoServiceError? ) -> Void

func call(path: Path, callback: @escaping ServiceCallback) {
	let urlRequest = path.urlRequest
	
		// OAuth handling
		// JSON conversion
		// upload / download
	
	execute(urlRequest, path: path, callback: callback)
}

API wrapper is initiating the network call but it does not handle the details of the network call.

Network mini library

Networking is pretty straight-forward business for which iOS already has perfect library: URLSession & friends. To perform network request, you need URLRequest. As result, you get your data + accompanying response metadata (HTTP status code, headers) or an error.

I’ve made a very thin wrapper around URLSession with sole goal to collect all relevant instances - original request, response headers, data, error etc - into one object: NetworkPayload struct.

struct NetworkPayload {
	let originalRequest: URLRequest
	var urlRequest: URLRequest

	init(urlRequest: URLRequest) {
		self.originalRequest = urlRequest
		self.urlRequest = urlRequest
	}

	///	Any error that URLSession may populate 
	/// (timeouts, no connection etc)
	var error: NetworkError?

	///	Received HTTP response. 
	/// Process status code and headers
	var response: HTTPURLResponse?

	///	Received stream of bytes
	var data: Data?

	///	Moment when the payload was prepared. 
	/// May not be the same as `tsStart`
	let tsCreated = Date()

	///	Moment when network task is started
	/// (`task.resume()`)
	var tsStart: Date?

	///	Moment when network task has ended.
	/// Used together with `tsStart` makes for simple speed metering
	var tsEnd: Date?
}

This micro-library handles networking only stuff, like HTTP authentication challenges, SSL pinning etc. The bulk of the code is in NetworkOperation which is a subclass of my own AsyncOperation which is itself a subclass of Operation. This allows you to use OperationQueue on the API wrapper, play around with Quality of Service, to auto-adjust the number of concurrent network ops depending on the speed of the network. All this while the rest of your app has no idea about this.

This Network library has no shared state. Each NetworkOperation creates its own instance of URLSession, takes the given URLRequest and when done calls back. Each request is independent from any other.

This Network library makes no assumptions about the data, it does not process the received Data blob at all. Whatever it receives, it passes it to the caller. API wrapper knows what it requested and knows how to handle what’s returned.

…

If you combine these two layers - API wrapper + Network layer - you get Alamofire / AFNetworking. I used to swear by AFNetworking until I started encountering less-than-ideal APIs which mostly return JSON until the moment they hit server-side error, in which case I get raw java.sql.exception inside application/json MIME type. At which point AFNetworking will wrap this into ResponseSerializationError, completely hiding the original error received from URLSession. Thus I have to do this:

failure:^(NSURLSessionDataTask *task, NSError *error) {
   strongify(self);

   //	parse and extract the actual error response...
   if ([error.domain isEqualToString:AFURLResponseSerializationErrorDomain]) {
	   //	...from the multitude of AFNetworking envelopes
	   if (error.userInfo) {
		   NSHTTPURLResponse *response = error.userInfo[AFNetworkingOp
		   NSData *data = error.userInfo[AFNetworkingOperationFailingURLResponseDataErrorKey];

		   if ([task.response.MIMEType isEqualToString:@"application/json"]) {
			   NSError *jsonError = nil;
			   NSDictionary *apiError = [NSJSONSerialization JSONObjectWithData:data options:NSJSONReadingAllowFragments error:&jsonError];
			   if (apiError && !jsonError) {
				   //	now we have the actual error response from server
				   //	example:
				   //	{"type":"NoSessionException","message":"Session expired"}
				   //	re-wrap into local error codes
				   NSString *apiErrorCode = apiError[@"type"];
				   NSString *apiErrorMessage = [apiError[@"message"] stringByReplacingOccurrencesOfString:@"java.sql.SQLException: " withString:@""];
				   DDLogError(@"API error response (%ld, %@): \n%@", (long)response.statusCode, task.response.MIMEType, apiError);

				   NSError *reportError = [ErrorManager apiErrorForType:apiErrorCode message:apiErrorMessage];

This is terrible and the source of the issue is obviously on the server-side, where it should be handled and fixed. The key word: should. That fix may be coming in next release scheduled for November or maybe early next year. Thus the code like the one above is needed due to zero flexibility with the library that expects valid JSON or else…

Separation of the API wrapper and actual networking gives me a chance to cleanly handle this nonsense and return properly formatted error to the API. I document my local error and send it to client / back-end team to implement it on the server. If the back-end ever gets fixed and improved, the only change on my end would be to delete the code handling these exceptions.

…

Important thing to remember is that DataManager will have one method for each API endpoint. Even if you have dozen or so API endpoints that look to return the same data structure, do not combine them into one method on Data Manager side. At some point over time it’s virtually guaranteed that at least few of those API endpoints will be changed to return something slightly different and then you start doing switch/case per API endpoint in both request and response parts of the DataManager method. I’ve been burned enough times that I know this is not the time to be DRY. You can extract the processing parts that are the same - like conversions to/from JSON, validation of the returned response…but never actual methods.

One API endpoint == one Data Manager method and the future you will thank you.

Business logic

On the other side of the Data Manager is client-side business logic. What do I mean by this..?

Say you have a login method which results in Customer object. Where do you keep it? Job of the DM is to fetch and deliver that object but not to keep a reference to that one specific instance.

To complicate matters a bit more - I encountered APIs where I need to make multiple backend request before Customer object is properly formed. So my previously simple DataManager now becomes aware of transactions and how objects it creates are related to one another… Nah! Data transformations it does already are more than enough for it.

Middleware is the term usually reserved for the part of the architecture between the front-end and database. In iOS apps, I create a series of thin, strictly-focused managers.

I create an AccountManager which is thin wrapper on top of the DM and it keeps a reference to that specific instance and gives it business meaning. I need 3 API calls to get customer details, his balances etc? AccountManager will call 3 DataManager methods and combine the results into one object.

This frees you to independently optimize how the data processing in DataManager is done, without the need to care about the meaning of actual objects.

In most larger apps, I would have half a dozen or more small managers that are all part of this business logic layer.

To re-iterate: DataManager creates instances of Product, Category, Season etc. But it makes no assumptions what they are. Every single one of those objects is some thing with a name.

🙂 🙂 🙂 🙂 🙂 🙂 🙂
↓  ↓  ↓  ↓  ↓  ↓  ↓ 
👮‍♀️ 👨🏼‍🌾 👩🏾‍🎤 👩🏽‍💻 👩🏿‍💻 👨🏻‍🎨 👩🏽‍🚀

Business meaning is assigned by higher-level managers.

AccountManager will ask DataManager to provide it with an Account object for given user/pass. AccountManager is the one that knows that particular instance is the currently logged-in customer. DataManager couldn’t care less, it’s simply yet another Account instance.

Similarly, CartManager will ask DataManager for an update (price, stock availability) for the particular Product. CartManager is the one who knows in what intervals should updates be performed. DataManager simply creates/refreshes the instance and gives the new one back.

CatalogManager contain data displayed in the shop browsing views. It knows when they should be refreshed, can optionally cache them if needed etc.

…

This separation into layers is amazingly flexible.

Middleware
Data Wrangling (Management)
Data Sourcing
Networking (if needed)

Each of them has strictly defined role and as such they are very suitable to automated testing, easy to debug and mock etc.

I can have multiple vastly-different API wrappers which all in the end need to execute URLRequest. DataManager may need to pick up some data like ads from 3 or 10 different platforms. They usually all have the same set of data and thus can be modeled with the same model instance.

This granularity and thin layering greatly simplifies maintenance. Big part of this is that it simplifies automated testing as you can test CartManager with any static combination of data you can think of, completely avoiding the process of actually sourcing the objects. Mocking is very easy.

Similarly, you can test DataManager with static files and API wrappers with zero care about networking. API wrapper should work 100% the same if data comes using URLSession or through local JSON file in the bundle. NetworkPayload is struct – hard-code any possible combination you need to test without actually making the network call.

No matter what your raw data looks like, your job is really straight-forward:

write API wrapper part first
write DataManager method and processing code
write middleware Manager method to call its corresponding DataManager

Once you write one or two data flows, you have learned all there is to learn.

…

This architecture approach is nothing new, mostly common sense. But I feel that the craft of building layered architecture got a bit lost in the (used to be) simple world of mobile apps. In this beautiful new startups world with teams working in unison to create both front-end and back-end for their app/service. Thus you get things like GraphQL, Realm Mobile Platform where most of this stuff is done for you under the hood.

But there’s so much work opportunity in the “older industry” world, where people work in systems created a decade or more ago. Where JSON import/export may not even exist. A layered approach like this can help you a great deal to step into that world and keep yourself and your clients happy in the support & maintenance phase.

…

Now, on the UI side, things are equally interesting.

UI

I hope by now it’s obvious that UI will only communicate with middleware part. I aim to avoid direct communication between the UI and the Data Manager.

UI should never, ever communicate directly with Network or API wrapper. Never!

Here’s an example from the demo app, the front view of the shop app:

To display the horizontal scroller of products, I need the CatalogManager().promotedProducts array and feed it into UICollectionView.

But how will this actually work? Should PromoContainerCell here call CatalogManager to get the list of promoted products? Will HomeController do that and pass it to PromoContainerCell?

This view is also the earliest chance my customer can buy something; that green Buy Now button which sits on top of the cell is obviously related to a particular product. So this Cell instance knows about the button and it knows about the Product instance.

To complete the purchase, I need some simple way to write something like:

let product = promotedProducts[indexPath.item]
cartAddProduct(product)
...
cartBuyProductNow(product)

and job done. Simple, readable, easy to explain. I’m not asking for anything unusual - UIKit already works this way. If you want to push some UIVC instance into current UINC, you simply do show(vc, sender: self) from any darn-deep level in your UIVC hierarchy and it magically slides from the side.

Side-note: if you are still writing self.navigationController.pushViewController(vc) - please stop (unless you still need to support iOS 7 or earlier).

But how will this actually work? Will PromoCell directly access CartManager to add the chosen product to the cart?

Solution: Singletons

One way to solve this is to make all those managers Singletons and then call them directly. This is quick and easy solution, requires very little code to implement.

let product = promotedProducts[indexPath.item]
CartManager.shared.add(product)

There are quite a few issues with hard-coded connection likes that one, as proved – proved!, I tell ya – by innumerable flame wars in the programming community since…well, forever. After 20 years of development, I mostly just 🙄 and look for practical benefits and applications. Singletons are omni present in the Cocoa SDKs and are very useful when used pragmatically.

But…

When used carelessly like in the example above – like some omni-present deity objects that accept your prayers wherever and whenever – they have pretty significant practical issues which regularly appear in more complex apps. Example: what if your action - like add to cart - needs to update some other data or view up in the UI chain as well as CartManager? Say a cart-counter widget in the HomeController.

Oh easy - I can solve this with Notifications, right..? CartManager will post DidUpdateCartNotification, HomeController will observe it and update its cart widget.

Oook…but what if the cart state is actually implemented on the server? Now you need to wait for network request, thus it makes sense to show some loading spinner and update the cart item counter when it finishes. Oh easy, just add another notification - StartCartUpdate and EndCartUpdate…

🙅🏻‍♂️ Using Singletons like this is no-go.

Each new notification adds more and more indirect pathways to worry about. Really quickly this goes into unmaintainable mess.

Solution: Delegate pattern

Let’s then try a different solution: Delegate pattern. PromoCell will have a delegate method promoCellDidTapBuyNow and someone will implement it and become a delegate to handle that. But who?

PromoCell is only known to its direct parent, PromoContainerCell. Which has no idea (yet) that CartManager exists. So we go up to HomeController which might know - it’s a Controller, after all, right? So we add another Delegate implementation: PromoContainerCell().delegate = HomeController().

Poor PromoContainerCell – it acts like both delegate and delegator for an action that it cares nothing about. Its only job is to receive [Product] and feed it to UICollectionView. Not to care what happens inside PromoCell - for all intents and purposes it should not even know that there’s a button in it.

Maintenance is becoming a real headache now. If you try to move promoted products scroller to some other place in the UI, you need to make sure to replicate such delegate chain as well. 😣

…

While I’m thinking this through, I have barely touched on the 🐘 in the room: why would any of these views / controllers even know that CartManager exists?

🤔 🤷🏻‍♂️

Strictly speaking, their job is to get the data they receive and display it. Their job is to collect the touch/action and pass it along to someone else but that does not mean they need to know who that someone is.

Get data, display it.
Receive action, pass it along.

That’s what UIVC/UIView are supposed to do.

There are multiple problems with just about any approach here and UIKit - in its current form - is not really helping. But it’s the thing we have and the thing we need to work with.

Let’s go few steps back…

What I want is a replica of what I have in the app’s backend: a set of focused components with clearly defined inputs and outputs. Translated into UIKit world, what I want boils down to this:

UIViewController should not know nor care about the hierarchy it’s presented in (is it inside the nav, split, popover, whatever)
It must be able to receive data it needs or ask for it, without knowing who exactly is delivering the data
It should be able to send info about events that happened in it — button taps, row/cell taps, swipes, any kind of interaction — to its semantic parent

This means that each UIVC should be configured using Dependency Injection and apart from those local data sources it should not need anything else to do its job.

In Swift, DI = (stored) properties. Either on UIViews or UIVCs, what you define as Data source stored properties is all that is needed.

If the Controller is able to feed its View(s) using only that Model then you have properly implemented MVC.

Embrace MVC. It’s great pattern, easy to explain, easy to use.
Use MVC properly. Use it for what it was designed. Use it for one UI entity only, to coordinate between its local data model and the view.
Think thrice before reaching out to anything else.

final class HomeController: UIViewController {
	//	UI Outlets

	@IBOutlet fileprivate weak var collectionView: UICollectionView!
	@IBOutlet fileprivate weak var notificationContainer: UIView!

	//	Local data model

	var season: Season? {
		didSet {
			if !self.isViewLoaded { return }
			updateData()
		}
	}

	var promotedProducts: [Product] = [] {
		didSet {
			if !self.isViewLoaded { return }
			collectionView.reloadData()
		}
	}
	var categories: [Category] = [] {
		didSet {
			if !self.isViewLoaded { return }
			collectionView.reloadData()
		}
	}
}

If the UIVC in question is actually your custom container controller (like HomeController is), the same rules should apply. With the help of property observers, you can keep your embedded controllers happy and pass the data along.

Note: pay attention to isViewLoaded, it’s crucial to check this inside property observers to avoid premature view loading. All the work you do in property observers should be repeated in the viewDidLoad and these two moments of setup should never happen in sequence.

…

Still…the original problem remains: how to pass the data into top-level UIVC in the first place. Where will the connection between the UI components and middleware happen?

How then will cartBuyNow(product) find its way up to CartManager / PaymentManager / something? If the UIVCs should not know about all these managers, who then will keep the references to them?

Well, that’s obvious; it must be the only thing left in our UI stack that’s not UIViewController:

AppDelegate!

…

😖 No.

Coordinators

Two years ago at NSSpain, Soroush Khanlou proposed Coordinators as possible solution for the problem of data flow between app’s model and UIs.

Coordinators completely solve the data flow in the UI layer. They don’t hold nor contain any sort of app’s data - their primary concern is to shuffle data from middleware into front-end UI.

What they do:

Create instances of the VCs
Show or hide VCs
Configure VCs (set DI properties)

plus:

Receive data requests from VC
Route requests to middleware
Route results back to VC

These are key things required in order to release UIVCs from the burden of knowing their place in the UI hierarchy and where they are used.

Coordinators wonderfully solve a plethora of issues in modern iOS apps:

they naturally implement universal links / remove notification pathways through the app
easily handle ForceTouch quick actions or Handoff continuation
seamlessly handle communication with extensions
etc.

Let’s see how to use them.

How to use Coordinators

Since Coordinator’s job is to handle data flow then it’s their job to know about the parent-child relationships in the app which means they deal with UI hierarchy. Each Coordinator can be parent and/or child of any other Coordinator.

In our shopping cart app, we would first need a high-level object that represents root Coordinator, more often called Application Coordinator. This object will create and hold instances of all the middleware Managers, like API wrapper, DataManager, CartManager etc. It also contains logic which decides what will be set as window.rootController.

Said plainly — it does what people usually do in AppDelegate. This leaves AppDelegate alone to handle its already big pile of app’s sentry duties that UIKit gives it.

You then model big picture parts: AccountCoordinator, CartCoordinator, CatalogCoordinator etc. Then you may have more focused stuff like PaymentCoordinator which deals just with payments. You may also have NotificationCoordinator that handles in-app presentation of the received push notifications. Etc.

The only object that’s always in the memory is ApplicationCoordinator and is kept with strong property on the AppDelegate. All the others are allocated and removed as needed. Each of those others can be a child of any other Coordinator, there is no fixed structure. So you can have any of these hierarchies currently active:

App → Catalog → Payment
App → Account → Payment
App → Catalog → Cart → Payment
App → Payment

AppCoordinator will have a bunch of (file)private properties to hold middleware instances. Those instances can be Singletons or not, as you wish. Frankly speaking, for bunch of them it makes sense to be Singletons and that is ooook.

Each Coordinator then employs Dependency Injection to receive a special struct called AppDependency. This is simply a collection of references to middleware Manager instances. Each and every Coordinator will always get a set of references to all managers, passed-down automatically from AppCoordinator. Why this?

struct AppDependency {
	var apiManager: IvkoService?
	var dataManager: DataManager?
	var assetManager: AssetManager?
	var accountManager: AccountManager?
	var cartManager: CartManager?
	var catalogManager: CatalogManager?

	var keychainProvider: Keychain?
	var persistanceProvider: RTCoreDataStack?
	var moc: NSManagedObjectContext?

	init(apiManager: IvkoService? = nil,
	     persistanceProvider: RTCoreDataStack? = nil,
	     dataManager: DataManager? = nil,
	     moc: NSManagedObjectContext? = nil,
	     assetManager: AssetManager? = nil,
	     accountManager: AccountManager? = nil,
	     cartManager: CartManager? = nil,
	     catalogManager: CatalogManager? = nil,
	     keychainProvider: Keychain? = nil)
	{
		self.accountManager = accountManager
		self.assetManager = assetManager
		self.cartManager = cartManager
		self.catalogManager = catalogManager
		self.apiManager = apiManager

		self.keychainProvider = keychainProvider
		self.persistanceProvider = persistanceProvider
		self.dataManager = dataManager
		self.moc = moc
	}
}

Some managers are “free” to instantiate since they are independent. API wrappers fall into this category. But others may not be. As I said previously - if you are using Core Data, Data Manager is the one that will handle Core Data objects, import, updates etc. Thus DataManager needs a reference to the Core Data Stack at the moment it’s created; that stack is certainly not free to create. You need to wait few 100s of milliseconds for it and it’s not really wise to wait even that much before displaying your UI. It makes the app feel slow. Since entire middleware part is then dependent on the Data Manager, all of them must wait as well. You are in danger of approaching that loose cut-off point after which iOS runtime may decide that your app has stalled and it may kill it.

To avoid this, what I usually do is something like this:

override func start(with completion: @escaping () -> Void = {}) {
	//	singletons, independent of other objects
	settings = Settings.shared
	apiManager = Empires.shared
	gamesManager = GamesManager.shared
	adsManager = AdsManager.shared
	keychainProvider = Keychain(service: Bundle.identifier)
	dependencies = AppDependency(apiManager: apiManager,
								 gamesManager: gamesManager,
								 adsManager: adsManager,
								 settings: settings,
								 keychainProvider: keychainProvider)
	//	mark the coordinator started
	super.start(with: completion)

	coreDataStack = RTCoreDataStack() {
		[unowned self] in
		self.configureMiddleware()

		self.dependencies = AppDependency(apiManager: self.apiManager,
								   gamesManager: gamesManager,
								   adsManager: adsManager,
									 settings: self.settings,
									 keychainProvider: self.keychainProvider,

									 persistanceProvider: self.coreDataStack,
									 dataManager: self.dataManager,
									 moc: self.coreDataStack.viewContext,
									 accountManager: self.accountManager,
									 cartManager: self.cartManager,
									 paymentManager: self.paymentManager)
	}

	...
}

func configureMiddleware() {
	// create instance of DataManager
	// and all the middleware ones
}

I fire up entire UI hierarchy while the Core Data Stack is warming up. My UI will display its LoadingState with some loading indicators or maybe an intro tutorial if you have one in the app. Once the stack is ready, it will call back at which point I create instances of the DataManager and its middleware friends and create updated AppDependency struct which is then passed through the active chain. With Swift’s generics, that’s easy to write in one place and call from property observer on each Coordinator implementation.

protocol NeedsDependency: class {
	var dependencies: AppDependency? { get set }
}

extension NeedsDependency where Self: Coordinating {
	func updateChildCoordinatorDependencies() {
		self.childCoordinators.forEach { (_, coordinator) in
			if let c = coordinator as? NeedsDependency {
				c.dependencies = dependencies
			}
		}
	}
}

Since Coordinators will load and initiate display of View Controllers, they need some place to keep a reference to them. Hence each Coordinator has rootViewController property which can be set to instance of any subclass of UIViewController. Active Coordinator will always set itself as parentCoordinator for its root view controller. (I’ll explain why in a minute.)

Usually that’s UINavigationController instance and Coordinator will simply do rootViewController.show(vc, sender: self) when it needs to show particular content controller.

…

Phew. This solves the input (DI) from Coordinator into UIVC.

Now, about output - how touch events / actions propagate from UIVC to Coordinators so they can route them to the Managers?

Why not Delegates?

In his talk, Soroush recommends Delegate pattern; not just for Coordinators but also for VCs where VC.delegate will be set to their containing (parent) Coordinator. This works acceptably if our UIVCs are flat but in case they are containers…well, I already explained the issues with that.

Here’s again the Home view from the demo app:

That green button which triggers Buy Now for the given item? Here’s where it is located:

AppCoordinator
  ↖︎ CatalogCoordinator 
    ↖︎ HomeController (inside UINavigationController)
      ↖︎ PromoContainerCell
        ↖︎ PromoCell

(This is about twice simpler case than some complicated UIs I had “pleasure” to implement in last several years.)

Can you count how many Delegates I would need just for this? It’s a maintenance headache in the long run. No go.

Inspiration

Looking for solution of any architectural issue, it’s good practice to first look at your framework of choice. Never fight the SDK; be friendly to it.

Lo and behold, UIKit already has very similar functionality; I mentioned it some minutes ago:

class UIViewController {
	func show(_ viewController: UIViewController, sender: Any?)
}

Smells like a good candidate: one method without any required boilerplate in my code; that you call on any UIViewController and with default implementation that simply calls parent.show(…). UINC (and few others) override this method and implement their own specific behavior — for UINC that means doing push. Perfect message bubble-up through any given hierarchy with a single line of code you write.

Some observations:

show(vc...) is based on UIViewController.parent so it works just with UIVCs
I need it to work with Coordinator too
I also need it to work with UIView, since original sender can be a simple UIButton in the UI*Cell or similar

Looking more closely at this I realized that this behavior is based on class inheritance and overriding a particular method (show) and setting a property (parent). And this lead me to the solution:

What’s the common ancestor for both UIView and UIViewController?

UIResponder

Thus:

make class Coordinator: UIResponder {…}
find a replacement for parent that spans both UIView and UIViewController and
make sure it works with Coordinator too

What follows is an explanation of the Coordinator micro-library

First one is straight-forward.

Second one was easy once I read the docs on how UIResponder actually works, meaning how it knows what’s the next responder in the chain:

class UIResponder : NSObject {
	open var next: UIResponder? { get }
}

The parent entity will set itself as next on any direct child entities it owns / creates.

Well, thank you UIKit — I can piggy-back on UIResponder.next without actually interfering with it.

public extension UIResponder {
	public var coordinatingResponder: UIResponder? {
		return next
	}
}

With coordinatingResponder, I can implement my own custom messaging system that will bubble up through the entire hierarchy in one-line method:

extension UIResponder {
	dynamic func messageTemplate(args: Whatever, sender: Any?, callback: @escaping () -> Void) {
		coordinatingResponder?.messageTemplate(args: args, sender: sender, callback: callback)
	}
}

Anywhere I need a custom behavior or specific handler for this method, I simply override messageTemplate and…done. Any unhandled message will simply bubble up until AppCoordinator (and AppDelegate) and be ignored if not handled anywhere.

Key fact: these methods can be used to request stuff by going up the chain and can receive stuff back through the callback’s chain.

Neat.

Inter-connect with Coordinator

Remaining issue to solve: if Coordinators are controlling the UIVCs, then in order for the bubble-up to work, each UIVC instance needs to know what is its (optional) parent Coordinator.

Simple 😇, with little help from wonderfully dynamic iOS runtime:

extension UIViewController {
	private struct AssociatedKeys {
		static var ParentCoordinator = "ParentCoordinator"
	}

	public var parentCoordinator: Any? {
		get {
			return objc_getAssociatedObject(self, &AssociatedKeys.ParentCoordinator)
		}
		set {
			objc_setAssociatedObject(self, &AssociatedKeys.ParentCoordinator, newValue, .OBJC_ASSOCIATION_ASSIGN)
		}
	}
}

(thanks Objective-C!)

I need to thread carefully here…Excerpt from UIResponder.next documentation:

The UIResponder class does not store or set the next responder automatically, instead returning nil by default. Subclasses must override this method to set the next responder.

UIView implements this method by returning the UIViewController object that manages it (if it has one) or its superview (if it doesn’t);

UIViewController implements the method by returning its view’s superview;

UIWindow returns the application object, and UIApplication returns nil.

So I need to mimic UIViewController.next and jump to the Coordinator if the UIVC.parentCoordinator is not nil. Otherwise, I need to replicate exactly what documentation describes:

override open var coordinatingResponder: UIResponder? {
	guard let parentCoordinator = self.parentCoordinator else {
		guard let parentController = self.parent else {
			return view.superview
		}
		return parentController as UIResponder
	}
	return parentCoordinator as? UIResponder
}

That middle self.parent check here shortens the walk up the responder chain and also enables usage of these message in viewDidLoad. 🤘🏻

Lastly, on the Coordinator level:

open class Coordinator<T: UIViewController>: UIResponder, Coordinating {
	open var parent: Coordinating?	
	
	override open var coordinatingResponder: UIResponder? {
		return parent as? UIResponder
	}
}

Benefits

You can call the coordinatingResponder method from anywhere in the UI code
It will travel up across all the views
Once it gets to any UIViewController, it will continue on through UIVC chain (of fallback to views if there’s no parentController)
Once it gets into any Coordinator, it will stay in the Coordinator chain
You can override the chain loop at any point, do something and continue on the chain

This system is not perfect but is pretty straight-forward in all cases. Don’t go crazy and remove all the Delegate pattern implementations in your code. It still has its place. If you have a component that always needs just one parent then is probably nicer to handle that using Delegate pattern. But if there’s any chance that this particular child may need to connect to more than one parent in one call, then coordinatingResponder method is much better solution.

There are situations where you need to be pragmatic and not implement this to the core (say with Core Data driven views). But if my last 3 of 4 projects are any indications, this approach is amazingly versatile and applicable to pretty complex apps, with 10+ Coordinators, 100+ UIViewControllers, multiple API wrappers and services.

The only thing Coordinator truly needs to be perfect are two letters in front of it: UICoordinator

(👋🏻 , sherlock this, pretty please)

…

There’s no fancy name for this architecture. Probably the most suitable name to call it is LAYERS, which is not an acronym for anything.

Any feedback – please open an issue on Coordinator repo or talk to me on Twitter: @radiantav

Passing dependencies through Coordinator chain

Sun, 23 Jul 2017 15:49:40 +0000

As described in the original post about Coordinators and MVC-C architecture, the top logical entity in your app should be AppCoordinator.

This Coordinator will then create and keep references to instances of other coordinators; either directly keeping references to them or through childCoordinators.

Apart from AppCoordinator, most other Coordinators are most likely content-oriented. Which means they will have a set of UIViewControllers that they display for specific purpose. How they do that – create UIVCs, present them etc – it’s their own business so it makes no sense to expose that as public. However, there should be a way for other coordinators to specify the desired content. Example: remote notification handler may instruct you to display a specific promo offer inside CartCoordinator.

This concept of the content page/view, I modeled through simple enumeration inside each content Coordinator, like this:

enum Page {
	case cart
	case checkout
	case payment
	case offer(String)
}
var page: Page = .cart
func display(page: Page) {
...
}

enum is great for this since it’s dead simple to scan and it’s straightforward to supply whatever set of parameters the page may need.

Now AppCoordinator is able to create / activate CartCoordinator and specify what it should display, without knowing how that will be done.

Here’s a typical method:

func showCart(_ page: CartCoordinator.Page?) {
	let identifier = String(describing: CartCoordinator.self)
	//	if Coordinator is already created...
	if let c = childCoordinators[identifier] as? CartCoordinator {
		c.dependencies = dependencies
		//	just display this page
		if let page = page {
			c.display(page: page)
		}
		return
	}

	//	otherwise, create the coordinator and start it
	let c = CartCoordinator(rootViewController: navigationController)
	c.dependencies = dependencies
	if let page = page {
		c.page = page
	}
	startChild(coordinator: c)
}

...

showCart(.offer(offerId))

CartCoordinator will fetch the offer using provided offerId from the remote notification and push the appropriate UIViewController.

To do that, it will probably need access to some DataManager and/or APIManager. Instances of those objects are kept at AppCoordinator and are passed-down using that one line of code I sneaked in the previous code snippet:

c.dependencies = dependencies

What is dependencies?

AppDependency

It’s the simplest possible struct with bunch of optional properties:

struct AppDependency {
	var apiManager: Empires?
	var dataManager: DataManager?
	var promoManager: PromoManager?
	var settings: Settings?

	var persistanceProvider: RTCoreDataStack?
	var moc: NSManagedObjectContext?

	init(apiManager: Empires? = nil,
	     persistanceProvider: RTCoreDataStack? = nil,
	     dataManager: DataManager? = nil,
	     moc: NSManagedObjectContext? = nil,
	     promoManager: PromoManager? = nil,
	     settings: Settings? = nil)
	{
		self.settings = settings
		self.promoManager = promoManager
		self.apiManager = apiManager
		self.persistanceProvider = persistanceProvider
		self.dataManager = dataManager
		self.moc = moc
	}
}

Using the provided init, you can create instance of this struct with any combination of app-wide dependencies.

I enforce the requirement through simple protocol, adopted by each Coordinator I create:

protocol NeedsDependency: class {
	var dependencies: AppDependency? { get set }
}

What I need to make sure is that whenever dependencies is set, that new value is passed-down to all its child Coordinators.

final class CartCoordinator: Coordinator<UINavigationController>, NeedsDependency {
	var dependencies: AppDependency? {
		didSet {
			updateChildCoordinatorDependencies()
		}
	}
}

Implementation of this particular method is easy, using protocol extensions:

extension NeedsDependency where Self: Coordinating {
	func updateChildCoordinatorDependencies() {
		self.childCoordinators.forEach { (_, coordinator) in
			if let c = coordinator as? NeedsDependency {
				c.dependencies = dependencies
			}
		}
	}
}

And that’s about it. In the next post in the Coordinator series I’ll explain how to use AppDependency with UIViewController and especially how to handle the case where some of the dependencies may not yet be available when it’s requested.

As always, keep an eye on Coordinator repo as I keep adding small fixes and refinements.

Coordinator updated, now with less Any

Sun, 11 Jun 2017 18:30:40 +0000

I have updated my Coordinator library, cleaning up the use of Any in both parent and childCoordinators properties. This is a breaking change from previous version, thus the version is now 4.0.

I have introduced Coordinating protocol which is very simple and both properties mentioned above are now of that type. The only purpose of those properties is to maintain coordinator hierarchy; for which I only need Coordinator’s identifier and its coordinatingResponder.

public protocol Coordinating: class {
	var identifier: String { get }
	var coordinatingResponder: UIResponder? { get }
}

Coordinator class naturally adopts this protocol:

open class Coordinator<T>: UIResponder, Coordinating {
	...
	open lazy var identifier: String = {
		return String(describing: type(of: self))
	}()

	/// Parent Coordinator can be any other Coordinator
	open weak var parent: Coordinating?

	///	A dictionary of child Coordinators, where key is Coordinator's identifier property
	fileprivate(set) public var childCoordinators: [String: Coordinating] = [:]

	open override var coordinatingResponder: UIResponder? {
		return parent as? UIResponder
	}
	...
}

I wasted way too much time trying to type-erase the Coordinator<T> before giving up and realizing I don’t need to do that at all. Goes to show that sometimes you need to stop and think back about the problem you actually need to solve.

start and stop methods also got simple default implementation that calls their completion blocks. Thus when you override them, you can now freely call super.start() and super.stop() at the end of your overrides.

The accompanying example app is updated to use the new library and everything seems to work just fine.

MVC-C · Injecting Coordinator pattern in UIKit

Thu, 18 May 2017 16:49:40 +0000

I first learned about Coordinators from Soroush Khanlou’s talk at NSSpain 2015 and two related articles on his blog. A bit later, Krzysztof Zabłocki wrote about more or less identical concept he calls Flow Controllers.

I got intrigued because it was the first iOS app architecture approach I’ve seen that (from my point of view) didn’t try to replace nor denigrate MVC — it embraced and extended it. It builds on existing design patterns: Model View Controller (MVC), Delegation and Dependency Injection (DI), all already proven to work well in practice.

In this article I want to present my evolution of the Coordinator approach that helped me conquer rather large app with 10 or so distinct parts and 100+ UIViewControllers in total.

But first — quick intro to where Coordinators fit in the iOS app architecture.

Let’s imagine a shopping cart app. I actually built a simple one as example project accompanying the library on Github.

Essential goal for this app is: customer adds items to shopping cart from anywhere in the app and completes the purchase of those items at any given moment.

It’s quite likely that you may have multiple features showing items for sale.

Promoted/clearance items in one or more carousels
Browse feature through one or more collection views
Controllers nested inside different controllers etc.

Lots of UI options your designer can choose to use. Key thing: regardless of where the item is shown, it should have a buy now or add to cart button. This is e-commerce app thus its key purpose should be available with as little friction as possible.

So let’s break down the high-level parts: you at least need My Account, Cart, Browse-Catalog. Each of these parts can have just one or two views up to maybe dozens. Then you also have minor parts which can overlap and/or be shared between those high-level parts. Things like: register payments or maybe deposit into an account or enter/retrieve a shipping address. Each of these can end up being a world of their own where you need to potentially support dozens of different payment options - cards, web wallets etc. Which often have strict requirements how they need to be presented. So dozens of additional controllers and views.

Payments can be initiated in the My Account but are needed inside the Cart as well. Or directly on the browsing views if you have 1-click buy. So that means that you may need to switch quickly to an entirely different context. And be able to go back to original context, whatever it is. So your poor PaymentViewController needs to know the context/conditions in which it was initiated and where it should go back once it’s done.

Adding items to cart is also prone to similar complexities. Regardless of where I tap, no matter how deep in the catalog display hierarchy I am — that chosen item should find its way to the Cart. For that to work, I either need to pass some CartManager instance all the way down to the leaf nodes or…maybe target a method on CartManager singleton. (I can almost sense you shudder) No matter which method you choose, your UICollectionViewCell or nested child UIViewController or whatever…is now deeply bound to the Cart Whatever.

You see where I’m going with this..?

This is what causes M(assive)VC problem people complain so much in iOS world. Controllers take up more and more responsibility as you add features and interconnect the app parts.

I’ve seen way too many people blame Apple¹ and Cocoa flavor of MVC for this. I find that really unjustified; the onus here is on the developer at hand, not Apple nor Cocoa.

Let MVC be MVC

What we need here is architecture that lets MVC do the task it was designed to do - handle display of one visual component and do nothing else.

MVC usage rules in UIKit:

UIViewController should not know nor care about the hierarchy it’s presented in (is it inside the nav, split, popover, whatever)
It should be able to send info about events that happened in it — button taps, row/cell taps, swipes, any kind of interaction — to its semantic parent
It should not make any network requests by itself, it shouldn’t even know nor care is there network connection available but
It needs to be able to request data and receive either the data or error/info about why data is not delivered

In other words, it should be configurable from outside (Dependency Injection at work). It should receive only the subset of app’s data set it needs to.

For the output: if you find your self calling self.navigationController or self.parent – you have failed this pattern² called MVC. It’s not the job of view controller to create nor decide the fate of other UIVCs.

Coordination between controllers and data flow through the app is someone else’s job — enter the Coordinators.

Coordinator job

Create instances of the VCs
Show or hide VCs
Configure VCs
Receive data requests from VC
Route requests to network, data, account etc. managers
Route results back to VC

Since their job is to handle data flow then it’s their job to know about the parent-child relationships in the app thus they also deal with coordinator hierarchy.

Hence each Coordinator can be parent and/or child of some other Coordinator.

How to use Coordinators

In our shopping cart app, we would first need a high-level object that represents root Coordinator, more often called Application Coordinator. This object will create instances of all other specific *Manager stuff, like NetworkManager, API wrapper, DataManager, CartManager etc. It also contains logic which decides what will be set as window.rootController. Said plainly — it does what people usually do in AppDelegate.

High-level app parts are covered by AccountCoordinator, CartCoordinator, CatalogCoordinator. Then you have focused stuff like PaymentCoordinator which deals just with payments. You may also have NotificationCoordinator that handles in-app presentation of the received notifications. Etc.

App → Catalog → Payment
App → Account → Payment
App → Catalog → Cart → Payment
App → Payment

Each Coordinator uses Dependency Injection with protocol composition to receive what it needs to operate properly.

Since Coordinators will load and initiate display of more than one View Controllers, they need some UIKit entity for that. Hence each Coordinator has rootViewController property which can be set to instance of any subclass of UIViewController. Active Coordinator will always set itself as parentCoordinator for its root view controller.

Usually that’s UINavigationController instance and Coordinator will simply do rootViewController.show(vc, sender: self) when it needs to show display controller.

Communication

Now, this is the key part of my approach.

In his talk, Soroush recommends to use DI pattern for input, which I agree with, as shown above. For output, he went with Delegate pattern; not just for Coordinators but also for VCs where VC.delegate will be set to their containing (parent) Coordinator. At first, I went with that approach. However, I found it lead to whole lot of boilerplate and repeated code.

I don’t know is it my luck to attract clients with affinity for complicated UIs but in last 4 projects I had to implement my own container controllers, in some cases with 2 or 3 levels deep nesting. Designs where you need to present vastly different UI from separate data sources, all on single screen.

So in our imaginary shopping app, I mocked this up with the slider at the top being a UICollectionView nested inside the cell of another collection view. In Reveal it looks like this:

Now, see that green button which triggers Buy Now for the given item? It’s inside PromotionCell, which is inside PromoContainerCell, which is inside HomeController’s collection view, which is nested in UINavigationController which is owned by CatalogCoordinator which is a child of ApplicationCoordinator where the CartManager instance is likely kept.

So if I implement Delegate pattern to pass this Buy Now action up, each level will need to adopt the protocol containing the cartBuyNow(:) method in order for it to reach the top. Even controllers that have no need for it, like PromoContainerCell or HomeController. Their job is to read and display the data, not care about taps on some small part of the UI. Even if that UI is in their subview hierarchy.

One way to solve this is to pass CartManager as dependency all the way from the top down to the bottom. But then — why would all the objects higher in the hierarchy care about CartManager? The precious few that need to care are maybe CartCoordinator and CartViewController which are not in that hierarchy. All the others - not so much.

(You see now why Singleton trap is so easy to fall into? I just add a tiny call to CartManager.shared.cartBuyNow() and problem solved, right?)

So, key problem is: how to transfer this cartBuyNow call up the stack without adding too much code?

Inspiration

I first looked for possible solution in UIKit. Because there’s already very similar functionality in it:

class UIViewController {
	func show(_ viewController: UIViewController, sender: Any?)
}

This is a replacement for the self.navigationController.pushViewController() we all used before iOS 8. (Please, don’t ever use it today)

This is good candidate: one method without any required boilerplate in my code; that you call on any UIViewController and with default implementation that simply calls parent.show(…). UINC (and few others) override this method and implement their own specific behavior — for UINC that means doing push. Perfect message bubble-up through the given hierarchy.

Sadly, this is not usable for me since:

It only works with UIViewControllers
I need it to work with Coordinator hierarchy too
I also need it to work with UIView, since action sender can be a simple UIButton in the UI*Cell or something similar

Looking more closely at this I realized that this behavior is based on class inheritance and overriding a particular method (show) and/or setting a property (parent). And this gives us the solution…

What’s the common ancestor for both UIView and UIViewController?

UIResponder

Thus all I need to do is:

class Coordinator: UIResponder {…}
find a replacement for parent that spans both UIView and UIViewController and
can be implemented on Coordinator as well

First one is straight-forward.

Second one was easy once I read the docs on how UIResponder actually works, meaning how it knows what’s the next responder in the chain:

class UIResponder : NSObject {
	open var next: UIResponder? { get }
}

Well, hello there — I can piggy-back on UIResponder.next without actually interfering with it.

public extension UIResponder {
	public var coordinatingResponder: UIResponder? {
		return next
	}
}

With this, I can implement my own custom messaging system that will bubble up through the entire hierarchy in one-line method:

extension UIResponder {
	func messageTemplate(args: Whatever, sender: Any?) {
		coordinatingResponder?.messageTemplate(args: args, sender: sender)
	}
}

Anywhere I need a custom behavior or specific handler for this method, I simply override messageTemplate and…done.

Inter-connect with Coordinator

Remaining issue to solve: if Coordinators are controlling the UIVCs, then in order for the bubble-up to work, each UIVC instance needs to know what is its (optional) parent Coordinator.

Simple with little help from ObjC runtime:

extension UIViewController {
	private struct AssociatedKeys {
		static var ParentCoordinator = "ParentCoordinator"
	}

	public var parentCoordinator: Any? {
		get {
			return objc_getAssociatedObject(self, &AssociatedKeys.ParentCoordinator)
		}
		set {
			objc_setAssociatedObject(self, &AssociatedKeys.ParentCoordinator, newValue, .OBJC_ASSOCIATION_RETAIN)
		}
	}
}

I need to thread carefully here…

Excerpt from UIResponder.next documentation:

The UIResponder class does not store or set the next responder automatically, instead returning nil by default. Subclasses must override this method to set the next responder.

UIView implements this method by returning the UIViewController object that manages it (if it has one) or its superview (if it doesn’t);

UIViewController implements the method by returning its view’s superview;

UIWindow returns the application object, and UIApplication returns nil.

So I need to override UIViewController.next and jump to the Coordinator if the UIVC.parentCoordinator is not nil. Otherwise, I need to replicate exactly what documentation describes:

extension UIViewController {
	override open var coordinatingResponder: UIResponder? {
		guard let parentCoordinator = self.parentCoordinator as? UIResponder else {
			return view.superview
		}
		return parentCoordinator
	}
}

Lastly, on the Coordinator level:

open class Coordinator<T>: UIResponder {
	open var parent: Any?	
	
	override open var coordinatingResponder: UIResponder? {
		return parent as? UIResponder
	}
}

Benefits

The main benefit is that this entirely removes the need for repeated mediating-only Delegate patterns. This is huge saving in number of code lines in large, complex apps. Plus it simplifies things immensely. Take a look at the updateData method in HomeController.swift in the example app. It’s heavily commented and it’s excellent example how you can implement seamless data updates.

Second: unit testing is trivial for message like this: showMarkets(node: Node, sender: Any?). The UIVC using such messages is also easy to test, as you need to supply input that’s completely in the domain of the given VC, no other dependency at all. All the data each VC needs are those marked as local data model, which are injected into it.

Even if the data fetch message has completion closure (escaping or not) that returns requested data back, you know exactly what the completion arguments are and can write tests for each variant.

One advice though: don’t go crazy with this. Use it only for messages that span multiple levels of hierarchy. If you have close parent-child containment for some UIViewController then please do use Delegate pattern for that.

I have not seen any performance issues with coordinatingResponder but still — let’s not overcrowd the UIResponder space more than it’s necessary.

Third benefit is related to popups/popovers since they are not part of the flow you (or at least I) would except. UIResponder.next for the presented UIVC is not going through presentingController as I expected but instead goes directly to window. Which means that if you present a UIVC you break the chain. But if you wrap your popups in their own Coordinator (which I consider the correct approach), you have full message bubble-up all the way to ApplicationCoordinator and do not interfere with UIKit behavior at all.

Downsides

The largest: you can’t use Swift-only types for message arguments since they must be representable in Objective-C. Thus you can’t use things like Swift enums or structs for arguments.

Solution for this is to wrap your structs and enums into a simple class and then box / unbox as needed.

struct Color {…}

class ColorBox: NSObject {
	let unbox: Color
	init(_ value: Color) {
		self.unbox = value
	}
}

extension Color {
	var boxed: ColorBox { return ColorBox(self) }
}

Moreover, even class-based model object must inherit from NSObject or implement NSObjectProtocol on their own. Otherwise you will get strangely sounding error saying:

Declarations from extensions cannot be overridden yet

The message itself sounds like a temporary issue with Swift so I hope it will be gone at some point in the future. For me personally, this is not an issue at all as in larger apps I use Core Data for persistence thus all model objects are subclasses of NSManagedObject. But if you have gone entirely with structs, this may be a deal breaker. Even then though, I believe that extra box/unbox steps needed are worth it for other benefits.

Second issue: Your message overrides must be in the original class definition due to Swift limitations at the moment. So you can’t place them in the class extension, where I would very much like them to be.

Third: in most cases you need to wait until viewDidAppear in order to use this system. This is because that’s the only moment I found that UIView.next is always reliably set for all the views in the nested hierarchy. I first thought didMove(toParentViewController:) could also work but found issues with it too so fell back to viewDidAppear.

In conclusion

The beautiful result of this architecture was that moving display VC from one coordinator to another required absolutely no changes in the VC itself. Only at the Coordinators to instantiate the controller and to process the output. Which again required relatively small amount of changes.

This approach of environment-agnostic VCs gave me large degree of freedom in the mentioned app with 100+ controllers since a good deal of them was moved around during development.

The high-level UI architecture of the app changed from UITabBarController to UISplitViewController and ended with entirely custom-made TabBar-look-alike powered by subclassed UINavigationController which came up one (full-time) month in. During all that, I did not need to change a single line in any of the display VCs.

Further — many of those display Controllers shared one or few actions that had to end up at the same high level object, similar to the Buy Now example.

All in all, I hope you will give my Coordinator approach a chance. This entire mini-library is one single file so it’s almost a crime to use it as Cocoapod and waste LLVM’s time ;) although you can if you want to.

Feedback through PRs and on Twitter — I’m @radiantav — is very much appreciated.

I would especially love it if any of you Swift wizards would look into this:

open var parent: Any?

///	A dictionary of child Coordinators, 
/// where key is Coordinator's identifier property
open var childCoordinators: [String: Any] = [:]

as I would you really like it to be:

open var parent: Coordinator<XX>?

open var childCoordinators: [String: Coordinator] = [:]

I received some very useful feedback at UIKonf 2017 and will continue to improve this pattern and extend the example app to show more elaborate uses, so keep it bookmarked on GitHub.

Being totally honest, they do deserve some flakk for the self.navigationController and similar stuff. Luckily, that’s in the past now. ↩︎
nod to Green Arrow ↩︎