SwiftPM binaryTarget dependency and code signing

[abarisain (Arnaud Barisain-Monrose)]

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

[abarisain (Arnaud Barisain-Monrose)]

I am still experiencing this issue with Xcode 12.3 RC

[afarnham (Aaron Farnham)]

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.

[kyzmitch (Andrey Ermoshin)]

@afarnham

ARCHIVE_APP is just a the path to the app inside the xcarchive bundle.

thanks for this new workaround, can you clarify how to get proper value for ARCHIVE_APP?

[afarnham (Aaron Farnham)]

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.

[abarisain (Arnaud Barisain-Monrose)]

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

[ferologics (Fero)]

Still getting this issue in 12.5 RC with MapLibre SPM

[krzyzanowskim (Marcin Krzyzanowski)]

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

[pewe (Peter Weishapl)]

We've solved this issue with a script that moves all embedded frameworks to "APP.app/Frameworks", see:

Swift Packages in multiple targets results in “This will result in duplication of library code.” errors

So we finally seem to managed to solve our problem with a little post-build script that moves all embedded frameworks to "APP.app/Frameworks" (and re-signs everything): cd "${CODESIGNING_FOLDER_PATH}/Frameworks/" for framework in *; do if [ -d "$framework" ]; then if [ -d "${framework}/Frameworks" ]; then echo "Moving embedded frameworks from ${framework} to ${PRODUCT_NAME}.app/Frameworks" cp -R "${framework}/Frameworks/" . …

Hope this helps.

[ferologics (Fero)]

This also happens when SPM tries to build dynamic frameworks to avoid linking duplicate static libraries. The frameworks inside Build/Products/Debug-iphoneos/PackageFrameworks directory are not signed before the frameworks are copied to their respective locations (i.e. to Debug-iphoneos/Module.framework/Frameworks/Nested.framework) and the final code signing step somehow misses them.

[zhihuitang]

This still happens to me on Xcode 12.4

dyld: Library not loaded: @rpath/xx.framework/xxx
  Referenced from: /private/var/containers/Bundle/Application/65369630-396D-466D-8595-0BBBCE553939/xxx.app/Frameworks/xx.framework/xx
  Reason: no suitable image found.  Did find:
	xxxx.framework/xx: code signature in (/private/var/containers/Bundle/Application/65369630-396D-466D-8595-0BBBCE553939/Cx/xx.framework/xxx) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.
dyld: launch, loading dependent libraries
DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib

[tonyarnold]

I'm seeing the same issue with codesigning in Xcode 13.0 RC.

I've implemented the following workaround in my project that seems to get around the missing code signing. Interestingly, this is only an issue when building on my Intel Mac - my Apple Silicon Mac builds just fine.

If you want to use this workaround, add the following as an Xcode Build Phase in your affected targets. I had to add it to my application and test targets.

# Populate a variable with the current code signing identity if it's available in the environment.
SIGNING_IDENTITY="${EXPANDED_CODE_SIGN_IDENTITY:-$CODE_SIGN_IDENTITY}"

# Populate a variable with the current code signing flags and options in the environment.
OTHER_CODE_SIGN_FLAGS=${OTHER_CODE_SIGN_FLAGS:-}
 
# Re-sign the SwiftPM packaged frameworks using the application's details.
if [ -n "${SIGNING_IDENTITY}" ]; then
    find "${CONFIGURATION_BUILD_DIR}/PackageFrameworks" \
        -name "*.framework" \
        -type d \
        -exec codesign ${OTHER_CODE_SIGN_FLAGS} \
            --force \
            --sign "${SIGNING_IDENTITY}" \
            --options runtime \
            --deep \
            {} \;
fi