We're working around this by creating a custom UIView for bottom toolbar that contains an embedded UIToolbar. The UIView constrained to superview .bottom, and UIToolbar constrained to UIView safeAreaLayoutGuide.bottom

These attached screenshots (from the simple Xcode workspace we submitted with FB19664903) show this issue, the first screenshot is from iOS 26 beta 7 (white gap below the red bottom toolbar), the second screenshot is the same code running on iOS 18.6 (red toolbar extends behind safe area). We have an app that uses many of these bottom toolbars and I'd prefer not to have to refactor....I'm surprised this hasn't received more "me toos"

I've learned that a combination of two things seems to resolve this issue, or at least soften the effects. For dark UINavigationBar and UIToolbar backgrounds set barStyle = .black don't use UINavigationBarAppearance() to set bar colors, just set navigationBar properties colorBarTint, colorBackground, and isTranslucent = false I'm closing FB19660024, though something definitely not right here ... for example setting the navigation bar title font and color requires use of UINavigationBarAppearance() and these display glitches recur.

This is NOT corrected in Xcode 26 beta 6 / iOS 26 beta 7

This is corrected on Xcode 26 beta 6 / iOS 26 beta 7, marking FB18995026 closed, thanks!

This is NOT corrected in Xcode 26 beta 6 / iOS 26 beta 7

I’ve discovered a workaround for this one: By setting: translatesAutoresizingMaskIntoConstraints = false on the UISegmentedControl the selectedSegmentTintColor is now working.

This is not corrected in Xcode 26 beta 5

Thanks Ed, its FB18995026

@elemans I agree this is a great new feature, though my observations are a bit different Setting the badge value with .count() or .string() works for me, but I did have some struggles with colors. I believe setting the .badge property to some non-nil value early on in the UIBarButtonItem lifecycle seemed to help. For example, this code in a UIViewControllers viewDidLoad did produce a cyan on black badge with value 123: self.buttonHistory = UIBarButtonItem.init(image: ...) if #available(iOS 26.0, *) { self.buttonHistory.badge = .count(123) self.buttonHistory.badge?.backgroundColor = .black self.buttonHistory.badge?.foregroundColor = .cyan } self.navigationItem.rightBarButtonItem = buttonHistory and I found that as long as the .badge property is initialized early on to a non-nil value, like shown above (even initializing to .none), then I could subsequently change its value, background, and foreground colors. In my case the UIBarButtonItem is in a UINavigationBar not a UIToolbar, not sure if this makes a difference.

I can attest that AVCaptureDevice.requestAccess suffered from this same problem, i.e. crashing with a thread/queue violation when built under Swift 6. Original code: AVCaptureDevice.requestAccess(for: AVMediaType.video, completionHandler: { granted in if (granted) { DispatchQueue.main.async { [weak self] in // do something } } }) Modified code: Task { let granted = await AVCaptureDevice.requestAccess(for: .video) if (granted) { Task { @MainActor in // do something } } } This code pops a permission dialog for using the camera, and as soon as the Allow button is clicked the app would crash.