I tried re-signing the helper with the hardened runtime, and then it won't launch at all. Trying to launch it in Terminal shows Runtime error 217 at 000000011003B572 Googling "runtime error 217" just shows Windows errors.

Is this helper app nested within your main app? No. That means you selected your main app’s scheme and chose Product > Run, right? So you’re debugging the main app and hit this problem when the main app tries to run the helper app. Correct. Is any of this stuff sandboxed? No. If not, do you have the hardened runtime enabled? Hardened runtime is enabled for the main app, not the helper. Is the main app running the helper as a child process (fork then exec*, or posix_spawn, or NSTask, or Process, or similar). Or as an independent app (NSWorkspace, or Launch Services, or similar)? Running as an independent app using -[NSWorkspace openApplicationAtURL:configuration:completionHandler:]. The configuration includes an additional argument.

Have you read the documentation on the PDFDocument class, for instance the findString(_:withOptions:) method?

I got that error message when trying to create an Apple Distribution certificate in Xcode 14. But in Xcode 15, it worked.

D'Oh! Yes, and the documentation does say to call resume. Thanks!

Are you doing this programmatically? If so, show some code; if not, you should be posting in the user forum or filing a bug with Feedback Assistant.

CGDisplayCreateImageForRect does not appear to be deprecated, could you use that?

I think you need to extract notarytool from Xcode 13. I ran otool -L on the copy of notarytool in Xcode 15 and saw that it depends on /usr/lib/swift/libswift_Concurrency.dylib. But doing otool -L on the notarytool in Xcode 13.4.1 does not show that dependency.

As far as I know, the advice from Apple (or at least Quinn) has always been to sign from inside out. That is, any helpers, tools, frameworks, and dylibs should be signed before the app bundle as a whole. Of course you’re free to write feedback, but don’t be surprised if it comes back “behaves as designed”. And they’re probably mostly focused on development with Xcode, in which the process of uploading an archive for notarization or the App Store takes care of the details of code signing.

My guess is that the problem lies in the Image I/O Framework. I filed a bug report, FB13283189.

Yes, there does seem to be something weird about icns handling in Sonoma. When I open that stop icon in Preview in Sonoma, the two smallest versions look blue in the thumbnail sidebar, but are red in the main view when selected. Opening the same file in Preview on Ventura does not show this effect. You should file a bug report with Feedback Assistant.

I'm surprised that you say it worked in Ventura, because in my testing, NSApplicationActivateAllWindows has not worked since at least 10.15. I filed FB11974786 about it. I worked around it by using the old Carbon function SetFrontProcessWithOptions, which is deprecated but works.

You could create an NSEvent and use the sendEvent method of NSApplication.

Override performFindPanelAction: in some class in the responder chain. In your override, if [sender tag] is NSTextFinderActionShowFindInterface, present your custom find panel. See the NSTextFinderAction enumeration for other possible actions.

You mean 13.6, there is no 14.6. Either Xcode 14.x or Xcode 15 will work on Ventura. Don't worry about .xip, if you double-click it, the Archive Utility will decompress it.