My hardened, developer-delivered MacOS app has a couple of embedded command-line executables, which are called from the main app, as well as dozens of dylibs that those executables require.The executables are in Contents/MacOS and the libraries are in Contents/lib/*.dylib. I used install_name_tool to point the executables at the appropriate dylibs with @executable_path. They are all signed; this has run great in the past, and the existing binary still runs fine. But...now when I build and run the unchanged app in Xcode (both 12 and 13), I get an error when the executable is called: dyld: Library not loaded @executable_path/../lib/library.dylib Referenced from: .../Contents/MacOS/subprogram Reason: no suitable image found.  Did find: file system relative paths not allowed in hardened programs Anybody know if a rule has changed here? Is @executable_path no longer supported in hardened environments? I've spent hours experimenting here. In searching the forums, I find various references to putting the dylibs into a framework. I tried just moving the dylibs into ../Framework instead of ../lib, with same error. Will switching to @rpath fix this? Would encapsulating them in full frameworks fix this? Is there any tool/documentation for that process? Does it require one framework for each dylib?