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.

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.

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.

@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 filed FB13215248

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?

Rebooting my Mac "fixed it."

Looks like this is still broken in Sonoma.

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

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

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

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 limitation never made any sense especially given the fact that NSURL has NSURLTagNamesKey which may be set and get. Way back in the day I was looking to do this. I naturally thought NSWorkspace API related to "file labels" (which I think tags replaced) would maybe just map to tag names but it didn't work. NSWorkspaceDidChangeFileLabelsNotification never got posted so I gave up.

You can now open the web inspector from Safari's "Develop" menu in the menu bar for a WKWebView in a Mac Catalyst app if you set the isInspectable property to YES. They added this in iOS 16.4.

Still doesn't appear to be supported on Sonoma. Oh well.