Yeah if NSApplication's -activateIgnoringOtherApps: method stops working this will be a problem for my app as well. I briefly replaced the to be deprecated method with -activate at some point (last year I think) but after discovering the same issue I had to revert back to -activateIgnoringOtherApps:YES

Interesting. I can't get in on macOS 27 yet. A bit too early for me and I have couple of things that need to get finished first. Hard for an indy dev to keep up! In one app I already have my own gesture recognizers I added for Force Touch trackpads years ago and it didn't interfere with the usual mouse stuff. I still override mouseDown: mouseDragged: -mouseUp: in all the 'big Appkit controls" (like NSCollectionView,NSOutlineView,NSBrowser). It's been awhile since I looked at that Force Touch gesture code so I wonder how this transition will affect that codebase. My biggest concern is Apple's most neglected control NSBrowser. Currently you have to use deprecated API to even get a dragging session to work. NSBrowser has some really old peculiar behaviors like posting live resize notifications for the window when only a column is being resized. And a lot of the browser stuff is done in the private table views which are still cell based. I think I put a hack gesture recognizer on the browser that helps me deal with some of its peculiar behaviors. I might have a swizzle or two, or three. I have so many hacks on NSBrowser I should probably get an Apple Design award for innovation. I would love to believe the changes they make to it (assuming they make changes to it) will make my life easier but I'm not very optimistic. I wonder why!

Also, Apple's own sample code for DragNDropOutlineView, which is linked to in the documentation for clickedRow, demonstrates using clickedRow in tableView(:shouldSelectRow:), which was the older version of tableView(:selectionIndexesForProposedSelection:). So if Apple's sample code uses it this way, I figure it should be fine. Great to know. Thanks for sharing that. Then it may be fine to read clickedRow in -tableView:selectionIndexesForProposedSelection: then. In my humble opinion Apple should add a note in the documentation like: The value of this property is meaningful in the target object’s implementation of the action, the double-action methods, and in the -tableView:selectionIndexesForProposedSelection:. delegate method Or maybe they just think it is so plainly obvious. I usually do my click specific stuff in the action method but given your unique requirements what you have might be the best way. I'm hesitant to offer any other possible solutions since I'm not on macOS 27 yet and things are changing. I'm definitely not looking forward to this gesture recognizer transition. I override -mouseDown: -mouseDragged: -mouseUp: etc. in like a million different places. Hope it goes easy and doesn't turn into two weeks of work just treading water.

Too bad nobody answered you. Six years later, I have a similar issue. I can't get NSPredicate +predicateFromMetadataQueryString: to work with InRange operator using dates either. In my case my app gets no results. But if I send the queryString to Finder via NSWorkspace +showSearchResultsForQueryString: Finder displays some results (though it appears inaccurate, as I know there are more files with a created date matching 'Today' than Finder is displaying). Instead of using InRange, this string works for me: kMDItemFSCreationDate >= $time.today && kMDItemFSCreationDate < $time.today(1) What's weird is if I send that string to Finder via NSWorkspace it does not work in Finder at all. So I guess the answer is to avoid using InRange with dates? There's not too much talk/examples for these old but still important APIs which enhance apps in meaningful ways!

I don't think you're supposed to read clickedRow in -tableView:selectionIndexesForProposedSelection:. Unless something has changed in macOS 27 the documentation for clickedRow states: The value of this property is meaningful in the target object’s implementation of the action and double-action methods. NSTableView is a subclass of NSControl. You should be able to pick up a click change by setting the table view's target-action instead of trying to do it in the delegate methods. Doing it in the delegate method like that might work but IMO this is cleaner and probably safer: -(void)windowDidLoad { [super windowDidLoad]; self.tableView.target = self; self.tableView.action = @selector(tableViewAction:); } -(void)tableViewAction:(NSTableView*)sender { NSLog(@"Clicked Column: %li Clicked row: %li", sender.clickedColumn, sender.clickedRow); } That will trigger on click. NSTableView does not invoke the action on keyboard navigation (at least not on macOS 26). I'm a bit worried that these AppKit changes might break a bunch of stuff. Hope not. I guess touch screen Macs are coming soon.

Thanks for responding. For some reason I didn’t get an email notification. I can’t use the editing string like that because the editing string is user controlled and isn’t guaranteed to be unique (the user can type the same editing string for different tokens which is valid for what I’m trying to do). So it looks like I’m going to have to write my own.

10 year later I filed a Feedback for this feature request 😂

