Closed DivineDominion closed 5 years ago
The error went away after upgrading my dev system to Mojave.
It reappeared recently and I was able to get past the problem by ditching Carthage and using the CocoaPods version instead (maybe it's Carthage's build commands, I don't know).
I also had to add a separate signing step afterwards, though, as a quick-fix for the signing issues after copying the helper app bundle using the script.
LOCATION="$BUILT_PRODUCTS_DIR/$CONTENTS_FOLDER_PATH/Library/LoginItems/LaunchAtLoginHelper.app"
# By default, use the configured code signing identity for the project/target
IDENTITY="${CODE_SIGN_IDENTITY}"
if [ "$IDENTITY" == "" ]
then
# If a code signing identity is not specified, use ad hoc signing
IDENTITY="-"
fi
echo "Hardening Launch At Login Helper with developer identity \"$IDENTITY\"..."
codesign --verbose --force --deep -o runtime --sign "$IDENTITY" "$LOCATION"
While the
LaunchAtLoginHelper
target'sENABLE_HARDENED_RUNTIME
is set to "Yes", Xcode rejects my app's binary for upload:The folks at Sparkle suffered from a similar problem: https://github.com/sparkle-project/Sparkle/issues/1266
Code-signing after embedding the framework did the trick for them: https://github.com/sparkle-project/Sparkle/issues/1266#issuecomment-421182578
The difference to this framework here is that they did sign both the app and the framework. But neither worked for me with regard to LaunchAtLogin.
From what I gather, the current settings or the addition of an additional
codesign
call to the framework should do the trick, but no such luck.Signing framework and app again
For reference, I modified the script to
LaunchAtLogin.framework
and sign the framework at the end--deep
option to the helper signing steps