Navigation Architecture Within Large Mobile Apps
Navigation within mobile apps is an underrated problem, similar to deeplinking. This is an area that engineers tend not to pay attention to with a small app - only to realize it’s a beast that needs to be tamed, as the number of screens and transitions grow. Both iOS and Android provide basic navigation concepts and leave putting navigation architecture up to developers. In turn, we tend to reinvent the wheel on navigation, both out of necessity, as well as due to the not invented here syndrome.
Having a well-defined app navigation strategy, with good separation of app state is key for any decent-sized app. What navigation happens between screens and components? What triggers this animation between taps and gestures? Is navigation independent of app state? Unfortunately, I’ve found that many teams only build this map once they code themselves in a corner, discovering they have built inconsistent navigation solutions that lead to bugs when the user gets in unexpected states.
Inconsistent navigation can be as visible as the app using popups, toasts, full-screen modals or pages/screens in an inconsistent way. It can mean that different animations are used between different screens. It usually also means lots of code duplication in instructing the app to navigate.
An example of an app workflow with navigation overview. Does your app have a navigation overview? If so - is it the same across iOS and Android?
Mobile and tablet navigation differences is an interesting area to think about that comes about with complex apps. Especially for larger screens and forms, mobile devices might have multiple steps or pages, while the tablet only has one. This scenario is more likely with iOS, where both the phone and the tablet sizes are well-defined.
Asynchronous navigation is a common use case that few engineers consider handing ahead of time. Under asynchronous navigation, I mean the case where something needs to finish, before navigation can continue. Logging into the application, submitting a form are all cases like this. What happens when the user attempts to navigate away during this phase? If you don’t plan and test for this scenario, the app can get into strange states. When using RIBs, Workflows provide an elegant solution to this problem.
A navigation framework or consistent navigation approach is something you’ll find yourself either building, enforcing or utilizing an existing component for, with more complex apps.
On iOS, there’s no one native navigation component you can use. While there are several smaller open source projects providing helpers around navigation, navigation is far from a solved problem on this platform. As John Sundell concludes in the article Navigation in Swift: “having a nice way to perform navigation, in a way that doesn’t paint you into corners, can be really tricky.”
Android is perhaps a step ahead. The Jetpack Navigation Architecture Component is becoming the preferred out-of-the-box library for navigation. It works well enough except for lack of support for some edge cases. Still, it’s been only released in 2018, meaning apps the previous 8 years have built their own solutions on top of Activities and Fragments, and now need to decide if they maintain those, or migrate over. Even without Jetpack, Android is more opinionated in its navigation approach with things like guidelines on the Up and Back keys and a back stack in place.
You are reading an early draft from the book Building Mobile Apps at Scale. For the final, expanded and improved content, grab the book now - it's free to download as a PDF until 31 May.
Building Mobile Apps at Scale
"An essential read for anyone working with mobile apps. Not just for mobile engineers - but also on the backend or web teams. The book is full of insights coming from someone who has done engineering at scale."
- Ruj Sabya, formerly Sr Engineering Manager @ Flipkart