Seems pretty absurd. Why bother implementing and deprecating something before the platform is even released? Many apps are complex and have taken years to write and their entire navigation structure is tied to one or more storyboards. Tearing the entire thing down isn't something you're going to do in a week (unless the app is very simple). So they want us to: Ship our storyboard based app on visionOS using deprecated "walking dead on arrival" API. They break the functionality and tell you to use SwiftUI. You now have a non-working app. Either rewrite the entire app with a new UI framework that has a different app lifecycle (can reuse very little code) or pull your live app from the store. No thanks. Instead of just letting developers choose which UI framework works best for them they have decided to force feed it. I mean if they want visionOS to be SwiftUI only like watchOS they should just enforce that policy from the start instead of trying to paint you into a corner. Feels like they are forcing SwiftUI because they're worried developers will choose UIKit if given the option. If SwiftUI is better, developers will use it so why force it? Oh yeah, interface builder products are being deprecated as well. I already miss the good old days where you could design custom table view cells in Interface Builder in like three seconds. And you didn't even have to wait for a preview to load. Even making the most basic custom table view cell now with the "content configuration" API is a pretty awful way to waste 30-45 minutes of your life.

I filed FB13188396

Part of my troubleshooting steps had me write the utterance to an AVAudioFile instead of just speaking it. This log seems like it could be related: Input data proc returned inconsistent 512 packets for 2,048 bytes; at 2 bytes per packet, that is actually 1,024 packets -- This really is a big setback for my development (I'm sure lots of other apps are affected by this too). Workaround I can think of are: Splitting the string into separate utterances or 2) Write the utterance to a file and play the audio file. Both options require me to restructure quite a bit of code and makes things much harder to maintain. No symbols for system methods...making it hard for devs to figure out workarounds. Anyone know if there is a method I can swizzle to patch this?

Looks like this bug is triggered when using the "Daniel Enhanced" voice in combination with this particular string. If I change the voice suddenly AVSpeechSynthesizer plays the entire string fine...

Well oddly after changing the voice it works but for some reason when switching back to the Daniel enhanced voice it causes -speechSynthesizer:didFinishSpeechUtterance: to be called prematurely at the exact same location of the speech string every time in my app. In the event of some sort of error where speech synthesis is supposed to stop prematurely I'd expect -speechSynthesizer:didCancelSpeechUtterance: to be called not -speechSynthesizer:didFinishSpeechUtterance: (though I think a new -speechSynthesizer:didFailWithError: would be a useful addition since -speechSynthesizer:didCancelSpeechUtterance: I believe is called when I programmatically stop an utterance). Not sure why the synthesizer is prematurely calling -speechSynthesizer:didFinishSpeechUtterance:. I set a breakpoint in -speechSynthesizer:didFinishSpeechUtterance: but the call stack doesn't include debug symbols for the system methods that are called before. A bunch of methods _lldb_nanamed_symbol_1111 are listed before -speechSynthesizer:didFinishSpeechUtterance so there's not a whole lot for me to go on. Anyone else run into this?

@And0Austria Yup just noticed the same thing...TTS will crash with the AddressSanitizer turned on iOS17. They are freeing a wild pointer according to the AddressSanitizer. Looks like every app that uses AVSpeechSynthesizer has undefined behavior. I've been working on a feature for my app for a couple of months that uses this API and now after updating to iOS 17 it abruptly stops and random points in an utterance. Maybe it'll work. Maybe it won't. I reported FB13188396 and made a thread about the issue here: https://developer.apple.com/forums/thread/737685 Kind of depressing that this was known two months ago and still made it into the iOS 17 release.

Related thread: https://developer.apple.com/forums/thread/730639?answerId=765237022#765237022

Are you strongly retaining the synthesizer? You should be holding the synthesizer in a property at least until it finishes speaking the utterance. Also there are some problems with AVSpeechSynthesizer which may or may not be related to your issue: https://developer.apple.com/forums/thread/737685 https://developer.apple.com/forums/thread/730639

Check out these related threads: https://developer.apple.com/forums/thread/730639?answerId=765237022#765237022 https://developer.apple.com/forums/thread/737685 -- Appears every app using AVSpeechSynthesizer has undefined behavior on iOS 17. This is blocking me from pushing an update I've been working on for months.

Yea. It's a pretty bad situation for us. Doesn't seem like there is anything we can do about...except wait and hope they'll fix it soon.

If you want to use UIKit on Mac you need to use Mac Catalyst. https://developer.apple.com/mac-catalyst/

That probably is just a band aid. I'm noticing all sorts of strange behavior where speech synthesizer just stops for certain voices and not others, for certain speech strings and not others.

Anyone else file a bug and if so did anyone from Apple reply? I think a lot of apps use AVSpeechSynthesizer so hopefully they give the issue priority,. I ended up opening a TSI last week but still haven't heard back yet. My app release is completely jammed up.

Still broken on Ventura 13.5.2. Also it doesn't work when creating a pull down UIButton. The following button just show "Loading..." and the provider block is never called: UIDeferredMenuElement *deferredmenuElement; deferredmenuElement = [UIDeferredMenuElement elementWithUncachedProvider:^(void (^ _Nonnull completion)(NSArray<UIMenuElement *> * _Nonnull)) { UIAction *actionOne = [UIAction actionWithTitle:@"Action One" image:nil identifier:@"fake.action.test" handler:^(__kindof UIAction * _Nonnull action) { NSLog(@"action one fired."); }]; completion(@[actionOne]); }]; UIMenu *someMenu = [UIMenu menuWithChildren:@[deferredmenuElement]]; UIButton *pullDownButton = [UIButton buttonWithType:UIButtonTypeSystem]; [pullDownButton setTitle:@"Pull Down Button" forState:UIControlStateNormal]; [pullDownButton sizeToFit]; self.button = pullDownButton; self.button.menu = someMenu; self.button.showsMenuAsPrimaryAction = YES; [self.view addSubview:pullDownButton]; //Position the button...

On Mac Catalyst I did get the UIDeferredMenuElement elementWithUncachedProvider: block to be called only when creating a menu for a UIContextMenuConfiguration directly but if you're actually loading data async to build the menu you can't use dispatch_async_get_main_queue to call the completion block on the main thread. UIDeferredMenuElement *deferredMenuElement = [UIDeferredMenuElement elementWithUncachedProvider:^(void (^ _Nonnull completion)(NSArray<UIMenuElement *> * _Nonnull)) { //Load whatever async. dispatch_queue_t queue = dispatch_get_global_queue(QOS_CLASS_DEFAULT, 0); dispatch_async(queue, ^{ //You can't do this. The menu will never update because of the run loop mode. dispatch_async(dispatch_get_main_queue(), ^{ //Build UIMenu with data loaded and call the completion block on the main queue. UIMenu *menu = //...make it completion(@[menu]) }); //Instead you have to pass the block to a method like this, then invoke the block. [self performSelectorOnMainThread:@selector(builtMenuBlock:) withObject:completion waitUntilDone:NO modes:@[NSRunLoopCommonModes]]; }];