SwiftPM binaryTarget dependency and code signing

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).

1 Like

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 {} \;
1 Like

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.

8 Likes

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.

2 Likes

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.

1 Like

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?

1 Like

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 :slight_smile:

9 Likes

I am still experiencing this issue with Xcode 12.3 RC

1 Like

This is our work around for static framework embedding problem if anyone needs an example. Excuse my scripting... I don't do this often :slight_smile:

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

6 Likes

Still getting this issue in 12.5 RC with MapLibre SPM

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.