Okay so I moved the path to Contents/Helpers. I tested in a Virtual Machine (though not a complete fresh one) but it seems the services for the app in Contents/Helpers are indeed discoverable. So over the last 8 years I either misremembered my reason for choosing Contents/Applications/ or I made a mistake or this was an issue that was resolved during that time. In any case I think the complete answer is: Use Contents/Helpers instead of Contents/Applications to get the app out of the Spotlight app launcher on Tahoe. Thanks for your help

You can quite easily see NSScrollView jitter/stall if you open a Finder window -> Icon view -> Use Groups -> yes. Make sure the folder you are viewing has a few collapsable sections. Collapse some of them. Then start vertically scrolling top to bottom. Scrolling will get interrupted often when the cursor moves over the collapsed sections. The scrollbar will freeze visible until you click somewhere and then the scrolling animation will start. You might think the horizontal scrolling of the collapsed section is colliding with the vertical scrolling and that that is causing the stutter but that's not what's happening. In my testing I can just stick a subview partially outside the bounds of the document view (but not increase the width of the document view so horizontal scrolling is not enabled) and the same stutter occurs. I went back to macOS Monterey and tried to reproduce but could not. Not sure when this bug came about. But adjusting the scroll point in a -scrollWheel: override without calling super avoids the issue and scrolling seems much more responsive. I think just calling -scrollPoint: kicks off Core Animation implicit animations(?) they seem to do a good enough job.

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? Sorry for the double reply and the re-ask, but I was still wondering about this. I am planning on changing the Path to Contents/Helpers and testing in a virtual environment in case there is any caching etc. as it related to Services to see if it works. These helper apps need their Services to be discovered by the system and is core to their functionality so if that somehow requires Spotlight indexing or being registered with Launch services or whatever I can't change the path. If you have any knowledge about this that could save me some time so I don't go on a wild goose chase that would be awesome. I could be misremembering all this because of the amount of time that has passed since I set all this up but I think I changed the path to "/Contents/Applications/" because I otherwise couldn't get the Services to show up. If Services are expected to be discovered for helper apps in Contents/Helpers/ then I'll go ahead and try moving them but if you already know that that's just not going to work for my use case that would be great to know ahead of time.

So I had to pepper a few of these around: // NSButton image scaling changed in 26.1 with certain SF symbols? if (@available(macOS 26.1, *)) { // looks better on 26.1 button.imageScaling = NSImageScaleProportionallyDown; } else { // looks better on 26.0. button.imageScaling = NSImageScaleProportionallyUpOrDown; } And one of these for a symbol image... NSImageSymbolScale symbolScale; if (@available(macOS 26.1, *)) { // large is too big on on 26.1 so let's go down to medium symbolScale = NSImageSymbolScaleMedium; } else { // need large on 26.0 symbolScale = NSImageSymbolScaleLarge; } NSImage *symbol = // make image with symbolScale and use it in a NSButton

I filed: FB21013306

I just ran into an issue where NSScrollView got stuck mid scroll. I answered in another thread here: https://developer.apple.com/forums/thread/748826?answerId=865833022#865833022 My simple override of scrollWheel: fixed the issue for me but I do lose the "rubber band" bounce back effect shouldn't be too hard to implement it but I'd rather not right now. I'll give up the rubber band bounce back in exchange for having a scroll view that doesn't freeze mid-scroll. I tried overriding +isCompatibleWithResponsiveScrolling and returning NO but it was never called on my NSScrollView subclass for some reason.

I'm not sure if our issues are exactly the same but in my case when scrolling gets stuck the scroll bar also remains visible like it's paused until I mouse click and the scroll position jumps for all the skipped frames. I dk if they are pausing a private CADisplayLink or something erroneously. Something not nice is going on with NSScrollView here! A subview sticking out partially on a horizontal edge slightly seems to trigger it for me. So regardless of whether or not I have subviews sticking out on the right or left edge of the scroll view it seems I can achieve "butter vertical scrolling" simply by overriding -scrollWheel: in the 'document view' subclass and moving the scroll point myself without calling super.... -(void)scrollWheel:(NSEvent*)event { CGFloat deltaY = (event.hasPreciseScrollingDeltas) ? event.scrollingDeltaY : event.scrollingDeltaY * self.enclosingScrollView.verticalLineScroll; NSRect currentVisibleRect = self.visibleRect; CGPoint scrollPoint = currentVisibleRect.origin; scrollPoint.y = scrollPoint.y - deltaY; [self scrollPoint:scrollPoint]; } I wish I didn't spend half a day on this!!!!

