I just ran into an issue where NSScrollView got stuck mid scroll. I answered in another thread here: https://developer.apple.com/forums/thread/748826?answerId=865833022#865833022 My simple override of scrollWheel: fixed the issue for me but I do lose the "rubber band" bounce back effect shouldn't be too hard to implement it but I'd rather not right now. I'll give up the rubber band bounce back in exchange for having a scroll view that doesn't freeze mid-scroll. I tried overriding +isCompatibleWithResponsiveScrolling and returning NO but it was never called on my NSScrollView subclass for some reason.

I filed: FB21013306

So I had to pepper a few of these around: // NSButton image scaling changed in 26.1 with certain SF symbols? if (@available(macOS 26.1, *)) { // looks better on 26.1 button.imageScaling = NSImageScaleProportionallyDown; } else { // looks better on 26.0. button.imageScaling = NSImageScaleProportionallyUpOrDown; } And one of these for a symbol image... NSImageSymbolScale symbolScale; if (@available(macOS 26.1, *)) { // large is too big on on 26.1 so let's go down to medium symbolScale = NSImageSymbolScaleMedium; } else { // need large on 26.0 symbolScale = NSImageSymbolScaleLarge; } NSImage *symbol = // make image with symbolScale and use it in a NSButton

I could be remembering wrong and maybe just switching the path would resolve but is Spotlight indexing required to get the .app's NSServices to appear in the Services menu? Sorry for the double reply and the re-ask, but I was still wondering about this. I am planning on changing the Path to Contents/Helpers and testing in a virtual environment in case there is any caching etc. as it related to Services to see if it works. These helper apps need their Services to be discovered by the system and is core to their functionality so if that somehow requires Spotlight indexing or being registered with Launch services or whatever I can't change the path. If you have any knowledge about this that could save me some time so I don't go on a wild goose chase that would be awesome. I could be misremembering all this because of the amount of time that has passed since I set all this up but I think I changed the path to "/Contents/Applications/" because I otherwise couldn't get the Services to show up. If Services are expected to be discovered for helper apps in Contents/Helpers/ then I'll go ahead and try moving them but if you already know that that's just not going to work for my use case that would be great to know ahead of time.

You can quite easily see NSScrollView jitter/stall if you open a Finder window -> Icon view -> Use Groups -> yes. Make sure the folder you are viewing has a few collapsable sections. Collapse some of them. Then start vertically scrolling top to bottom. Scrolling will get interrupted often when the cursor moves over the collapsed sections. The scrollbar will freeze visible until you click somewhere and then the scrolling animation will start. You might think the horizontal scrolling of the collapsed section is colliding with the vertical scrolling and that that is causing the stutter but that's not what's happening. In my testing I can just stick a subview partially outside the bounds of the document view (but not increase the width of the document view so horizontal scrolling is not enabled) and the same stutter occurs. I went back to macOS Monterey and tried to reproduce but could not. Not sure when this bug came about. But adjusting the scroll point in a -scrollWheel: override without calling super avoids the issue and scrolling seems much more responsive. I think just calling -scrollPoint: kicks off Core Animation implicit animations(?) they seem to do a good enough job.

Okay so I moved the path to Contents/Helpers. I tested in a Virtual Machine (though not a complete fresh one) but it seems the services for the app in Contents/Helpers are indeed discoverable. So over the last 8 years I either misremembered my reason for choosing Contents/Applications/ or I made a mistake or this was an issue that was resolved during that time. In any case I think the complete answer is: Use Contents/Helpers instead of Contents/Applications to get the app out of the Spotlight app launcher on Tahoe. Thanks for your help

This is still a thing. I have a UIToolbar with some buttons in it. They are are created in Interface Builder. One is hidden. At runtime, something happens and I set hidden = NO to show that one button that is hidden and nothing happens. I see UIToolbar is now a wrapper on top of SwiftUI on iOS 26 so while this is disappointing this type of bug isn't really shocking. @N. Holzschuch Thanks for sharing. Setting the items like it's iOS 15.0 does the trick. I tried just resetting the property with a copy of the .items array but it didn't work. Adding a dummy bar button item then removing it seems to be required.

Ya using +groupWithItemIdentifier:images:selectionMode:labels:target:action: avoids the crash. So under this API design am I permitted to do this? NSToolbarItemGroup *readStatusToolbarGroup = [NSToolbarItemGroup groupWithItemIdentifier:itemIdentifier images:@[mailOpenEnvelopeImage, mailBadgedEnvelopeImage] selectionMode:NSToolbarItemGroupSelectionModeSelectOne labels:@[@"Read",@"Unread"] target:nil action:nil]; NSUInteger i = 0; for (NSToolbarItem *aItem in readStatusToolbarGroup.subitems) { if (i == 0) { aItem.action = @selector(markRead:); aItem.toolTip = @"Tooltip for this one.."; } else if (i == 1) { aItem.action = @selector(markUnread:); aItem.toolTip = @"Tooltip for this one..."; } i++; } This API design is not very good TBH. I'm not really happy about having to rewrite the code to build four toolbar groups (I already did this work). I'd like to move forward instead of running in place all the time. BTW the appearance of the toolbar groups don't look particularly special when created via the group class constructor so I dk what's with all the system appearance talk. It isn't clear to me why the underlying implementation can't build the toolbar properly in the same way from -setSubItems: These toolbar items just get images and titles I'm not even using a custom view for the toolbar item.

