iPadOS 18 - June 13 2024
Let's talk about the new tabs and sidebar in iPadOS 18
Author: Nico
The new look for tab bars and sidebars in iPadOS 18. With iPadOS 18, Apple introduces a new unified architecture and design for tab bars and sidebars on iPad. Previously, sidebars were constructed using a UISplitViewController and could optionally display a tab bar in smaller window sizes. This was cumbersome, as view controllers across these two view styles would not persist. Developers had to write custom logic to restore view controllers depending on whether they were displayed in a tab view or split view controller. This changes with iPadOS 18. Apple has made significant updates to UITabBarController, which now supports displaying a sidebar as well. By default, the tab bar floats at the top of the screen and uses only text labels, essentially placed in the navigation bar’s title view area. Optionally, developers can add a sidebar button to the tab bar. When tapped, the tab bar morphs into a sidebar on the left side of the screen. Unfortunately, this change brings many complex issues, some of which I want to discuss as I try to integrate these updates into my app, Gamery. These issues are particularly frustrating for me as a developer attempting to implement this new UI. When sidebars were first introduced in iPadOS 14, it seemed like Apple was moving the iPad experience closer to that of a desktop. It was a step in the right direction. Now, it feels like they are regressing, making the app experience confusing and unnecessarily complex. I have included feedback numbers for the issues I have already filed with Apple and will update this article with more over the next days. I encourage you to file similar feedback and reference these numbers to help ensure Apple addresses these issues, or better yet, reverts these changes entirely, if you feel the same about the points I mention. You can learn all about the new tab and sidebar system here: https://developer.apple.com/wwdc24/10147
Design
Everything starts with the new design for the tab bar, which now features a capsule shape with text labels and a sliding selection indicator.
This new design might look familiar because a similar control has been used in the Photos app for a few years. Essentially, it functioned as a custom segmented control to switch between different views (Months, Year, All, etc.). Coming from that, its resemblance to UISegmentedControl is no coincidence; both share the same design philosophy. However, this similarity introduces some challenges. While both the tab bar and the segmented control look alike, they serve different purposes. Switching tabs usually changes the entire view and context, whereas a segmented control typically changes the state within a single view (e.g., in the Calendar inbox, where you can switch between all and accepted events). We will revisit this point later.
Glyphocalypse
Since the inception of the iPhone, tabs in a tab bar have always included a glyph and a label.
With the new tab style, the glyphs are gone. Glyphs play a crucial role in UX design, allowing users to quickly recognize parts of the app for fast interaction. Now, users need to read multiple text labels to find the content they want, which is slower to perceive and can cause issues in languages that generally use longer words, such as German. Additionally, because tab bars are now customizable, they can even scroll if too many tabs are added!
Who needs titles?
Feedback for confusing title behaviors: FB13840800
When using large titles, the title is displayed as you would expect.
For default inline titles, no separate title is displayed; instead, the tab itself is used to emphasize what you’re currently viewing.
When pushing a view controller, if this view controller has a different title than the tab title, a secondary navigation bar appears below the main one to display the new title. This effectively doubles the height of the navigation bar, negating any space saved by moving the tab bar to the top. To make matters worse, some apps, such as Apple’s own Podcasts app, only show the title upon scrolling when viewing a podcast, causing the secondary bar to appear unexpectedly.
If you use a large title in a child view controller, it will display even lower, effectively creating a nearly triple-height navigation bar. When you scroll up, the large title will recede, showing the title inline in the secondary navigation bar.
Another style is the large title inline, which is used by the App Store for all tabs. While this style is the most accessible, it looks odd and takes up significant horizontal space.
Less space for controls
Although Apple’s goal was to save space on the iPad screen, in reality, it makes things even more condensed. Apps need to compress actions because they take up too much horizontal space in the navigation bar. This constant adjustment of button placement in the navigation bar as windows are resized prevents users from building muscle memory. The smaller the window gets, the more items collapse.
In most cases, the search field needs to be collapsed into a glyph due to limited space. This issue can be exacerbated by the number of tabs, other actions, and the dynamic type size.
In languages like German, even more controls need to be collapsed now. For instance, the action for "New folder" is moved to the overflow menu.
Custom title views are impossible
Feedback for confusing title behaviors: FB13840800
Many apps incorporate a segmented control, logo, or other custom controls into the center title view. However, this is no longer possible without triggering the automatic creation of a secondary navigation bar. This can be particularly confusing, especially for a segmented control.
Inconsistency across system apps
We’ve seen a significant evolution in UI design on iPadOS, transitioning from tab bars only to including sidebars starting from iPadOS 14, and now having both in iPadOS 18. This has resulted in Apple’s own apps implementing different UI styles, contributing to a confusing user experience. Here are some examples: If an iPad app previously wanted to use a sidebar, it typically relied on UISplitViewController. When the window size decreased, it would switch to a traditional bottom tab bar. Many Apple apps followed this approach. Some apps still retain the split view controller sidebar functionality. They allow you to hide the sidebar, switching to a traditional bottom tab bar when the window is resized. Examples include Music and Shortcuts. On the other hand, there are apps that have adopted the updated UITabBarController, offering both a tab bar and a sidebar. Examples here include Podcasts, Files, and TV. Photos has taken a different path by removing the tab bar from its iPhone version, and consequently, the iPad version only features the sidebar in the new implementation style, without the option for an additional tab bar. These variations demonstrate the diversity in how Apple’s apps now handle navigation and interface elements on the iPad, contributing to the complexity of the overall user experience. This is truly a mess, every app looks and works different. But it gets worse...
Update, June 15: Now, this is just sad
I have just discovered the newest atrocity: The TV app. In landscape, it will only display a sidebar. In portrait, you have the choice between a tab bar and the sidebar. That's another differentiating factor for how the navigation structure can be displayed to the user. Who will understand this?
A step backwards
Some apps, like Books, have taken a step backwards by offering only a tab bar, removing the powerful sidebar that previously allowed quick selection of different aspects of your library. This change can make the iPad feel more like a larger iPhone in terms of navigation and functionality.
Multitasking makes this even worse
iPadOS now supports three navigation paradigms depending on the size of the app window, whether in Stage Manager or split view multitasking mode.
At the largest window size or in fullscreen mode, the default navigation is the top tab bar. Users or developers can switch to a sidebar appearance either programmatically or by using the sidebar button within the top tab bar. As the window is resized to be smaller, the top tab bar or sidebar is replaced by the traditional bottom tab bar.
For users, it can be confusing why the entire navigation scheme changes with window resizing, and now they must adjust to three different variations. Navigation controls can be located at the top, the bottom, or the left side (with the option to hide the sidebar!), which may not be very intuitive for users accustomed to consistent navigation patterns.
Choice
Feedback to allow to use old tab bar style: FB13840897 As a developer, you have limited control over these navigation issues on iPadOS. If you want to implement a tab bar in your app, you are constrained to using the new style, going sidebar-only, or building a custom control. You cannot revert to the old style navigation if desired. Your options are either to hide the tab bar entirely if you prefer using only the sidebar. However, this can lead to issues when the tab bar is automatically hidden in smaller window sizes, which also hides the sidebar, leaving users with no navigation options until they resize the window larger again. These limitations can pose challenges for developers aiming to maintain consistent navigation experiences across different window sizes on iPadOS.
Solution
In my opinion, Apple should reconsider this current implementation and revert to having a dedicated sidebar for iPad apps and a bottom tab bar for smaller windows. The tradeoffs mentioned here outweigh the benefits, even if many of these issues are addressed. With a bottom tab bar, Apple can still allow for user customization of tabs, maintaining flexibility while providing a more intuitive and consistent navigation experience across different window sizes on iPadOS. This approach could help streamline usability and reduce confusion among users and developers alike.
Other issues
Feedback to allow to set a title for sidebars: FB13840633
Currently, it's not possible to set a title to appear at the top of the sidebar, akin to what was possible with UISplitViewController. System apps that implement this feature do not display a title, as evident when comparing screenshots. For example, Files does display a title at the top of its sidebar (with the old implementation) while apps like Podcasts (or the example below) do not.
Feedback to remove translucent background: FB13843024
Feedback to fix incorrect layout margins: FB13842111
For some reason, the sidebar always has a translucent background, even when not in overlay mode. This transparency allows you to see navigation controller transitions, like pushes and pops, behind a blurred sidebar. Additionally, this affects directional layout margins, as view controllers are now rendered below the sidebar rather than beside it.