I'm on iOS 17.0.3 and still am still seeing all the same issues with AVSpeechSynthesizer. The reason why certain voices seem to work while others don't is due to the nature of undefined behavior. All sorts of random and bad stuff can happen in unpredictable ways. The issue does not seem to be fixed.

This bug still exists in the released version of Sonoma (macOS 14.0).

Have to turn off picture in picture on Mac as a workaround.

@dw_dw My TSI got credited back to my account and they said there is "no workaround" and the issue is being investigated. I was wondering the same thing about 17.1 beta but haven't checked it out myself. Sidenode for whatever reason e-mail notifications aren't working for me on this thread even though I'm watching it. Have to check back manually periodically to see if anyone is posting here.

Looks like this is still broken in Sonoma.

Rebooting my Mac "fixed it."

If I hit the "Play" button in the Preview my app icon appears in the dock and it says "Previewing on 'Local Mac'" and there is a button that says "Bring Forward" but I see nothing. If I click the "Bring Forward" button it launches the preview (my app?) and it shows me the view controller I'm previewing and it does perform the modal presentation in the window brought forward. .....but if I make a change to the source code this window doesn't refresh it stops the preview and I have to relaunch it. I don't see how this is any different from launching my app normally as the preview is not live. Are Mac "Live Previews" supposed to behave this way or is this a bug?

I filed FB13215248

@previewseng Nice tip. That does work and will have to do for now when I want to use a Live Preview. I get great compiler performance and it never crashes for ObjC so it's kind of a shame I have to pollute my code base with Swift for a design time feature (** JOKING**. I'm only JOKING don't kill me Swifters).

I see. I don't think there is a good way to do this using public API. I could think of a way to hack it but the implementation would be fragile. Unless customizing this menu is really important to your app I wouldn't do it.

The idea is that the developer is expected to provide a better user experience if you use Mac Catalyst and put in the time and effort to make your app feel like a "Mac App" (by that I mean an app that behaves as close to an AppKit app as possible, though Mac Catalyst creates some arbitrary barriers that does not always make this an easy task). If you let your iPad app run on Mac unmodified it's definitely easier for you. It all depends whether or not you think your app is "good enough" for Mac as an unmodified iPad app. It won't run on Intel Macs though.

Is the allowsUserCustomization property set to YES on the toolbar? self.myNSToolbar.allowsUserCustomization = YES; self.myNSToolbar.autosavesConfiguration = YES; //<--Most likely want this to YES too. If you are using Interface Builder make sure the checkboxes corresponding to these properties are checked.

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.

Still broken on macOS Sonoma.

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