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

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

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.

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.

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

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.

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.