Also FB21554951

Okay so I can't seem to get an actual URL to cause this crash. Maybe there is a race condition. I wonder if you could crash other apps by evicting files from iCloud at just the right time. I am able to reproduce it by swizzling BRCloudPathComponentDisplayMetadata's -initWithDisplayName:suffix:url:icon: and calling the original implementation and passing nil for the displayName parameter which then gets passed to NSConcreteMutableAttributedString -initWithString: and crashes. Neat! Not easy to reproduce 'naturally'. Not sure if there is a way I can intercept the URL before passing it to NSPathControl -setURL: and transform it in a way that avoids this crash but haven't been able to reproduce it on my end naturally so I'm not sure what to look for in the URL. Anyone got any pointers? Otherwise one of these methods is looking like some Pollo Tropical - swizzles on the grill. CloudDocs -[BRCloudPathComponentDisplayMetadata initWithDisplayName:suffix:url:icon:] + 180 (BRCloudPathComponentDisplayMetadata.m:75) CloudDocs -[NSURL(BRCloudPathComponent) br_pathComponentDisplayMetadataWithOptions:]_b

Actually if you are using the pasteboardWriterFor.. delegates it will work fine. Unfortunately, NSBrowser has so such API (yet?) so I'm stuck. I have filed a bugreport and it's being invetigated. I filed FB5417493 way back in 2019. This NSBrowser bug still exists on macOS Tahoe 26.2 (so nearly 7 years later, happy new year). I've been avoiding the issue all this time by using the deprecated API: -(BOOL)browser:(NSBrowser*)browser writeRowsWithIndexes:(NSIndexSet*)rowIndexes inColumn:(NSInteger)column toPasteboard:(NSPasteboard*)pasteboard { // Code here.... NSArray <NSURL*>*urls = // get urls for columns/rows.. BOOL didWrite = NO; if (@available(macOS 10.14,*)) { NSArray *filenames = [self fileNamesFrommURLs:urls]; // ironically need to use deprecated API on newer OS's [pasteboard declareTypes:@[NSFilenamesPboardType] owner:self]; didWrite = [pasteboard setPropertyList:filenames forType:NSFilenamesPboardType]; } else { // I can just write urls didWrite = [pasteboard writeObjects:urls]; } return didWrite; } But I raised the deployment target so now I'm getting warning which I guess I have to suppress. There is no way to provide more than one drag image with NSBrowser without using private API because the delegate method only accepts one image: -(NSImage*)browser:(NSBrowser*)browser draggingImageForRowsWithIndexes:(NSIndexSet*)rowIndexes inColumn:(NSInteger)column withEvent:(NSEvent*)event offset:(NSPointPointer)dragImageOffset I'm not sure why there is an "Accepted Answer" on this thread because the accepted answer doesn't answer anything and only asks more questions.

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