All binaries must be signed in order to load successfully on M1 machines.
It’s worth checking whether running strip causes the code signature of the plugin to become invalid, by checking the signature before and after running the strip command. If the signature is invalid after running strip, you will need to re-sign the binary before attempting to run it.
Yes, I always sign after the strip command. But, there’s something I’ve noticed, it looks like since I’ve updated to the develop tip, even though the Code-Signing Identity field is empty in my Projucer project, it still signs the plugin. I’ll do more tests, but something definitely changed recently that’s messing with my builds.
I’m only aware of one recent signing change, specifically:
If no signing identity is specified, Xcode will now sign the binary to run locally. I’d be a bit surprised if this was causing the problems you’re seeing, but it might be worth checking before and after that commit to see whether it has any effect.
Thanks, good to hear that codesign --remove-signature works fine then (I had read a few horrible posts about it not working correctly on Stack Overflow, but these were older posts, so I guess it should be fine now if you’re using it on all your plugins in the wild). That should help for the AU and VST version then.
BTW: did you ever find out if the “Strip symbols” option in the Projucer does the same as strip -x -S?
Last question: how do you handle the AAX version now that Xcode signs that .aaxplugin bundle too?
Until now, I always did this in a post-build script defined in the Projucer (and thus ran by Xcode):
if [ "$TARGETNAME" = "SaltyGrain - AAX" ] ; then
echo Copying presets into AAX bundle
mkdir -p $CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME/Contents/Factory\ Presets/SaltyGrain/
cp -R $PROJECT_DIR/../../Source/Presets/AAX/ $CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME/Contents/Factory\ Presets/SaltyGrain/
echo Stripping binary in AAX bundle
xcrun strip -S -x $CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME/Contents/MacOS/SaltyGrain
echo Signing AAX build
/Applications/PACEAntiPiracy/Eden/Fusion/Current/bin/wraptool sign --verbose --account samplesumo --signid "Developer ID Application: SampleSumo (PV***********)" --wcguid *******-****-****-****-************ --dsigharden --in $CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME --out $CONFIGURATION_BUILD_DIR/$FULL_PRODUCT_NAME
so I only sign with (AVID) wraptool, and don’t (Apple) codesign the aaxplugin bundle.
But with the change in JUCE 6.1.3, the wraptool-signed aaxplugin bundle now also gets signed with Apple codesign by XCode: is that OK (doesn’t it break AVID’s wraptool signature)?
I’m not sure, I suspect it’s not the same kind of strip, that’s why I kept it in my build script.
I don’t run any post-build script with Projucer, I have a bash script with all the build steps I need (using xcodebuild etc…) so I just remove any signature from the AAX too and then resign it again correctly with wraptool
Yeah, that’s also why I have the strip in my script: you’re sure what actually gets executed then. Maybe I’ll experiment a bit later on to see if it’s doing the exact same thing or not.
What you do for the AAX version (remove Xcode’s signature + call wraptool from your own script later on) could indeed be a workaround, but I was doing it from Xcode’s post-build actions because I could then just easily build it from Xcode and my plugin would already contain the presets in it’s bundle (I copy them in there in that post-build phase) and be signed with wraptool, ready to go if I want to try it, without having to run an extra script after the Xcode build (which I only do when I make a full test release installer normally).
I’ve continued my findings for AAX in the topic I had started and mentioned above.