@And0Austria Thanks for sharing that info. I'll have to give AVSpeechSynthesizer another try on iOS 17.2 now and see. It would be nice (if they did fix it) if they included that information in the release notes and/or updated some of our bug reports but if it's fixed that'll be good enough....

I made a post about this a couple of months ago: https://developer.apple.com/forums/thread/738814 Had to disable Picture in Picture as a workaround. On Mac Catalyst the way PIP was implemented (if it ever worked) was kind of pointless IMO. It should pop out into a separate standalone window on a Mac but I think you could only drag it around inside the window where the WKWebView was.

For whatever reason I'm not getting e-mail notifications when people reply in this thread even though I'm "following it." Weird. I'm a little confused by all the manually downloading voice stuff. I don't particularly care that much that speech synthesis isn't working in the simulator (although it would be nice if it did...like it use to). I noticed, on device, that speech synthesis just randomly seems to stop working since the release of iOS 17. Incorrect behavior includes: -Jumping around to random ranges of the speech string at random points. -Speech synthesis simply stops speaking at certain points of some speech strings. When synthesizing short amounts of text (a couple of words) it usually "works" but the inconsistent behavior seems to match the idea that there are possibly memory management issues going on under the covers. I haven't checked on iOS 17.2 to see if it's fixed. Nothing in the release notes say anything about it. The API is basically unusable. My TSI got closed with a no workaround available message and my bug report has not received a reply. Sooo....they seem to be in no rush to fix it. I was going to release my app in just a few days before they broke it and put me on hold. Investigating alternatives. Feels like I got burned. I imagine all the devs who already have a released app using AVSpeechSynthesizer must feel really burned.

Good question. You are far from the only one who has this concern. Many developers prefer the "old way" of making apps and find SwiftUI to be limiting, hidden behind a wall of "magic" Apple controls. We have to inherit all their bugs. In AppKit/UIKit we do too but we have a much greater chance at implementing our own workarounds. I think most developers, even the ones who like SwiftUI at least want the option to be able to drop into the lower-level APIs SwiftUI is wrapping. For example in most cases on iOS SwiftUI seems to rely on UIKit like SwiftData is built on top of CoreData (I could be wrong on some of those details, anyone out there feel free to fact check me if I am). This doesn't appear to be the direction Apple is heading in (giving developers the choice). Feels like Apple is trying to force this on us instead of letting the framework speak for itself. I'm getting tired of the way they are bullying developers. They are flexing their power a little too much for my liking. They want to treat us like babies. Don't you worry your little head about what's going on under the covers. Here's SwiftUI peasant...you can use that... what's underneath it...well that's not for you. I also understand that Xcode is a very complex piece of code and that maintaining and evolving some tools (as IBDesignable) requires effort I don't think they've touched IBDesignables in years (could be wrong). It's been frozen in time, for a long time. Good thing about that is you don't get new bugs when they stop touching things.

So I modified the .dylib and changed the LC_BUILD_VERSION's platform to 6 (signifies Mac Catalyst see <mach-o/loader.h>). I also discovered this post from Quinn https://developer.apple.com/forums/thread/659964 and discovered that I could have done this with vtool as well.

This stackoverflow post has a useful answer: https://stackoverflow.com/questions/1085137/how-do-i-determine-the-target-architecture-of-static-library-a-on-mac-os-x

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.