How We Centrally Manage UITabBar in Our iOS Apps

Imagine you have dozens of screens in your apps. Some of them need to show the tab bar and others don’t. How complicated it is if we handle it one by one on every screen. It can run the risk of being buggy.

Photo by charlesdeluvio on Unsplash

Background

In Stockbit apps, the tab bar is shown and hidden on specific screens. At first, developers were following several separate approaches: whether using hidesBottomBarWhenPushed, manipulating tabbar.frame, or setting tabbar.isHiddenflag. Those approaches are sometimes managed by view controller initializer, viewDidLoad(), viewWillAppear(), or just before pushing the view. They’re spread over the project so it is difficult to control and yield known issues that it has many scenarios of the buggy tab bar, when it is sometimes shown while it’s not really intended to or vice versa.

Showing/hiding the tab bar in our apps

Here are some examples of buggy tab bar scenarios and some developer’s struggles that can happen if implementing those three approaches in one project:

Example 1:

Let’s say we have a Company Page on which the designer wants the tab bar to be shown over there regardless of whether the previous screen shows the tab bar or not.

The scenario of the tab bar being hidden and shown

Stream-Comment Page’s tab bar is hidden by setting hidesBottomBarWhenPushed it to true when pushing it from Stream Page. It can be a struggle to show back the tab bar when Company Page is pushed from Stream-Comment Page even if we set hidesBottomBarWhenPushed it to false. The image below explains it.

https://stackoverflow.com/a/5641671

Example 2:

Still using screen flow on the example above. Imagine that developer A uses tabbar.isHidden flag to hide the tab bar on Stream-Comment Page. Unfortunately, developer B didn’t notice that and tried to show the tab bar on Company Page using tabbar.frame. Any value set to tabbar.frame will never show the tab bar because basically, it is hidden 😂

And also, showing/hiding the tab bar using tabbar.isHidden is actually disliked by many developers because it just appears and disappears in an instant. We can’t implement animation using that approach.

Example 3:

Let’s say our Company Page is a reusable view that any entry point could navigate into it. We set tabbar.isHidden to false and set the correct frame to tabbar.frame inside the Company Page initializer to force it always show the tab bar. But unfortunately, we can not control if tabbar.isHidden or tabbar.frame is overridden just after creating a Company Page instance from another class. It can lead to bugs as well.

A reusable view of the Company Page can be entered through several entry points

Our Solution

1. Make a standardized method to show/hide the tab bar
We make an extension to UITabBarController to create a method for showing and hiding the tab bar. Only use setTabBarHidden(_:animated:duration:) the method to show/hide the tab bar. No more using hidesBottomBarWhenPushed, tabbar.isHidden, or tabbar.frame manually to the code.

2. Centralize showing/hiding tab bar in one place
On our project, we have a tab bar as the root of our main app. Each tab has a navigation controller. We create a class, let’ say MainTabBarNavigationManager, conform it to UINavigationControllerDelegate, and set every navigation controller’s delegate to its instance. Decide whether the view controller being pushed should show or hide the tab bar inside it.

Diagram for central management of showing/hiding the tab bar. Disclaimer: This storyboard is an illustration. We don’t actually use it.

Controlling which screen should show/hide the tab bar is now being managed inside MainTabBarNavigationManager.

Result

Since it was released 5 months ago until this article is published, we found no major issues related to the tab bar (like the tab bar missing or the tab bar suddenly show not on the proper screen). Thus, we can focus to develop other features instead of bug-fixing the tab bar continuously 😁