Xcode is supposed to re-sign all of your libraries and frameworks upon export of the archive, or is that incorrect?
Yes, but if you attempt to run the app on a device directly from Xcode it will fail (which is quite annoying when you have something to debug).
Thanks for this! I think part of your script may have gone missing. It worked for me when I used this:
find "${TARGET_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}" -mindepth 1 -maxdepth 1 -type d -exec /usr/bin/codesign --force --sign ${CODE_SIGN_IDENTITY} --preserve-metadata= '{}' \;
You are right, sorry for the bad copy & paste. I actually preserve identifier and entitlements metadata, so the final command looks like:
find "${TARGET_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}" -mindepth 1 -maxdepth 1 -type d -exec /usr/bin/codesign --force --sign ${CODE_SIGN_IDENTITY} --preserve-metadata=identifier,entitlements {} \;
Was this issue resolved in the latest Xcode 12.2 beta?
The issue has been fixed in Xcode 12.2 beta 3. The binary frameworks are now properly code signed, as can be seen in the build log.
Note that you have to switch your command-line tools to this specific beta version (12B5035g) and to cleanup your build folder first.
A big thanks to the people who fixed this issue!
Remark: The fix has not been backported to 12.1 GM, the workaround is still required for this version.
Xcode 12.3 does fix the issue for me, but it looks like I'm still running into another issue specific to static frameworks: Xcode copies (and signs) the static framework in the app's Frameworks directory.
The framework is properly statically linked to the app, so it runs but it unnecessarily heavier than it should.
Yea, moving static archives (.a) into the Frameworks directory is still a big problem!
Embedding static frameworks also causes the application package to be invalid when uploading to the App Store.
Unfortunately this is still an issue with Xcode 12.2 RC
Yep, we're still seeing the issues with static frameworks in Xcode 12.2 RC requiring complicated workarounds. This is a major usability issue impacting migration to Swift Package Manager.
Can anyone provide an update on a fix?
Xcode 12.2 final and 12.3 beta 1 don't fix this either
Not trying to be rude or anything, I'm just keeping people up to date so that they don't waste time testing
I am still experiencing this issue with Xcode 12.3 RC
This is our work around for static framework embedding problem if anyone needs an example. Excuse my scripting... I don't do this often
ARCHIVE_APP
is just a the path to the app inside the xcarchive bundle. We codesign the whole the whole thing again right after we remove these static frameworks.
The gist is we check the executable using the file
command and if the word dynamically
is not found in the output from file
we remove the framework.
for FRAMEWORK in "${ARCHIVE_APP}"/frameworks/*.framework
do
echo "Found '${FRAMEWORK}'."
EXEC=$(/usr/libexec/PlistBuddy -c "print :CFBundleExecutable" "${FRAMEWORK}/Info.plist")
FILE_INFO=$(/usr/bin/file "${FRAMEWORK}/${EXEC}")
if [[ -n "$(echo $FILE_INFO | grep -v dynamically)" ]]; then #if FILE_INFO is not empty
echo "Removing '${FRAMEWORK}'"
rm -r "${FRAMEWORK}"
fi
done
Edit: As for efficacy, we ship tons of internal testing builds through this bit of script, so far it has not caused any issues for us.
thanks for this new workaround, can you clarify how to get proper value for ARCHIVE_APP?
The ARCHIVE_APP
is the path to your app inside of an xcarchive bundle. The xcarchive bundle is the output of our Release build on our continuous integration servers.
For example our path is /<working directory>/ForeFlight.xcarchive/Products/Applications/ForeFlight
.
I am happy to report that it looks like that Xcode 12.5b1 has fixed the issue.
FYI, Apple has acknowledged the issue in 12.4's release notes and documented a workaround
Same issue with Xcode 12.5 final release. Xcode refuse to resign binary target. The very same xcframework when drag&drop in Xcode works just fine, however when integrated with Swift Package Manager it throw sign error
Summary:
iOS target can resign framewoks
macOS target can't resign frameworks
so it looks like the bug is still there, however is half-fixed
We've solved this issue with a script that moves all embedded frameworks to "APP.app/Frameworks", see:
Hope this helps.