Still experiencing this issue in the just-released Xcode 12 public build. Anyone have an idea how far away we are to a resolution?
With Xcode 12.0.1 the issue is the same.
@NeoNacho @Aciid We have complex project which has multiple sub projects inside workspace, where each target depends internally, but this modularization works fine with Cocoapods but not with SPM(Xcode 12/ swift 5.3), any idea when this problem would be solved?
Thanks
This is a great summary, thank you.
Could you explain the workaround for issue 2?
Thanks 
The general idea for the workaround is making whatever is linked statically multiple times dynamic.
In the case of package products, that is relatively straightforward, you can change the type of the library to dynamic (Apple Developer Documentation). The main annoyance here is that you might not directly control this dependency, so it could require creating a fork.
If the issue happens with a package target, the solution is unfortunately quite complicated, since packages don't give control over the type of targets, they are always static. One solution is creating a framework in Xcode which bundles up the products in question to avoid having to link them twice. Another solution is to restructure the package in question so that the given target can become a product, but this will require breaking it out into its own package.
As said before, we aware that this is an issue for many people and are investigating a solution, especially because the workarounds aren't particularly easy to deploy.
9 Likes
Are there any news on this Topic? I think Swift Package Manager could be awesome but without being able to add a Dependency to multiple Frameworks I can't use it for my projects. 
Tested it with Xcode 12.3 and it's not working.
1 Like
We are still running into this problem today in Xcode 12.3.
We have a Swift Package that declares two dynamic library products:
- Fooable
- Foo
Foo depends on Fooable.
Some frameworks in our app just depend on Fooable, and this works just fine.
However when we made the app itself link to both Fooable and Foo, now compile breaks with:
"Swift package target 'Fooable' is linked as a static library by 'App' and 'Foo'. This will result in duplication of library code.
Why is Xcode statically linking to a dynamic library target...? What is the fix?
I've found two workarounds so far:
- If I only link the app to
Foothen, the error goes away. - If I turn on "DISABLE_DIAMOND_PROBLEM_DIAGNOSTIC" then the error goes away.
But I would like to understand first of all, why this problem is happening in the first place? Considering that the Swift package itself declares both of its products as dynamic libraries, why would Xcode try to statically link anything? Is there a way to prevent it from statically linking these, and if so, how? If not, why not?
I don't want duplicated code anywhere in the app.
1 Like
@NeoNacho thanks for chiming in here. Looking forward to a desined solution.
Another solution is to restructure the package in question so that the given target can become a product, but this will require breaking it out into its own package.
Would it be possible to expand on this (or point me/us to documentation)? What is the relationship between products and targets and how would a target become a product?
1 Like
@NeoNacho thanks for all the details you've included on this thread so far. Do you happen to know what the status is on this nowadays?
There is this in the 12.5 beta:
- The Swift Package Manager now builds package products and targets as dynamic frameworks automatically, if doing so avoids duplication of library code at runtime. (59931771) (FB7608638)
However, there are some known issues with code signing dynamic frameworks that are built from packages in general in the betas right now, so it might not be usable yet in all contexts.
1 Like
Thanks for the info! This is great news, I'm looking forward to it.
So dynamic linking seems to finally work since Xcode 12.5RC....until you're trying to submit the app, which will give you the infamous ITMS-90205/ITMS-90206 error messages.
I already submitted an example project (FB9028703) to Apple, but no response.
It has the following components:
- iOS App Target (BundleFormat)
- Framework 1 (Framework)
- Framework 2 (OtherFramework)
- Local SPM Package (Package)
- Remote SPM Package Dependency (DeviceKit)
With this dependencies:
App > OtherFramework
OtherFramework > Framework
OtherFramework > LocalPackage
LocalPackage > RemotePackage
Framework > RemotePackage
And produces the an app package that looks like this:
As you can see it contains a lot of nested frameworks, which the app store doesn't accept.
I have no idea how to work around this.
The 12.5 RC still has deal-breaker problems for our team.. we worked around the 12.4 linker issues by forcing all our SPM products to be .dynamic and using DISABLE_DIAMOND_PROBLEM_DIAGNOSTIC.
We had hoped that Xcode 12.5 would be our saviour. When the RC came out we went through all our packages and removed the harcoded .dynamic from each Package.swift - however when using 12.5 to build we get this error:
The Xcode build system has crashed. Please close and reopen your workspace.
(sometimes the error is prefixed with unexpected service error:)
The funny thing is.... 12.5's xcodebuild command works just fine!
DEVELOPER_DIR=/Applications/Xcode12.5.app/Contents/Developer xcodebuild -workspace ./Redacted.xcworkspace -scheme Redacted_iOS\ Prod build
Our package structure is a little complex but we would definitely expect Xcode to handle it. The issue stops happening if we remove the package with the blue background (and therefore packages that it depends on).
The diagram above shows our SPM dependency structure with our app target at the top. Some of these products exist in the same package, others have their own package (there are 8 packages all together). Something else to note that we think may be related is that the package shown in blue has some products that are only used in our unit test targets.
Has anyone else has experienced this in 12.5? For now we are sticking to 12.4 and (again) hoping that the next RC solves all our problems...
this embedded framework issue only seemed to happen when a package was embedded in an xcode framework project (that hasnt been migrated to package manager)
if that is the case, i think just changing the "embed" to "dont embed" in the list of dependencies should fix the issue
(it did for me/us anyways)
hope that helps 
So we finally seem to have solved our problem with a 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/" .
rm -rf "${framework}/Frameworks"
fi
fi
done
if [ [ "${CONFIGURATION}" == "Debug" ] & [ "${SDKROOT}" != *Simulator* ] ] ; then
find "${CODESIGNING_FOLDER_PATH}" -name "*.framework" -print0 | while read -d $'\\0' framework
do
if [ "${framework}" != "NULL" ] ; then
codesign --force --deep --sign "${EXPANDED_CODE_SIGN_IDENTITY}" --preserve-metadata=identifier,entitlements --timestamp=none "${framework}"
fi
done
echo "Resigning ${PRODUCT_NAME}.app after moving frameworks"
codesign --force --deep --sign "${EXPANDED_CODE_SIGN_IDENTITY}" --preserve-metadata=identifier,entitlements --timestamp=none "${CODESIGNING_FOLDER_PATH}"
else
echo "Info: CODESIGNING is only needed for Debug on device (will be re-signed anyway when archiving) "
fi
This has also solved this problem for us: SwiftPM binaryTarget dependency and code signing
3 Likes
@pewe Thanks for providing the script! however, when I run it I get [: too many arguments.
The fix is to remove the extra [ ] wrapping from:
if [ [ "${CONFIGURATION}" == "Debug" ] & [ "${SDKROOT}" != *Simulator* ] ] ; then
to be:
if [ "${CONFIGURATION}" == "Debug" ] & [ "${SDKROOT}" != *Simulator* ] ; then
Anyway, after I tried it Xcode just says "Unable to install "App"" error and in the details it has "No code signature found".
Did you set a Team in Signing & Capabilities? (Automatically manage signing)
Yes, automatic code signing is enabled.
After diving into this we managed to work around the issue with a similar but modified version of the script posted by @pewe (many thanks!). In our case we had to remove some leftover nested SPM packages. Also, we only sign frameworks that are missing a signature. Hope it helps:
# Flatten and code sign nested frameworks
# adapted from https://forums.swift.org/t/swift-packages-in-multiple-targets-results-in-this-will-result-in-duplication-of-library-code-errors/34892/57
cd "${CODESIGNING_FOLDER_PATH}/Frameworks/"
# flatten nested frameworks by copying to APP.app/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/" .
rm -rf "${framework}/Frameworks"
fi
fi
done
# remove any leftover nested frameworks (i.e. 'PackageName_359AFEED79E48935_PackageProduct.framework')
for framework in *; do
if [ -d "$framework" ]; then
if [ -d "${framework}/Frameworks" ]; then
echo "Removing embedded frameworks from ${framework} to ${PRODUCT_NAME}.app/Frameworks"
rm -rf "${framework}/Frameworks"
fi
fi
done
# codesign for Debugging on device
if [ "${CONFIGURATION}" == "Debug" ] & [ "${SDKROOT}" != *Simulator* ] ; then
echo "Code signing frameworks..."
find "${CODESIGNING_FOLDER_PATH}/Frameworks" -maxdepth 1 -name '*.framework' -print0 | while read -d $'\0' framework
do
# only sign frameworks without a signature
if ! codesign -v "${framework}"; then
codesign --force --sign "${EXPANDED_CODE_SIGN_IDENTITY}" --preserve-metadata=identifier,entitlements --timestamp=none "${framework}"
echo "Added missing signature to '${framework}'"
fi
done
fi
5 Likes
I just made the same mistake as you, by removing ".dynamic" from all our local packages and updating their Swift Tools versions to 5.4. Except rather than crashing, instead, now when Xcode builds our app, for every Swift package that it decides to build as a dynamic framework, it embeds a copy of it into a Frameworks folder inside every. single. other. package. product. or. Xcode-project-defined. framework. that. depends. on it.
Of course, this "automatic embedding" behavior causes the app to fail app store validation due to multiple copies of the same bundles being deposited throughout the app like easter eggs throughout a backyard on Easter Sunday. WTF.
Like with all the other unwanted, automatic behaviors that plague the SPM/Xcode integration, this also has zero documentation around it, and no way to turn it on or off.
See my post here for details:
I'm 100% certain this problem (described in my post linked above) is the exact same problem that @ferologics is describing, which they have "solved" by writing a shell script to go through their entire app after it's built and remove all the extra copies of frameworks that SPM has sprayed everywhere, and then resign the whole thing.
Our app is 800 MB with 100+ modules... so I find as unacceptable any "solution" that extends our already long CI build times by repeating steps in order to work around an issue that could be avoided by simply not using Swift Packages for anything related to enterprise or business-critical software.
Maybe in Swift 7 or 8, Swift Packages will be able to fully replace Xcode project files without everything caving in on itself. But I've seen enough to now believe that it would be less work to redo our 50+ local packages as Xcode projects than it would be to continue supporting them as Swift Packages.
1 Like