If you change properties that implicitly cause the query to stop/restart on another queue (say from the main queue) the system logs out: NSMetadataQuery: has been started, but a modification to it was made from a different run loop or queue. Here's the backtrace: ( ... )

Hmm, I'll just wrap NSMetadataQuery behind my own class I think. I am assuming all properties need to be set on the operation queue, and I call start/stop on the operation queue as well.

So actually in System Settings I had the "Close windows when quitting an application" preference turned on, so the behavior I was witnessing in my testing is correct. It looks like Mail.app plays by its own rules because it decides to restore the windows anyway. It appears AppKit is doing the right thing here.

Thanks a lot for the reply! I had a bug I recently introduced in my app where I missed syncing model/UI with a selection change. I was already using the target-action but my app is pretty large and also programmatically changes the selection in many different places. As far as a I know there is no way to pick up all selection changes globally (other than the binding) so I decided to try the binding but that didn't work out as described in the original post. So instead of the binding to resolve I'm now overriding four different set methods (in addition to responding in the target-action). - (void)selectRow:(NSInteger)row inColumn:(NSInteger)column; - (void)selectRowIndexes:(NSIndexSet *)indexes inColumn:(NSInteger)column -(void)setSelectionIndexPath:(NSIndexPath *)selectionIndexPath -(void)setSelectionIndexPaths:(NSArray<NSIndexPath *> *)selectionIndexPaths Maybe overriding only two is required, not sure but if so that is undocumented and subject to change anyway. So a binding or a notification like NSBrowserSelectionDidChangeNotification would be preferred. and FBs from real-world cases like yours raise the priority on those gaps. I've been filing enhancement/bugs on NSBrowser for nearly 10 years. Searching Feedback Assistant I filed something about selection change in 2017: FB5335246 My most recent NSBrowser Feedbacks (though unrelated to this): FB22704799 FB22641162 FB5417493 FB20298148 Old school: FB5447156 -- Unfortunately NSBrowser seems to be frozen in time. I've thought about writing my own several times over the years but I'm always working on other things and I usually find a workaround for the browser (which takes a long time to write and is frustrating) so I haven't been able to motivate myself to write my own completely from scratch. I think column view is like everyone's favorite view type in Finder...so it would be great if this control got some love from Apple!

So I decided to give up on this because I don't think it is currently possible. There is a button on iPadOS "Restore Recently Closed Windows" in the upper left corner that becomes visible when you are in the app switcher... so I guess iPadOS keeps some closed windows in the openSessions set but there appears to be no way to distinguish these windows verses the archived ones in the app switcher. I could be wrong and maybe I missed something, but not worth spending anymore time trying to figure it out.

So I just discovered a related misbehavior for inherited properties. FWIW I'm in ObjC. If your superclass declares a public IBOutlet and then in your xib your subclass connects it, now Interface Builder incorrectly displays a warning triangle saying that your class has no such outlet. Example: @interface MySuperClass : NSObject @property (weak, nonatomic, nullable) IBOutlet NSMenu *menuSampler; @end @interface MySubclass : MySuperClass @end Use MySubclass in xib and connect outlet to menuSampler and I get a warning triangle. Not sure if this is required to reproduce but the superclass is in another framework.

Is it only with objC code or Swift as well ? Xcode 26.5: In new iOS storyboard project I can connect IBOutlets from the Assistant editor in Swift...looks fixed there. Connection bubbles show. But in Objective-C the connection bubbles are completely gone from source files so in ObjC the problem is not fixed, actually worse. You can connect from the Connections Inspector though, but Xcode won't display "connection" status in ObjC source. So for me, because I still use ObjC the problem is worse. Hope that's not intentional. That would be very very negative evolution. You mean typing xibs by hand doesn't make you more productive!? 😂

No problem. I also just noticed if you do the selection quite rapidly the selection box can also get stuck (no right click required). Seems to happen when collection view is grouped though I'm not sure exactly if that has anything to do with it (so in Finder "Use Groups" with section headers). Also if you mouse drag while you are doing the selection box outside the collection view (to the point where your cursor extends into the sidebar in Finder) things sometimes stop working. What things stop working? Mouse clicks. The collection view temporarily stops responding to mouse clicks. Using the arrow keys to move the selection 'fixes it' then mouse clicks start working again. My app uses an NSSplitView and has sidebar and a collection view so my app is impacted the same way. My hope is because Finder is impacted they may fix. Fingers crossed. In my app when this mouse clicking problem happens I am getting -mouseDown: in my NSCollectionView subclass (and calling super) but the collection view just doesn't modify the selection when you click on items nor does it deselect when you click on the background.