My latest workaround attempt is to override -preferredFocusEnvironments: on UITableView and if the table view has a selected row try to find the cell for it by calling -cellForRowAtIndexPath: and returning it. Hopefully that'll work.

What about the WKWebView itself? Is the_wkWebView not being retained? Do you have a strong reference to it? If the wkWebView is not nil you can try subclassing and overriding the navigationDelegate setter and set a breakpoint in it to see if some other code is setting it to nil after you assign it: //In a WKWebView subclass -(void)setNavigationDelegate:(id<WKNavigationDelegate>)navigationDelegate {     [super setNavigationDelegate:navigationDelegate];     if (navigationDelegate == nil)     {         NSLog(@"set a breakpoint here.");     } }

FB11753568

Ya I think you'd have to box all the StoreKit2 structs in classes that inherit from NSObject to access it from Objective-C, which would be pretty time consuming. Not sure why they decided to make it so difficult to use this API from an Objective-C app.

Just to add another note...the system doesn't appear to enumerating through the responder chain in the proper order when validating undo/redo commands. For example if a UITextField has focus/firstResponder status -canPerformAction:withSender: is hitting my responder implementing this workaround first and you could accidentally swallow the UITextField's undo/redos with this workaround if you're not careful... So you also have to check that a text field is first responder/has focus and if it does call through to super so you don't swallow the text field's undo/redo. Not sure why the system doesn't start validating undo/redo starting from the first responder, then enumerate responders backward until undo/redo validates. The system seems to be starting from the UIWindow and digging through the responder chain in the wrong order. Note that calling through to super from -canPerformAction:withSender: when the text field has focus will leave you with an Undo/Redo menu item that doesn't have a proper action name (it should say "Undo Typing"). This can be fixed, if you are determined enough to write even more workaround code to get the proper behavior. This is kind of a nightmare. I'm spending so much time implementing workarounds like this. Not sure if skipping AppKit with this UIKit shortcut is actually saving me anytime at all, but I'm in too deep now though.

I opened FB11749379

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.

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?

I filed FB11747430

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.

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....

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

I opened FB11733820

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.

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.