This build adopts a new API from Xcode beta 26.2 to conditionally render the tabViewBottomAccessory on iOS 26.1. Read on for more.

If you made the choice to adopt this API in 26.0, you may have noticed that rendering an EmptyView() inside of it caused the accessory to disappear and used that to your advantage. In iOS 26.1, rendering an EmptyView() inside the tabViewBottomAccessory will not hide the accessory; its empty, glassy shell still occupies the space at the bottom of the tab view. Xcode 26.1 provides no way to work around this change in behavior.

Thankfully, Xcode 26.2 beta includes a new tabViewBottomAccessory(isEnabled:content:) API to allow controlling the visibility of the accessory on devices running iOS 26.1 or later. This beta release adopts this new API. We now have three branches of behavior for our mini-player implementation:

  • Pre-iOS 26.0: The mini-player is rendered as an overlay to match the design system of pre-Liquid Glass tabs.
  • iOS 26.0: The mini-player is rendered using tabViewBottomAccessory without the ability to control visibility. The mini-player is always visible on devices running this OS version.
  • iOS 26.1 and later: tabViewBottomAccessory is adopted with the ability to control visibility. The mini-player is hidden on the Settings tab and when navigating to music item detail views. A toolbar item is rendered in place of the mini-player in these cases.

Additionally, I’ve also noticed that the entire accessory is being recreated from scratch when navigating between tabs, losing any state it may have initialized on the previous tab. In particular, this causes our volume slider to jump a bit in its current implementation. I’ve reproduced this bug in a minimal sample project and filed FB20938254 with Apple and am exploring a workaround in the time being.