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]]; }];

Still broken on macOS Sonoma.

Thanks for that tip. It doesn't appear to be possible to create a live preview purely from Objective-C unfortunately. When I expand the macro I see it uses API declared in the DeveloperToolsSupport.framework which is Swift only and everything is Swift structs and Swift protocols not exposed to Objective-C. You can create a live preview for an Objective-C view controller/view in a Swift source file...by importing the Objective-C header and then create the Objective-C view controller from a Swift source file in the Preview macro: //In a Swift source file (make sure header file is imported for the view controller/view in the bridging header) #Preview { let someVC = ObjCViewController() return someVC } This seems kind of silly and dev hostile IMO. The preview works but you have to jump back and forth between the Objective-C .m and the Swift file created only for the purpose of making the live preview.