Haven't seen this on Ventura. On Monterey the whole deferred thing didn't work at all but have used it on most every Ventura version without issue. Though I guess I don't have any menus attached to button bar items. I wonder if not implemented there.

I've also seen this bug. My workaround (as annoying as it is) is to create my own NSToolbar and items and enable and disable them myself as needed. Seems like the only workaround until the Catalyst devs improve the interaction between navitems and toolbaritems.

Here's some code I'm using. I grabbed it from somewhere and didn't make note of where it came from. UIPanGestureRecognizer *scrollWheelGesture = [[UIPanGestureRecognizer alloc] initWithTarget:self action:@selector(handleScrollWheelGesture:)]; scrollWheelGesture.allowedScrollTypesMask = UIScrollTypeMaskDiscrete; // only accept scroll-wheel, not track-pad scrollWheelGesture.maximumNumberOfTouches = 0; (void)handleScrollWheelGesture:(UIPanGestureRecognizer *)pan { CGPoint delta = [pan translationInView:self.view]; // delta.y will be negative if scrolling up and positive if down I think..

Seems like there's definitely some bugs in there when switching windows/window scenes. I'm just trying debug something that I bet is related to this (UITextView loses its focus when you click on another window and then back to the original window again). I've also seen oddness when a window looks like it is active but menu items aren't enabled that should be.

You aren't using NSUIViewToolbarItem in your toolbars are you? Seems to cause all kinds of problems. It ends up creating its own scene to host the view and that was the cause of my UITextView focus issues. I filed a FB (FB12182334) and seems to be a known Catalyst issue.

I just checked the only place I know of in Ivory for Mac where you can reorder something in a UITableView (settings -> accounts) and it works. Do you have a test app I can look at where it fails?

You likely need create a UIBarButtonItemAppearance and adjust the titlePositionAdjustment property then set navigationBarAppearance.buttonAppearance = buttonItemAppearance. Same for navigationBarAppearance.doneButtonAppearance and navigationBarAppearance.backButtonAppearance. For the back button I had to multiply the vertical value by -1.0 to get it to be the same as the other properties. Then lastly had to apply the full appearance to the navigation bar: navigationBar.standardAppearance = navigationBarAppearance navigationBar.scrollEdgeAppearance = navigationBarAppearance

Nice fix. In my case I used some appkit code to create the toolbar item view instead of using UIView. It would be far nicer though if I could just use a subclass of UIView again. I just tested my sample app on Sonoma/Xcode 15 and it looks like they fixed the bug. Would be nice if there were actual release notes for Mac Catalyst code. Will experiment with your fix in my app. Thanks for posting it.

I ran into this issue recently and found a workaround to this. Don't attach the menu to the bar button item. Instead use a UIButton as the custom view (sorry about the bastardized ObjC code): let optionsButton = [UIButton buttonWithType:UIButtonTypeCustom]; [optionsButton setImage:optionsImage forState:UIControlStateNormal]; optionsButton.showsMenuAsPrimaryAction = YES; optionsButton.menu = menu; optionsBarButtonItem = [[UIBarButtonItem alloc] initWithCustomView:optionsButton]; I want to saw if I changed the button type to .system then I got the same 'Loading...' menu item forever. But when it is custom seems to work. Of course now the bar button item behaves a little differently when the window isn't active so you'll have to write code to tint it to look inactive as needed. But hey the menu works.