SwiftPM binaryTarget dependency and code signing

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.

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.

1 Like

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

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

In Xcode 13.4 it doesn't seems to populate PackageFrameworks.
I ended up doing this based on @defagos' post above, but with referencing the nested framework directly:

# Build phase: Copy signing identity
echo "${EXPANDED_CODE_SIGN_IDENTITY}" > /tmp/target-name-signing-identity
# Build post-action: Re-sign nested framework
FRAMEWORK_PATH="$BUILT_PRODUCTS_DIR/$FRAMEWORKS_FOLDER_PATH/Module.framework/Frameworks/Nested.framework/Nested"
CODE_SIGN_IDENTITY=`cat /tmp/target-name-signing-identity`
codesign --sign "$CODE_SIGN_IDENTITY" -f "$FRAMEWORK_PATH"

I encountered this issue even with Xcode 14.1 where my xcframework is linked with the main target via SPM Package.swift. Anyone still encountered this issue?

I'm afraid this is a lost battle. I reported bug report to Apple on 19 May 2021.

Screen Shot 2022-11-22 at 19.06.45@2x

I keep adding comments about it still being an issue every few months/weeks, but no reply since.

Maybe you can try report too and reference FB9111156

1 Like

Oh damn, every time I fall in these holes I lost my faith. I'll report it and reference your report for sure.
Have you found a workaround? I'll try the script above (I've switched between enable sign but I didn't worked).

@danielemm which script works for you as a workaround?
I encounter the same issue for a zipped xcframework within a .binaryTarget

None of them, unfortunately.
This a reproducible small project Dropbox - MyProj.zip - Simplify your life

Maybe there is something possible with the new build tool plugin addition for SPM.

I'm not sure it's the same error, however I've created a simple project to reproduce the problem here: "No code signature found" when using SPM to integrate binary .xcframework