Maybe it's not possible? I just tried to do it in the "Developer" app which I believe is a Catalyst app and it won't collapse the sidebar via drag. Notes, Mail, Xcode, Finder, etc. all allow you to collapse the sidebar by dragging the split.

I duped this thread in a feedback: FB11689969

So I deleted the "Push Notifications" entry in "Signing and Capabilities" then added it back. Remote notifications are working again. 🤷‍♂️

Actually I get the behavior I expect by default as long as the selected row isn't also focused (the collection view is configured to have the selection follow focus, which is something I want). Only thing I can think of is to manually implement the expandable row's UICellAccessoryOutlineDisclosure actionHandler, set selectionFollowsFocus to NO before I collapse the row, then set selectionFollowsFocus to YES after the animation finishes. Feels like this is way more work then it should be though.

Also not sure why focus moves to the first row (0,0) when another row is collapsed with the selected and focused row. If the collapsed parent (just clicked) isn't selectable but is focusable the focus should move to the clicked row. IMO it shouldn't jump to index path 0,0. Overriding this behavior is not as straightforward since the focus API gives developer's limited control. I have to hold the clicked index path in a property and return it from -indexPathForPreferredFocusedViewInCollectionView:

So I can make the search bar and scope bar look reasonable by setting UISearchBar's backgroundImage and scopeBarBackgroundImage properties to a image of just a solid color, but my app also sets navigationItem.prompt when the UISearchController is active, and the background color of that view _UINavigationBarModernPromptView is white... Edit: setting UINavigationBarAppearance's backgroundColor allows me to get override the white background.

So I'm going with the workaround above (for now at least). You have to be careful to ensure that you only set the fallback weak reference once (I'm doing it in -didAddSubview: from a UITableView subclass) and don't accidentally set it while the tableview is in the process of being torn down. Attempting to set it from within -parentFocusEnvironment can cause the weak reference crash since the focus system is very aggressive and it interrogates the focus environment during/after it has been removed from the window.

So the "unemphasized" state happens even if the selected rows are in the active focus environment if a table view cell is swiped. There doesn't seem to be anything in the UICellConfigurationState to indicate this state, nor the trait collection. I don't see any properties that make it easy to detect for this "unemphasized" state. The workaround I came up with (limited testing) is to inspect the background color on the background configuration directly and compare it against the default tint color when the window is active....(using -traitCollectionWithActiveAppearance: and -performAsCurrent:). Code is pretty ugly.

I opened FB11733820

Ah nice I found the answer. I have to override the -validateCommand: method.

Oh my I just discovered that UIScrollView doesn't have any implementation at all for scrolling with the arrow keys. Guess I'll try to have to subclass and try to implement it myself....

Thanks a lot for the reply. I filed a feedback with a sample project and screen capture FB11745181. In the sample project I used a plain UIScrollview. Tabbing into it doesn't work. After fiddling with the quick sample I noticed that arrow key scrolling doesn't work at all (even when clicking on the scroll view). In the app I'm actually working on I'm using a WKWebView which does have arrow key scrolling implemented but was requiring at least a mouse click on the web view before it started working (couldn't tab in). It's hard to say what might be happening without a sample project, but — on the Mac — keyboard navigation is going to change first-responder, not focus. That's what I thought. I fiddled with calls to -becomeFirstResponder with no luck (on the view controller and on the web view itself). Subclassing and returning YES from -canBecomeFocused on the view is all I needed to do to get focus to move over with the tab key, without messing with the responder chain at all. But I also needed to implement my own key commands to actually do the scrolling now because the default web view ones don't work after these overrides.

I filed FB11747430

So tried to workaround the issue by implementing -validateCommand: but apparently this isn't called on menu bar items provided by the system. What am I supposed to do reimplement the entire Edit menu?

This works around the problem. I'm sharing it with the community because I'm that type of guy: Add the following methods in the responder chain: -(void)redo:(id)sender; -(void)undo:(id)sender; Implement the methods like so: -(void)redo:(id)sender {     NSUndoManager *undoManager = self.undoManager;     [undoManager redo]; } -(void)undo:(id)sender {     NSUndoManager *undoManager = self.undoManager;     [undoManager undo]; } Validate the methods: -(BOOL)canPerformAction:(SEL)action withSender:(id)sender {  if (action == @selector(undo:))     { return self.undoManager.canUndo; } else if (action == @selector(redo:)) { return self.undoManager.canRedo; } return [super canPerformAction:action withSender:sender]; } Then the undo/redo menu items in the menu bar will update with the action name proper. You're welcome.