I noticed this with QLPreviewView--images for .apps take forever to load. Zip files too and I'm sure there are other file types I don't know about. I filed FB20797520 back in October. Considering making the thumbnail myself for these certain file types that I've found to be slow because this is degrading my app but I've been somewhat overwhelmed by these types of bugs I really don't want to write another one of these ugly workarounds. Kind of hoping they just fix it in a timely fashion. Fingers crossed. My app is sandboxed, and access to the files is made through the NSOpenPanel first (Macintosh HD folder). I have non-sandboxed app version of an app and QLPreviewView still takes around 30 seconds to load app icon images. In another part of my app I don't use QLPreviewView but load thumbnails with QLThumbnailGenerator. QLThumbnailGenerator seems to load the thumbnail images quickly.

Switch the box type to custom in IB, then pick the color from another box that isn't custom with the color picker (again because it looks fine at design time). Better. Is what it is

Same here on launch. All AppKit methods/functions on the call stack. Not sure what I could do to resolve.

FB21171975

Also just noticed that it isn't just the Emoji/SF symbol badge. When the folder is not empty QLThumbnailGenerator makes a folder icon with paper sticking out (indicating that the folder is not empty). When the folder is empty no paper is sticking out. So if a folder is emptied out after your app is run the icon will still show the papers sticking out like it isn't empty and vice versa. I can think of a workaround for both issues but real pita like the bread

Same issue here. QLThumbnailGenerator caches the custom Folder icon it seems....once it's loaded it seems to always reuse that image. No public API I'm aware of to clear the thumbnail cache?

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.

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.

Yup same issue here.

Appears to be fixed in 26.1 update. Nice!

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.

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

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

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.

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.