Routing for iOS: universal navigation without rewriting the app

What’s wrong with navigation anyway?

Almost every app has a navigation between different internal components and it seems like it shouldn’t be a problem. UIKit contains more or less convenient containers like UINavigationController, UITabBarController and a flexible way to present screens modally. We, as developers, just need to use the right tools.

However, as soon as we start implementing a navigation to a screen that’s initiated by a push-notification or a URL, things start getting complicated. Straight away we need to start asking questions like:

• What shall we do with current view controller?
• How can we switch to the different part of the app (for example, switch a tab of UITabBarController)?
• Do we have the needed screen in the navigation stack?
• When should we ignore the navigation?

We came across such issues when developing iOS applications at Bumble — the parent company operating Badoo and Bumble apps — and decided to make a set of tools to solve them for all our apps. In this article, I’ll share the ideas behind these tools and describe our approach to implement them. For a practical example, check the small demo app.

Our problems

Problems with automatic navigation are often solved by introducing a global component which knows the structure of screens in the app and decides what to do in different situations. The structure of screens is understood as the information about which containers the app has and where and how some screens should be presented.

Badoo, our first product, had such a component which worked in a similar way to the old Facebook navigation library. It was based on the idea of an association of each screen with a URL. It has now been removed from their public repository and there is a reason for that.

• Most of the logic was contained in a single class and this class was aware of the presence and the state of many components specific for Badoo…