When you see the archive in the Organizer window, is it described as an app archive or a generic archive? If it’s the latter, see this article: https://developer.apple.com/documentation/technotes/tn3110-resolving-generic-xcode-archive-issue

Why aren't you using Xcode to notarize your app? That is, in the Organizer window, select the archive, click Distribute App, and when it asks for the method of distribution, select Developer ID. There are some situations where one must use notarytool manually, but it doesn't sound like you're in one of those situations.

I don't know what that error means, but I'm pretty sure that it's not just that the function is deprecated. I'm still successfully using SetFrontProcessWithOptions in conjunction with GetProcessForPID on Sonoma.

seemed to suggest that signing and notarizing are two separate processes They are. You can sign without notarizing, but you can't notarize without signing. To distribute an iOS app, you pretty much have to put it on the iOS app store, which also involves signing, but with a different kind of certificate. Mac apps, in contrast, can either be notarized and distributed however you want, or can be posted on Apple's Mac app store.

Once you're a member of the Apple Developer Program, you can notarize Mac apps for no additional fee. I'm not sure what you mean by "signage", but there is no additional fee to create or use code signing certificates.

There are two ways to see a preview of a file in the Finder. Select the file and tap the Space bar. Select the file, do Get Info (command-I) and then open the Preview section of the info window. Both of these methods use the same Quick Look extension mechanism, so I think it is you who has misunderstood.

It talks about target templates, not project templates. Try creating a new target.

Xcode complains that the hardened runtime isn't enabled for these prebuilt executables. At what point does Xcode complain about that? It surprises me, because the hardened runtime is specified during code signing (you can do it on the command line with codesign --options=runtime) and submitting for notarization involves Xcode signing all the executables in the application, even if they're already signed.

Apple docs do say "To upload a macOS app to be notarized, you must enable the Hardened Runtime capability.". I thought it was always required, but if I'm wrong about that, I don't know when it changed. Is there something that prevents you from enabling Hardened Runtime?

Years ago I wrote code that created a movie with chapter titles that showed up in QuickTime Player. At some point it stopped working, possibly due to changes in QuickTime Player. I don't know whether today's QuickTime Player is even capable of showing chapter titles. But for what it's worth, I can tell you that my text track used a media type of text, not metadata.

Thanks for the reassurance that it may not just be me. But I can't reproduce the problem in a toy project, so there's probably not much point in filing a feedback. I think I''l just hack a workaround: When I see a second-click mouse-up event in nextEventMatchingMask:untilDate:inMode:dequeue:, I'll directly dispatch it if it hits a view that responds to a custom selector doubleClick:.

It is possible to send mouse and keyboard events using functions such as CGEventPost and CGEventPostToPid. Doing so requires that the user grant permission in System Settings > Privacy & Security > Accessibility. You can request that the user be asked to provide this permission using CGRequestPostEventAccess. I know less about how to actually locate buttons and text fields in an app that is not your own. I think this would involve accessibility APIs. The Accessibility Programming Guide unfortunately seems to be all about making an app accessible, not using accessibility APIs. Here's a possible place to start: https://stackoverflow.com/questions/69002718/how-get-ui-elements-of-a-window-swift

Afterthought: although -[NSApplication sendEvent:] seems to work OK for simulating keyboard events, it's probably preferable in general to use -[NSApplication postEvent:atStart:]. The latter works better for mouse events.

The bug persists in Xcode 15.2 beta. I filed FB13520381.

If you look in the Report navigator rather than the Issue navigator, you'll see more details about linker errors.