@fuseaudiolabs the error message "The binary uses an SDK older than the 10.9 SDK." suggests to me that you might be using an older version of the SDK, or at least that the PluginManager.framework that you are copying to your built products is from an older SDK. With any recent version of the FxPlug SDK and Xcode, it is no longer necessary to add custom build phases to get plugins recognized and loaded by the host app. You can simply link with the frameworks, and under the General → Frameworks and Libraries section of your project configuration, select the "Embed & Sign" option. Under Build Phases, the part where the SDK frameworks are copied to the Frameworks directory inside your bundle should have the Code Sign on Copy option enabled. First, I would make sure you have the very latest version of the FxPlug SDK. This message thread pre-dates the reorganization of the SDK, following Apple’s newest conventions. Besides letting the FxPlug SDK install the "FxPlug.sdk" folder where it wants, you could make your own local copy (so it's part of your repository) and add a build configuration setting so that Xcode can locate it when building your target, for example: ADDITIONAL_SDKS = "$(PROJECT_DIR)/SDK/FxPlug/FxPlug.sdk"

I haven't had the time to file a bug yet, but this might help anyone else who bumps into this... The problem seems to be triggered by the target being set to be deployed. I'm referring to the Build Settings whose xcconfig equivalents are DEPLOYMENT_LOCATION and INSTALL_PATH, e.g.: DEPLOYMENT_LOCATION = YES INSTALL_PATH = $(LOCAL_APPS_DIR) The deployment location might also play a role, though this is speculation "inspired" by macOS security policies. In our case, the framework whose default Metal library was not being created, was set up to be deployed to the Frameworks directory for the current user, i.e. INSTALL_PATH = $(LOCAL_LIBRARY_DIR)/Frameworks ...and this is enough to trigger the failure. This problem seems to affect more than just the Metal compiler. I noticed it too with the Storyboard compiler for a silly Swift app. Since the app was set to be deployed to $(LOCAL_APPS_DIR) the storyboardc invocation was failing to copy the compiled storyboard to the app bundle. Whether this is a bug in recent versions of Xcode, or a side effect of these various tools being unable to touch files at those locations, the solution is to add built phases to "do what the underlying compiler is no longer doing" ;-)