I’m reluctant to just revert this change, as it’s necessary to run console apps built with Xcode 14.1+:
It would be helpful to know how your project is configured. Have you specified a code-signing identity and development team ID, or are you leaving those fields blank? Are you manually signing the app, e.g. in a post-build step? How is libavcodec.dylib added to the bundle, and during which part of the build?
After investigating, it looks like previously (with an empty signing identity), Xcode would bypass the signing step for GUI apps, so the resulting app would be linker-signed:
My suspicion is that adding a framework to the bundle after the signing step will invalidate the bundle signature, but without detailed information about your build process, it’s difficult to say exactly what’s going wrong.
If I create a completely new app in Xcode, setting the development team to “None” in the wizard, then the generated project has no CODE_SIGN_IDENTITY key, but the product will still be automatically signed with an identity of “-”. I think it’s probably a good idea for JUCE projects to mirror this approach, so my preference would be to find a way of ensuring that any embedded frameworks are also correctly signed.
Using --deep is probably not a good idea:
It looks to me like Xcode defaults to resigning embedded frameworks during the build. Assuming the framework was specified as an “embedded framework” in the Projucer, I would expect this to work automatically.
Based on your remarks, it seems we’re either not signing the frameworks before consuming them, relying on bad or outdated build behaviours, or both? In any case, I’ll park this for now because it’s entirely possible that we rip out these libraries for the time being (as we’re not using them) which may inherently fix the issue.