the semi-transparent blur bleeds into the entire section. I just ran into this in one of my apps after scrolling a collection view a bit. Luckily I was attached to the debugger and was able to debug the view hierarchy. I discovered it to be an instance of a private class called NSScrollPocket which gets added to the NSScrollView. I set it hidden with: po (void)[0x977e0b480 setHidden:YES]; The blur over the section went away. Then I called setHidden:NO and it came back. Usually the scroll pocket appears to be near the top where the pinned section header is but I guess sometimes they have one over the entire section rectangle. So maybe we can workaround with an NSScrollView subclass like: -(BOOL)_isPotentialSubviewOuttaPocket:(NSView*)subview { Class scrollPocketClass = NSClassFromString(@"NSScrollPocket"); return (scrollPocketClass != nil && [subview isKindOfClass:scrollPocketClass]); } -(void)didAddSubview:(NSView*)subview { [super didAddSubview:subview]; if ([self _isPotentialSubviewOuttaPocket:subview]) { // outta pocket subview.hidden = YES; } } But if AppKit sets the hidden property on the scroll pocket at various times maybe we need to just prevent NSScrollPocket from entering the view hierarchy..meh or perhaps we can use a sledgehammer to make sure instances of NSScrollPocket remain hidden. might have to put it on the grill and sizzle, I mean swizzle that thing

Thanks a lot for responding. Why are you using "/Contents/Applications/"? TBH I can't remember exactly why because I set this up ~7-8 years ago. I think I might've used this path because the helper app declares NSServices in the Info.plist and I was unable to get the these services to appear in the Services menu until I changed the path to /Contents/Applications/ 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?

I suggested looking at clipsToBounds b/c I recently ran into a situation that looks very similar to your second screenshot when modifying a project that uses NSCollectionView. In my case the issue occurred when the layout used a footer view. The footer view implemented drawRect: and was filling the dirty rect. The project was written (not originally by me) but long before clipsToBounds was exposed as public API. Setting clipsToBounds to YES on the footer view stopped the issue from occurring. It was not my initial thought to check clipsToBounds because all the system blurring mixed in with the semi transparent fill color the footer view used made me think the issue was caused by something else. When I changed the footer view background color to something that stood out more like NSColor.purpleColor it made it more obvious. I first tried all sorts of other tricks. So I figured this story may be worth sharing. If you are able to narrow your issue down to something else it would be great if you shared here for knowledge building.

Have you inspected the value of clipsToBounds on views in your view hierarchy? Particularly supplementary views. If the view has clipToBounds set to NO and its -drawRect: uses the dirtyRect it can draw outside its bounds.

So using -decodeObjectOfClasses:forKey: with the NSArray class and the custom class (like I mentioned in the above post) works on macOS 12.7. // in the -initWithCoder NSSet *classesSet = [NSSet setWithObjects:[NSArray class],[MyCustomClass class],nil]; _arraypropertyOfOtherClass = [aDecoder decodeObjectOfClasses:classesSet forKey:@"myKey"]; Not sure when -decodeArrayOfObjectsOfClasses:forKey: started working but beware of this if you are deploying back to 12.7, you can't use -decodeArrayOfObjectsOfClasses:forkey: with XPC.

Going to try NSSet *classesSet = [NSSet setWithObjects:[NSArray class], [MyCustomClass class], nil]; _arraypropertyOfOtherClass = [aDecoder decodeObjectOfClasses:classesSet forKey:@"myKey"]; instead of -decodeArrayOfObjectsOfClasses:forKey: but I have to archive and notarize again and then send to the Mac with 12.7 to test. Will let everyone know if it works. Would be great to get a macOS simulator someday :)

May seem like a dumb question but I'm somewhat overwhelmed by the amount of information and all the terms and conditions as it relates to this topic. There are several threads about cross platform issues, etc. as it relates to app groups but that is not my situation. Not too long ago I asked a similar question about a different app (not new but an update) and I just stuck with the group prefix on that one but I'd like to know what the recommendation is for a new Mac app. So I have this simple situation: I have a new Mac app. Two versions: Mac App Store (sandboxed) Non-Mac App Store (not sandboxed). They both use XPC service embedded in the app. XPC service + main app need an app group. Both non-MAS and MAS use app groups with their own XPC services (not with each other) I always used teamIdprefix.groupidentifier. So I configured and registered the group identifier for the outside the Mac App Store version because Xcode prompted me to. I'm using group. prefix (iOS style group). It seems to work fine. Is that the correct way for outside the Mac App Store? If I don't use group. prefix Xcode display the identifier in red like something is wrong. And for the Mac App Store version, is it now recommended to use iOS style groups from now on? Can the recommendation on this topic be simplified to always use the iOS style app group (group prefix not team id prefix) and only use team id prefix for historical reasons if you already have a deployed app using the old style? Or am I misunderstanding something? Thanks a lot.

Well Apple has pretty much dropped Objective-C and moved fully to Swift and SwiftUI becuase its faster and better to use. Worth learning it though. Interesting claims. When you say faster are you talking about performance or the speed in which you scratch your code? While it's obvious Apple is recommending Swift all the new AppKit API I'm aware of (or at least care about) for macOS 26.0 is available to Objective-C and I'm grateful or that. And how do you define better to use? Do you think the compiler gives better/more descriptive warning/error fixes in Swift than Objective-C? What about viewing variables in the debugger? What about compiler speed? I will continue to use Objective-C until I can't. My policy is currently this: -Any Swift only frameworks that are required (like Storekit2) must be wrapped inside its own framework or library. -All Swift code must be private API. All public API is Objective-C. -Main project remains Objective-C and continues on like Swift doesn't exist. Do I recommend this for new devs? No but that has more to do with Apple's public statements. It has nothing to do with Swift being "better" in any measurable way for me. I suspect one day that may change and I won't be able to use Objective-C anymore or I'll have to get an Objective-C runtime from GNUStep or something. Or maybe I'll just move to Electron or Flutter.

My apologies this actually isn’t actually causing a crash…the exception is being thrown but apparently caught.... I hit my exception breakpoint in the debugger last night and had assumed a crash was imminent (because typically you're not supposed to recover from this type of error)

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

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

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.

FB20489224

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.

@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.