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.

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?

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.

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.

Nope I gave up on it.

FB20272917

I filed FB20272813

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.

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.

Yeahhh it's broken. Very annoying.

wow i haven’t got on 26 but i have plenty of nibs with autolayout constraints. hopefully they don’t ship this. i’m one of the three still using AppKit. i won’t touch SwiftUI with a ten foot pole

What about exposing Objective-C API to Swift only within the framework? Private framework API shouldn't be imported in the umbrella header

I filed: FB18281521

I met with the UIKit team last week and discussed this briefly. They explained some of the challenges that led to this decision, and that they didn’t make it lightly. I might’ve been more receptive to this change had the messaging been better. For instance, if it were explicitly mentioned in a WWDC session or, ideally, at last year’s WWDC—a year before the removal of support. They thought it was mentioned in the release notes this year, but I haven’t found it. What did they say? I'd love to know why unarchiving a nib became too much of a burden all of a sudden, to the point where they couldn't even give proper notice before removal. I don't have a Catalyst app that loads the menu bar from a nib but so many changes in recent years pulls us back instead of pushing us forward. Remember when you could just set restoration identifiers on view controllers and UIKit would restore your entire view controller hierarchy? Now why didn't they apply that same approach to scene based apps? I mean I did it but they're supposed to be the geniuses why are they making every developer repeat that code? Now they want us to type nibs by hand. What are they going to take away next?

How is the alert presented in the second UIWindow? Is it the root view controller, or is presented on the root view controller? Not sure if this works but did you try implementing the AppDelegate method: (UIInterfaceOrientationMask)application:(UIApplication *)application supportedInterfaceOrientationsForWindow:(nullable UIWindow *)window API_AVAILABLE(ios(6.0)) API_UNAVAILABLE(tvos); I heard UIApplicationDelegate is on the chopping block so even if it does work who knows how long it'll work for (IMO AppDelegate still has useful APIs that scene delegates don't cover and certain things are really quirky to do in a scene delegate) . I use a separate UIWindow to display some critical alerts too because injecting alerts in the UIViewController hierarchy can lead to some nasty bugs, especially if you run a network operation and get an error, the user might have hit a button and presented or pushed another view controller on screen in the in between but you really want to display that error. Separate UIWindow avoids a lot of potential problems about presenting on detached view controllers, interfering with the state of view controllers the error alert know nothing about, etc. ..But I let my alerts rotate. Consider whether you really need to do this. Usually you should allow rotation in both windows but if you really can't you can try implementing the method above but note on iPad with resizable windows the concept of orientation doesn't make sense if you're not full screen. If you're feeling really hacky I guess you could respond to the rotation in the alert window and just move everything where you want it to make it look like it's not rotating but I don't think I'd do that.