Assume we have a package that has a dynamic product. If you'd add this package to a framework or the host application, it will automatically be set to Embed & Sign which in some cases might be not the intended behavior. If I try to change that entry to Do Not Embed, Xcode simply deletes the dependency which makes it impossible to code to compile.
This happens in Xcode 11.3.1 and both new 11.4 betas.
One thing to notice is that the icon of the library is always the same as for static libraries even though it will generate a framework out of the package as it's set to dynamic.
This is a critical setup issue because there only a single workaround I can pull of.
The product must be static.
Add the static framework which will keep the entry under Embed blank.
Change the product to dynamic which will automatically set the entry to Do Not Embed.
This isn't suitable for remote packages that one does not own.
If you then attempt to switch the entry to Embed & Sign and again to Do Not Embed, Xcode again will simply delete the dependency.
Can someone cc the right SwiftPM devs and maybe someone who works on the Xcode part of this?!
Another workaround I came up with is to create a framework which will embed the static lib from the package and re-export it and then link against that framework, but this simply defeats the purpose of SPM already supporting dynamic libs but Xcode not properly handling it.
This is a known issue and has been there from the start of Xcode integration. At least now Xcode doesn't crash anymore when you try to set it to Do Not Embed. Seriously, it used to do that.
A workaround I am using is to actually modify the xcodeproj file manually with a text-editor and remove the embed phase. That's what @Aciid recommended and it works.
I hit that yesterday but it happened when I toyed around with a regular framework. However I don't recall which Xcode version I used at that moment. Either 11.3.1 or 11.4 beta 2.
That seems dangerous to me. I compared the files, but I couldn't fully understand them as some of the relate parts seem a little bit cryptic.
I've got an app where the main project depends on a package and a framework that in turn depend on the same package. I've tested the technique to manually edit my framework's project file to remove the embed phase while letting the main project embed the library. It does seem to work and the AppStore validation tool does not complain anymore, which it did before the manual edit. But I guess that this is dangerous and the reason why Xcode automatically removes the dependency. I have not verified this but I'm guessing that in theory the main project could embed one version of the library binary while the framework is linked against another resulting in unexpected behaviour.
Can anyone here say for sure that the workaround is dangerous and could this danger be removed by making sure that they link against the same library version/revision?
The mentioned workaround also works for me but I am sharing the concerns that Xcode behavior might be intentional. I raised question in Apple Developer Forum: https://forums.developer.apple.com/message/417881#417881 and I am waiting for an answer
