As you discovered UIAction just takes a block with no keyboard shortcut support and UIKeyCommand takes a selector and has no ability to set a target (UIKeyCommand just goes through the responder chain). For a top level action like "Show Settings" invoked from the menu bar it seems silly to me that the entire responder chain needs to be enumerated but that's how they decided to implement it in Mac Catalyst. A NSMenuItem in AppKit world can specify a target but for whatever reason they made the context menu/menu bar APIs a little weird in UIKit/Mac Catalyst. I believe the AppDelegate is supposed to participate in the responder chain but don't think it does on Mac Catalyst which is why the menu bar item isn't validating. Add your showPreferences method on UIApplication in a Swift extension or Objective-C category instead (UIApplication is in the responder chain). So long as nothing else in your responder chain implements a selector that collides with that name the UIApplication should always get it.

Guess I'm going to have to try to do it with Javascript which is going to be difficult because media is often placed in iframes and communicating with user scripts across frame boundaries properly is kind of difficult. Also is there a way I can execute a script (from the native app) on all frames (without knowing of the existence of iframes)? Ideally something like -evaluateJavaScriptInAllFrames:inContentWorld:perFrameResponseHander:completionHandler: I can install a user script on all frames but when the native app wants to manipulate something in a subframe (say from a UIButton press), it doesn't seem like I can get ahold of a WKFrameInfo describing the iframe outside of the WKScriptMessageHandler callback. or...Is there a place in AVFoundation where I can pick up WKWebview playback events to avoid using javascript?

Try setting the passthroughViews property on TipUIPopoverViewController's popoverPresentationController https://developer.apple.com/documentation/uikit/uipopoverpresentationcontroller/1622312-passthroughviews?language=objc Include the view controller's view that you are presenting in the array. tipUIPopoverViewController.popoverPresentationController.passthroughViews = @[self.view]; //then present it. Unfortunately I can't test this myself because even though TipUIPopoverViewController is a view controller subclass for whatever reason they decided not to include a header file that can be imported into Objective-C which is just bizarre.

I filed FB13273243

I haven't been getting e-mail notifications for some threads I'm following lately. Not sure why. I filed a bug on this three years ago which I forgot I even filed and it just got closed as "Works as Designed. We won't fix it." Sigh.

I don't believe it is possible to do this programmatically using public API. I'm marking this as correct. If I'm mistaken feel free to reply and I'll take off the green check.

Thanks for your reply Quinn. It was FB7830262. I also didn't get an e-mail notification for your reply on this thread even though I'm watching it.

After looking into this a bit more it seems to be a Mac Catalyst issue. The HTML full screen API doesn't appear to be supported at all. If you load a page with Javascript that calls requestFullscreen on an element you will instead get a Javascript exception. You can confirm this with this simple little bit of javascript: // Function to open fullscreen mode. Attached to a button's onclick event. function openFullscreen() { //The elem is a <video> element. var elem = document.getElementById('myvidid'); if (elem.requestFullscreen) { console.log('Calling requestFullscreen'); elem.requestFullscreen(); } else if (elem.webkitRequestFullscreen) { console.log('Calling webkitRequestFullscreen'); elem.webkitRequestFullscreen(); } else if (elem.msRequestFullscreen) { console.log('Calling msRequestFullscreen'); elem.msRequestFullscreen(); } else { console.log('Calling nothing. Must be Mac Catalyst.'); } } If I run it on iPad the following logs out: Calling requestFullscreen If I run it on Mac Catalyst (Optimized for Mac) the following logs out: Calling nothing. Must be Mac Catalyst. If I create an AppKit target and run it works. -- So full screen elements is just stripped out of Mac Catalyst. Doesn't matter if you set elementFullscreenEnabled on WKPreferences to YES. Hopefully it's a bug and not "intentional behavior" to make Catalyst apps less capable.

Another related thread: https://developer.apple.com/forums/thread/738048?answerId=768059022

Yeah pretty much all you can do is wait. I filed a TSI and it got credited back and they said there is no workaround to the issue. I advise everyone impacted by this to file a Feedback with Apple which (hopefully) will cause them to treat the issue with a higher priority if they see it is affecting a lot of apps. I'm pretty sure every app using AVSpeechSynthesizer is broken on iOS 17.

NSApplicationActivateIgnoringOtherApps is deprecated in Sonoma so it seems intentional. I understand the theory that forcing yourself active can be abused and bad but I've needed to do it to workaround macOS bugs before. I use NSApplication +activateIgnoringOtherApps: to workaround some bugs in macOS before...but that's also deprecated and I haven't tested but I assume that that method doesn't work either anymore. Curious why are you calling that inside an autoreleasepool?

Changing the Global variable from let to var fixed the error but I am still curious if this behavior is intended or would be considered a bug.

Tested after upgrading to Version 15.0.1 (15A507). No change unfortunately. Did notice AVSpeechSynthesizer no longer works in the simulator though but same issues on device has all the same problems.

Thanks for your reply. I did file FB13264525

Attempting to install a WKUserScript to do this has its problems. It seems if the loaded web page has uncaught javascript exceptions it can cause my WKUserScript to stop working. The page (from the user's perspective) works fine but my user script can no longer send the native app messages. Apparently the web is the Wild West because there's a shocking number of websites that have errors on them so using javascript to monkey patch this functionality into WKWebView isn't going to work.