Would be nice if there were actual release notes for Mac Catalyst code. +1 on that. It would also be nice to know if our bugs are being acknowledged with some communication, (if a human can tell us if the bug was reproduced on their end where they could confirm the bug and indicate that a fix is at least being worked on and is to be expected). Usually you submit a bug and all you get is crickets, no indication of whether or not a fix is a "priority" and can be expected in a reasonable timeframe. Every once in a while I get surprised but it's a very low percentage. I just tested my sample app on Sonoma/Xcode 15 and it looks like they fixed the bug I'm not sure if it's fixed entirely as I came back to this on Sonoma. But since it's triggered by the responder chain/focus system logic so it'll probably trigger differently from app to app depending on what's in the responder chain. Even if it is fixed we're gonna have to keep the workaround in place for another year for users who don't do minor updates. I actually ended on the same workaround as you so we think alike. After I confirmed the source of the bug with the swizzled code I ended up adding AppKit code to build the toolbar item. Even though the swizzling code works, building the toolbar item in AppKit to workaround this seems way safer. Using NSStringFromClass to check for the existence of a private class can break at anytime (if they change the class name, etc). But the AppKit NSToolbarItem stuff Apple really can't change even if they wanted to because it'd break too many apps.

If you are using Mac Catalyst, you could create a bundle (NSBundle) which has direct access to the AppKit lifecycle and APIs and load the bundle from Mac Catalyst (just be sure you only load the bundle when you are running on Mac Catalyst because it'll crash your app on iOS, in fact you should only add the bundle to the Mac Catalyst target). From the bundle you can call anything in AppKit (and make a menu bar item). This is a widely used technique in Catalyst apps to implement missing functionality that the framework doesn't provide. No private APIs are involved. Apple doesn't like to recommend this but I'm pretty sure SwiftUI just shims over the same APIs (related to status items and such) that they seemingly don't want us to access directly anymore, for whatever reason. Maybe they think they are "abstracting" things away to make it simpler for us but often, for me, it feels like they are tying one hand behind my back.

Can you show your code?

I tried converting a pre-trained Tensorflow model to and it also spits out the error: "For mlprogram, inputs with infinite upper_bound is not allowed. Please set upper_bound to a positive value in "RangeDim()" for the "inputs" param in st.convert(). Code: model = TFAutoModel.from_pretrained("pretrainedmodename_here") ctmodel = ct.convert(model,source="tensorflow") I also tried downloading the .h5 file locally and feeding it to coremltools convert but that also fails with the same error. How do I set the upper_bound? I'm new to this. I have tested a .tflite version of the Tensorflow model with the TensorflowLite framework but I'd rather convert the model to CoreML and use the native APIs. If possible I'd like to avoid having to add such a large dependency (TFLite) to my project. Thanks in advance.

Okay so I found it. if you go to Xcode on the developer site if you click "Download" it'll send you to the Mac App Store. But if you choose "Xcode Beta..." it'll take you to the Downloads page where you can download it directly from the website.

Address sanitizer crash as soon as you call -speakUtterance: still occurs on iOS 17.1. Kind of surprising that this seems like it is being treated as a low priority issue. I'm pretty sure WebKit uses AVSpeechSynthesizer to implement the Web Speech API so even beyond use in native apps every WKWebView and maybe even Safari could be impacted? It would be great if there was a little more communication from Apple on this to let devs know if a fix for this issue is coming anytime soon (and by soon I mean not in iOS 18) or if we should investigate other ways to implement this functionality.

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.

Thanks for your reply. I did file FB13264525

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.

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.

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?

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.

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

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.

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.