Also I lose the ability to set the itemIdentifier property on subitems when creating the NSToolbarItemGroup with the class constructor. Presumably the subitem is still the sender when NSToolbarItem invokes its action? Being able to define itemIdentifier on subitem can sometimes be useful. I guess I can use tag instead but feels like a lot of busy work here. Err

This API is broken in AppKit land as well. Also experienced another exception when rerunning the app... the system throws up an alert like: "App crashed while reopening windows - Do you want to reopen windows again" error. If you choose to reopen windows in the alert we get another exception: ** Assertion failure in -[UINSAppKitTerminationController launchingDidComplete], UINSAppKitTerminationController.m:71

So using the class constructor is pretty much the only reasonable way around this. I'm marking this reply as the correct answer. You can also avoid the crash by setting UIDesignRequiresCompatibility to YES in your Info.plist and use the pre Liquid Glass UI. maybe I'd file a bug but I don't think Apple responded to like 95% of my Catalyst bugs I reported in the past. I must have reported more than a dozen so I'm not going to be filing this one. FYI if you migrate to the group class constructor... if you have to do any per item tweaks you can apparently just dig in the subitems array right after you create the GroupItem (to set different actions on particular subitems etc.) HOPEFULLY they don't release an update that breaks that.

Appears to be fixed in 26.1 update. Nice!

Yup same issue here.

Because Mac Catalyst doesn't provide a great way to control width constraints of Split View controller columns (unlike the more sophisticated NSSplitView) I was proportionally computing a fraction min width/max width in -viewWillLayoutSubviews. For example: say I want to express a max primary column width as fraction. Sidebar can only grow to 1/2 of the Split View controller width we have to use this property: maximumPrimaryColumnWidth But there is no maximumPrimaryColumnFractionWidth property. Hard values for max column width only makes sense IMO if your window isn't resizable (hard min may be fine though so long as the window min width is properly configured). So to express maximumPrimaryColumnWidth as a fraction you have to compute it: (bounds.size.width/2.0). I was doing this in -viewWillLayoutSubviews and it worked fine before Liquid Glass. But apparently doing this with the Liquid Glass design wreaks havoc. Window resizing performance is much better if I take it out of -viewWillLayoutSubviews (but still not as good as it should be TBH). I'm aware of preferredPrimaryColumnWidthFraction, using the UISplitViewControllerAutomaticDimension results in columns that aren't really resizable in a way that makes sense for a Mac app. So don't set properties related to min/max column width of a UISplitViewController during layout. Very bad with Liquid Glass. Why such a performance kill? I dk? It looks like I still can't use Liquid Glass design though due to other issues. My NSToolbarItems reorder in an illogical manner when I collapse and expand Split View columns so I think I'll proceed with UIDesignRequiresCompatibility set to true for now. Plus I don't like having Split View columns you can only expand like 20-30 points.

Spent way too much time on this...grr..my workaround: -(void)updateConfigurationUsingState:(UICellConfigurationState *)state { UIListContentConfiguration *contentConfig = (UIListContentConfiguration*)[self.contentConfiguration updatedConfigurationForState:state]; if (![contentConfig isKindOfClass:[UIListContentConfiguration class]]) { contentConfig = [[UIListContentConfiguration valueCellConfiguration] updatedConfigurationForState:state]; } UIBackgroundConfiguration *backgroundConfig = [[UIBackgroundConfiguration clearConfiguration] updatedConfigurationForState:state]; UITraitCollection *traitCollection = state.traitCollection; // Focus AND active if (traitCollection.activeAppearance == UIUserInterfaceActiveAppearanceActive && state.isFocused) { backgroundConfig.backgroundColor = self.tintColor; contentConfig.imageProperties.tintColor = UIColor.whiteColor; contentConfig.textProperties.color = UIColor.whiteColor; contentConfig.secondaryTextProperties.color = UIColor.whiteColor; } else { if (state.isSelected || state.isHighlighted || state.isFocused) { // need an unemphasized selection color. backgroundConfig.backgroundColor = [UIColor colorNamed:@"SomeKindOfLightGrayHereMaybe"]; } contentConfig.imageProperties.tintColor = UIColor.darkGrayColor; contentConfig.textProperties.color = UIColor.darkGrayColor; contentConfig.secondaryTextProperties.color = UIColor.darkGrayColor; } self.backgroundConfiguration = backgroundConfig; self.contentConfiguration = contentConfig; } These content configuration APIs have always been kind of an overcomplicated disaster IMO. You could try to duplicate the 'source list' selection style like Finder sidebar but I just use the current tintColor. Seems to work in my limited testing. At least I can read the text.