it doesn't seem possible to get the index of the clicked path item, nor does it seem possible to associate any kind of data with each path item, What happens when you try this: -(void)pathControlAction:(NSPathControl*)pathControl {     NSPathControlItem *clickedPathItem = pathControl.clickedPathItem;     if (clickedPathItem == nil) { NSLog(@"whoops!"); return; }     NSUInteger index = [pathControl.pathItems indexOfObject:clickedPathItem];     if (index == NSNotFound) { NSLog(@"whoops!"); return;  }     //do whatever. } They deprecated the cell based NSPathControl API without introducing proper replacements as you discovered. It's been so many years I get the feeling that they are never going to improve this so it's probably pretty safe to use the cell based stuff even though it's deprecated. But if you don't want to do that your probably can associate data with path control items by subclassing and setting the path control items with some custom objects at the same time. @interface MyPathControl : NSPathControl //Each array must contain the same number of objects. -(void)setPathControlItems:(NSArray<NSPathControlItem*>*)itemsArray withRepresentedObjects:(NSArray<WhateverObject*>*)representedObjectsForEachItem; -(void)setPathControlItems:(NSArray<NSPathControlItem*>*)itemsArray NS_UNAVAILABLE; @end Or something like that. Not great but that's all I can think of.

That's the incredible thing: sender.pathItems.firstIndex(of: sender.clickedPathItem!) always returns nil, even if the clicked path item has the same address as the corresponding item in the path items array. Even sender.pathItems.firstIndex(where: { $0.description == sender.clickedPathItem!.description }) returns nil. And when executing that print statement more than once one after the other, each item always has a different address. Not sure. I don't have time to test this thoroughly but try overriding the pathControlItems setter to see if you or the system are resetting the array unexpectedly. How are you creating each NSPathControlItem? In any case as long as each NSPathControlItem URL is unique you can just hold whatever data you want to associate with each path item like so: @property NSDictionary<NSURL*,Whatever*>*representedObjectsForPathURLs; Then add a method on your path control subclass: -(Whatever*)representedObjectForPathControlItem:(NSPathControlItem*)item { return [self.representedObjectsForPathURLs objectForKey:item.URL]; } This assumes NSPathControlItem doesn't mangle your url strings after they are set.

Take out your PathControlItem subclass. Add a property on PathControl that maps the the path control item titles to your custom data (assuming each path control item has a unique title). Just change the code from my previous response to use the title as the dictionary key instead of NSURL if you aren't setting a URL. //Add this to PathControl. @interface PathControl : NSPathControl //Set this. @property NSDictionary<NSString*,Whatever*>*representedObjectsForPathItemTitles; -(Whatever*)representedObjectForPathControlItem:(NSPathControlItem*)item; @end @implementation PathControl -(Whatever*)representedObjectForPathControlItem:(NSPathControlItem*)item { return [self.representedObjectsForPathItemTitles objectForKey:item.title]; } Unless your titles aren't unique, in which case you'd have to figure out another way to do this.

Ya I'd just keep using the cell based API and suppress the deprecated warning then...and just file a bug (or wait if you already filed it). Good news is if they never acknowledge your bug they probably aren't paying too much attention to this anyway....the deprecated API seems very unlikely to break anytime soon.

So it doesn't appear to be possible to determine when a UISplitViewController is in a column resizing event. Would be great to be able to determine this to be able to optimize the number of layout passes until after the column resize event finishes... FB11775512

targetScene is nil on Mac. For my app I'll just create a new window (new window scene). On iPad I assume it just picks the most active scene but I'll have to test it.

I was able to figure this out. I had thought the directory share would auto mount on the guest but you have to mount it from Terminal on Linux.

Just to add, I make the call to -loadHTMLString:baseURL: in -viewWIllAppear:. I use a BOOL to make sure I only call -loadHTMLString:baseURL: once since viewWillAppear: can be called multiple times. This is how my code has always been. What's weird is if I move the -loadHTMLString:baseURL: call to -viewDidAppear: loading appears to be a bit faster (not as fast as it should be though, but better) even though -viewDidAppear is called after viewWillAppear. Is it just in my head or is WKWebView trying to optimize and it's actually throttling/delaying the page load? If so it seems to be trying too hard to optimize the window is visible and active and I see my spinner for way too long. Is it waiting for some window state to finish "loading' and draw on screen?

Searched developer.apple.com trying to find info about this. I cannot find anything. If there is a way to do this it doesn't appear to be documented. I filed FB12004725

Ended up making a AppKit project that uses WKWebView, and duplicated the code I need to test in the AppKit project. Using the -_setDeveloperExtrasEnabled: method works when building under AppKit.

Okay so I have two window scenes open (windows) and the auto selecting was happening in one window and not the other. I figured out how to trigger it: UITableView just starts doing this after I move the selection with the arrow keys shortly before doing a swipe delete. The focus system just acts bizarre. I really didn't need to run into another one of these UITableView bugs... errr.. I'll see if I can come up with something to prevent it tomorrow. Anyone else got anything on this?

I filed FB12007198

FB12007249

So I attempted to workaround the issue by disabling table view focus just before doing the swipe delete action...then enabling it again after a bit of a delay in -tableView:didEndEditingRowAtIndexPath: And that avoids the auto selecting, assuming I do it after a long enough delay since the focus system must be queuing all this up on timers. But if you click outside the window, then reactivate the window, the focus system just selects the first row automatically in the table view after focus is reenabled. I could suppress it by returning NO from -tableView:shouldHighlightRowAtIndexPath: or canFocusOnItemAtIndexPath: but there is no good way to determine when I should suppress the selection to workaround this issue. Anyone know a way to tame the focus system? Can I clear its queue? A method like -cancelQueuedFocusSystemUpdateRequestsTakeItEasyPlease ?

I filed FB12008627 If anyone has a workaround for this that they are willing to share I'd appreciate it.