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?

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.

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.

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

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.

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.

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.

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.

I had an issue with UITableView starting on iOS 16.2 which seems similar to your issue, but may in fact not be. Are you able to get the NSException reason, name, info, etc.? https://developer.apple.com/documentation/foundation/nsexception?language=objc

Workaround is to do this in all the view controllers automatically being wrapped in the more navigation controller: -(void)willMoveToParentViewController:(UIViewController*)parent {   [super willMoveToParentViewController:parent]; #if TARGET_OS_MACCATALYST   if ([parent isKindOfClass:[UINavigationController class]])     { UINavigationController *navigationController = (UINavigationController*)parent;         [navigationController setNavigationBarHidden:YES]; } #endif }

Hmm.. just for testing I showed the UITabBar and created a UITabBarItem for each view controller. UITabBarController just starts stacking view controllers in the "More" navigation controller when there are around 8 or more view controllers. It doesn't take into account the width of the UITabBarController; I can resize the window to giant size but the UITabBar just adds additional space between all the tab bar items and keeps the "More" item as the last tab bar item even though there is plenty of room to fit all tab bar items.

Perhaps I finally resolved this. My last guess is that the UITableView for some reason started outliving the object I use to return a cell in -tableView:cellForRowAtIndexPath: which was never the case prior to iOS 16.2. I made some changes, will need to test this longer to see if I finally got this fixed since the crash is pretty hard to reproduce.

Hmm if you specify "Pad" it will show up on a Mac Catalyst build even if the "Optimize for Mac" option is being used.

Thanks for the reply, kind of a bummer. Would be cool if there was a way to configure a UIButton for the radio style on Mac Catalyst only. Or maybe as an option to UISwitch like UISwitchStyleRadioButton.

Thanks for these tips. I filed the following feedbacks related to UIDocumentInteractionController: FB11956915 and FB11956933