On iPhones: It will force the full width of the accessory view irrespective of its content Placing a view that manages its own glass – like a collection of individual glassy buttons – means that the full-width container is still encased in an outer layer of glass. There is no way to remove the outer glass layer, and it's not exposed as a property of a visual effect view, of the parent _UITabAccessoryContainer, or its parent _UITabBarContainerView. On iPads: Infuriatingly, it behaves completely different in regular width layouts. Suddenly, it doesn't draw a full width glass container around the content and starts respecting the supplied view's layout. A collection of glassy buttons starts working as intended. This all falls apart in compact layouts and starts behaving like an iPhone. The lack of configuration on this API is deeply unusual. More unusual is that there's no layout guide or similar for us to hook into to supply our own bottom accessory behavior.

The new UITabBarController APIs are great! But they leave a lot to be desired. For example, let's say I want a bottom accessory – one simple enough that it could be a UIBarButtonItem. The UITabAccessoryAPI only takes UIViews but passing a simple UIVIew or UIButton will create a new problem: now the view is stretched to be huge instead of a tiny little image-button. New approach: Show it on screen as a contextual overlay modal thing. I can do that, no problem. New problem: It won't animate down when the tab bar minimizes, like the bottom accessory does; there is no layout guide exposed that allows us to hook into this. I'd really rather not reverse engineer to grab the platter when the state is minimized and set some funky layout constraints to adapt to it, determine that it can fit (a bit irrelevant in this instance, since it's a single button), and animate into place as the tab bar animates. I know there's a new contentLayoutGuide, but it doesn't seem there's anything like what I'm looking for here. I basically just want a tab accessory view, but I don't want to commit to it being so huge. And what happens if I want multiple views here? Suddenly, this opens up the toolbar, but… having a toolbar and a tab bar in the same app is an exercise in frustration, since the tab bar will cover up the toolbar. In a different environment, I may have gone ahead and just wrapped my own UITabBar, as Steve Troughton-Smith does via his Mastodon post (can't link directly). That presents another host of issues though: iPad behavior goes out the window. I'd probably still have to dig into private APIs to get a magic pocket effect that works the same as the UITabBarController's! UIScrollEdgeElementContainerInteraction doesn't behave exactly the same as the interaction added to the tab bar by the tab bar controller. Is there any such API for this? What possible reason could there be for keeping these APIs private?

When adding a glass effect to my UIControl: let effectView = UIVisualEffectView() let glassEffect = UIGlassEffect() glassEffect.isInteractive = true effectView.effect = glassEffect effectView.cornerConfiguration = .capsule() addSubview(effectView) effectView.snp.makeConstraints { $0.edges.equalToSuperview() } effectView.contentView.addSubview(stackView) for subview in effectView.subviews { subview.backgroundColor = .clear } self.effectView = effectView I find that I get this visual effect: These controls are the only view within a UICollectionViewCell. Nothing in the hierarchy of the collectionview to the control has a background color. The grey background only seems to appear when I place the glass effect. Without the glass effect, there is no grey shading.

Sample Project In iPadOS 26 beta4, when a UISplitViewController transitions to compact layout and proposes the secondary view controller, a crash occurs: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Layout requested for visible navigation bar, <UINavigationBar: 0x1018205b0; frame = (0 0; 320 54); opaque = NO; autoresize = W; gestureRecognizers = <NSArray: 0x600000d37cc0>; layer = <CALayer: 0x600000d13390>> delegate=0x102826600, when the top item belongs to a different navigation bar. topItem = <UINavigationItem: 0x101af3b20> title='Detail' style=navigator rightBarButtonItems=0x600000011e10, navigation bar = <UINavigationBar: 0x101817680; frame = (0 0; 320 54); opaque = NO; autoresize = W; gestureRecognizers = <NSArray: 0x600000d12310>; layer = <CALayer: 0x600000d116b0>> delegate=0x102826000, possibly from a client attempt to nest wrapped navigation controllers.' When we show the primary view, there is no crash. Similarly, there is no crash on beta-3. To reproduce the crash in the demo project: Launch the project on an iPad. "Try the Demo" Tap "List-Detail Pattern" To trigger the crash, select any of the list items and switch the app to a compact layout. The crash occurs because the app will attempt to propose the secondary view controller. To avoid the crasah, refrain from selecting an item in the list and switch to the compact layout. The app will not crash because it will attempt to propose the primary view controller.

In the Console, when presenting my view in a horizontally compact environment, I see: UINavigationController for collapsing UISplitViewController about to push view controller <UINavigationController: 0x107933c00> This message repeats infinitely, until the Xcode debugger eventually says: QUARANTINED DUE TO HIGH LOGGING VOLUME Of note is that this only occurs in the beta, does not occur when using the iOS 18.x SDK, and only occurs in a compact environment. EDIT: This occurs only when setting the secondary column of a doubleColumn UISplitViewController: splitVC.setViewController(secondary, for: .secondary) EDIT 2 and WORKAROUND: If this action is deferred until after viewDidAppear, it self-resolves: public override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) if let deferredSecondaryViewController { splitVC.showDetailViewController(deferredSecondaryViewController, sender: nil) } }