so it looks like if one subview of the document view extends past its NSMaxX(self.bounds) even partially two finger drag scrolling can stutter when scrolling is initiated from around this area of the scroll view. I don't want to widen the document view because I actually don't want horizontal scrolling in this case

Did you ever find a solution to this? I'm running into an issue where two finger scrolling on a Magic Trackpad can occasionally be interrupted. In my case the documentView is only scrollable vertically. But there is a situation (intentionally) where some subviews of the document view are positioned outside of the visible region on the x-axis (say extended a bit beyond NSMaxX of the visibleRect or before before NSMinX, not too many views though). We can call this a "row" of subviews. When the mouse is hovered over this row on the Y-axis (with the views off screen) when vertical scrolling first starts scrolling can be interrupted. I tried all sorts of things like setting clipsToBounds YES on the a bunch parent views and even the document view itself thinking drawing outside the visible area has something to do with this laggy scroll. This only occurs with two finger drag on a Magic Trackpad (not sure about Magic Mouse because I don't have one) but I have a non-Apple scroll wheel mouse and vertical scrolling never seems to be interrupted. At first I though my -scrollWheel override did it so I took it out and it but the problem still occurs.

Fixing the header view frames like this seems to work. NSSet <NSIndexPath*> *theIndexPaths = [collectionView indexPathsForVisibleSupplementaryElementsOfKind:NSCollectionElementKindSectionHeader]; for (NSIndexPath *aIndexPath in theIndexPaths) { NSView *headerView = [collectionView supplementaryViewForElementKind:NSCollectionElementKindSectionHeader atIndexPath:aIndexPath]; NSView *headerViewSuperview = headerView.superview; NSCollectionViewLayoutAttributes *headerLayoutAttributes = [collectionView layoutAttributesForSupplementaryElementOfKind:NSCollectionElementKindSectionHeader atIndexPath:aIndexPath]; if (headerView != nil && headerViewSuperview != nil && headerLayoutAttributes != nil) { NSRect headerViewRect = headerView.frame; NSRect targetRect = [headerViewSuperview convertRect:headerLayoutAttributes.frame fromView:collectionView]; if (!NSEqualRects(targetRect, headerViewRect)) { headerView.frame = targetRect; } else { // frame okay } } else { os_log_fault(OS_LOG_DEFAULT, "Header view in visible region not properly set up."); } } I'll probably wrap it in a category method

For me I had better success just calling -performBatchUpdates:completionHandler: with a nil updates block. Maybe scratch that. I'm able to restore scroll position properly after a previous reloadData call in the completionHandler: the but sometimes header views are still misplaced. After inspecting index paths for visible items and index paths for header view etc. it seems that these index path collections are completely out of whack and are nowhere near the visible collection view region. Appears there is some kind of bug in NSCollectionView where visible index paths and visible header views are not updated to match the visible region. Seems to occur when the collection view is updated/scrolled ~viewDidAppear so I'm probably experiencing the same bug when it comes to the header views not be properly shown. Also was surprised to discover that there are some situations where NSCollectionView won't call the completion block with -performBatchUpdates:completionHandler: so whatever code you put in there could potentially get dropped (shouldn't it always call the completion block and pass NO for the finished flag?). I might just umm stay away from that...

But still when transitioning back with my NSPageController to the collection view the pinned header is hidden until the transition completes but I was able to mitigate that issue by calling invalidateLayout() briefly after the navigation starts. I noticed a similar issue - headers are sometimes misplaced when they are shown for the first time (headers can be toggled in my app). I'm actually using the old flow layout still so it may be a different issue but the headers snap in place after scrolling a bit. In my case calls to invalidateLayout etc. didn't reliably help. Fixing stuff after performSelector: afterDelay worked but is ugly and I want to avoid. For me I had better success just calling -performBatchUpdates:completionHandler: with a nil updates block. My original plan was to try to fix the frames in the completionHandler which ought to be called after layout is actually ready but simply calling performBatchUpdates:completionHandler: and doing nothing seems to kick it in gear. I guess I'll have to test more to be sure though. I also use the -performBatchUpdates:completionHandler: with the nil updates block to do things like restoring scroll position which you can only do when the layout is ready.

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.