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

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

@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.

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?

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...

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?

I filed FB13188396

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.

Am I supposed to work on making my apps work on a platform that's letting me know I'm already deprecated pre release? Doesn't seem like a great way to entice developers to jump in. IMO.

Being able to enforce numberOfLines would be desirable. It seems like a pretty common need to enforce a button to fit on a single line and I would think having a button wrap multiline would be more uncommon. In my case a button with a configuration initially displays with 1 line, but after toggling the Dynamic type setting to a smaller value, then increasing it back to the original value causes the button to start character wrapping even though there is plenty of room to fit all text on one line. It seems that UIButton (with a button configuration) can't really properly respond to the -sizeToFit method. Calling -sizeToFit just constrains the button to the current width and increases the height which is the opposite of what I often want.

I filed FB12771317

Under option 1 you say you archive with: [NSKeyedArchiver archivedDataWithRootObject:(array of objects of type A) requiringSecureCoding:YES error:&error] And then unarchive with: NSSet *classesSet = [NSSet setWithObjects: [NSMutableArray classForCoder], [A classForCoder], [NSString classForCoder], [NSNumber classForCoder], [B classForCoder], [C classForCoder] , nil]; NSKeyedUnarchiver *unArchiver = [[NSKeyedUnarchiver alloc] initForReadingFromData:decryptedData error:&error]; [unArchiver setRequiresSecureCoding:YES]; unarchivedArray = [unArchiver decodeObjectOfClasses:classesSet forKey:NSKeyedArchiveRootObjectKey]; Which doesn't match. Why are you specifying all those classes (NSString, NSNumber, etc.) if the array only contains TypeA? If you archive a single array that only contains TypeA objects then why don't you you use -decodeArrayOfObjectsOfClass:forKey: NSArray *unarchivedArray = [unArchiver decodeArrayOfObjectsOfClass:[TypeA class] forKey:NSKeyedArchiveRootObjectKey];

Thanks again for your replies! So after some research it appears that there is no javascript event to detect url changes. So the javascript code I have won't work for "web apps" that modify an already loaded DOM and change the URL programmatically. Usually a combination of onhashchange and onstatechange will capture all the ways JS programmatically changes the apparent URL without loading a new document. Both those aren't relevant for the back/forward cases. I heard about onhashchange but I can't seem to find documentation for a onstatechange event? It is my understanding that onhashchange won't pick up url changes in all cases? Being able to run a script after a "page change" in a reliable fashion is surprisingly complex.

So after some research it appears that there is no javascript event to detect url changes. So the javascript code I have won't work for "web apps" that modify an already loaded DOM and change the URL programmatically.

Would be nice to be able to tell what's being blocked so I can see if my WKContentRuleList is working properly. Testing one of these lists is kind of a nightmare.