So returning to this issue after while I made the following discovery: The image was parsed from a PDF stream. Data was obtained using the CGPDF APIs. The decode array appears to be explicitly included in the PDF file but for some reason it wasn't in the stream dictionary. Around the time when I wrote this I think I just grabbed a copy of the image data, saved it, and starting messing with it using the Accelerate APIs/NSBitmapImageRep in a small sample project.. Looking at the PDF spec there are default decode arrays for color spaces. Passing the default decode array as documented by the PDF spec to CGImageCreateWithJPEGDataProvider and it works. No need to to convert with vimage at all.

This should do it. NSPopUpButton *popupButton = [[NSPopUpButton alloc]initWithFrame:NSZeroRect]; [popupButton addItemsWithTitles:@[@"Animal",@"Dog",@"Cow"]]; popupButton.bezelStyle = NSBezelStyleFlexiblePush; popupButton.showsBorderOnlyWhileMouseInside = YES; [popupButton sizeToFit]; It should be easy enough to translate my Objective-C to Swift if needed.

I filed FB20272813

FB20272917

Nope I gave up on it.

just watched the "Build an appkit app with the new design" video. There is a section on the scroll edge effect but there is no mention how to deal with it. How can I customize my drawing when my view is inside the "scroll edge effect" There was stuff about Split View, toolbar items, but nothing about collection view.

Anyway so I can do the following to basically "disable it": Continue drawing my section header background color in -drawRect: (windowBackgroundColor works for me) Instead of using NSColor +headerTextColor: for the text In the header view use colors that aren't dynamic like: +NSColor.whiteColor for the text color in a dark NSAppearance +NSColor.blackColor for the text color in a light appearance. So either make a custom color in an Asset catalog for the above or just override -viewDidChangeEffectiveAppearance: and change the NSTextFields textColor directly based on the current appearance. I'm just drawing over the scroll edge effect rather than disabling it. But that'll have to do.

so it looks like my NSView subclass which is my overrides draw rect. I wrote this like 7 or 8 years ago and forgot.. And in -drawRect I used NSColor +windowBackgroundGroundColor to fill the section header background. I must've added this because text in the section header was probably really blurry on non-retina displays. The NSTextField inside the section header is using the headerTextColor FWIW. So it appears Liquid Glass animation thing changes the top header text from black to white at certain points in the scroll. Not sure why, seems to be when section 0 scrolls on screen (even if we are not really even close to the top of it). Looks like maybe it's misinterpreting the background. Only a little bit of a collection view icon overlaps the section header (but the background is mostly white). The text should only turn white if it was overlapping a truly dark background. Not just like a partial overlap with a small icon in the collection view. Anyway if I remove my fill code in draw rect I see the Liquid Glass thingy draw a glass/shadow blur behind it so you can see the white text a bit. With windowBackgroundColor it was completely blending in. But even after removing my background fill...when the text turns white it still seems like a glitch. Sometimes the text doesn't reappear at all (when I scroll all the way to the top for instance and the header is completely behind white background, the text stays white) so I'd still like to disable. Is there good reliable override point for glass state so I can change the text color? I was unable to find any API in NSCollectionView header, NSSCrollView header to detect the scroll edge effect state?

Just to add: Continue drawing my section header background color in -drawRect: (windowBackgroundColor works for me) Oh right NSColor header file says not to use windowBackgroundColor for drawing so I'll pick something else. But avoiding the dynamic system colors in the collection view header view and adapting to light/dark mode manually does the trick.

@storj Cool story. For whatever reason I'm not getting email notifications when people respond to my threads. Still think it would be great if building with the 'Debug Configuration' caused the same permission error to accurately simulate the behavior you'll get in the wild but maybe there is a good reason why Apple doesn't want to do this. I dk.

Additionally, the up-down arrows are drawn even when the button isn’t hovered over. Hmm prior to Tahoe the arrows did draw even when the mouse wasn't hovered inside. Upgrading to Tahoe this does not happen. I just verified this change in behavior in a test project (using the code from my previous post): Add UIDesignRequiresCompatibility to Info.plist and set it to YES. Run the app. Arrows draw even while mouse is not hovering over it. Change UIDesignRequiresCompatibility entry back to NO and the arrows do not remain. So they changed stuff in macOS 26. Maybe there is a way you to get the pre Tahoe behavior if you play with some of the button properties. Someone from Apple should know. If there is no way to get this behavior for "free" on Tahoe you could always subclass. I don't think it should be too hard. . In the SwiftUI.Form style, the pop-up button shrinks its width to match the width of each option when the selection changes IMO I don't think a pop up button should adjust its width based on its selection b/c that can create a moving target for the user. I think it should take the width of its widest entry, or settle on a reasonable width and if there is an option with a long title let it truncate if that one option is selected. But what do I know I'm just a peasant developer :) You could resize on selection change if you want though.

FB20489224

So I just spent quite a bit of time restructuring things in my app to use the new AppStore.requestReview(in:) My app is all Objective-C so I had to add a single Swift file just wrap the single class method in a @objc wrapped method. Why they can't just declare the AppStore.requestReview method @objc is beyond me. Then I had to sandwich an NSViewController in the mix. Before SKStoreReviewController +requestReview did not rely on the presence of a view controller (SKStoreReviewController always shows the request in a separate alert). But the new API has a NSViewController parameter that is not optional And guess what... after doing all that I discovered the new AppStore.requestReview(in:) does the exact same thing as the deprecated SKStoreReviewController +requestReview. The NSViewController parameter which is not optional is completely ignored and the review is presented in a separate alert just like SKStoreReviewController. It is not presented as a sheet. What a complete waste of time. Seriously who is designing these APIs....who deprecates something with another method that does the exact same thing as the old method....the only thing the new method does is require Swift.

Swizzle -_axPostPageChangeNotification: and don't call the original implementation avoids the crash... you're welcome

Interestingly Preview.app seems to avoid the crash but they left the bug in for everyone else. cool.