One thing to watch out for during development is that Xcode: Builds all your apps and frameworks into your Products/Debug directory Set up a dynamic linker environment variable to force your apps to look for framework in that same directory I have specified legacy build locations in my project, so that the app and frameworks are built in different directories.

The frameworks SBEngineLib4.framework and Cal3D.framework exist in the main app. Having one app load frameworks out of an ‘unrelated’ app is a tricky business. Perhaps I wasn't clear, but I definitely wasn't trying to have one app load frameworks out of another app. The main app contains private frameworks just for its own use, and the helper contains dylibs for its own use. It's just under this debugging situation that things somehow got confused.

Aha! When I re-signed the helper app using the hardened runtime and an entitlements file that sets com.apple.security.cs.allow-unsigned-executable-memory to YES, then the helper runs even when I'm debugging. I don't know why it needs that entitlement, but it probably has something to do with the helper was built using the FireMonkey framework, not Xcode. So, thanks for asking about hardened runtime.

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.