Apparently the link in my previous reply didn't post properly. For anyone who was curious, I came across the information that I needed in a blog called xcodebuild-destination-options, on a site called mokacoding.

Funnily enough I had just discovered the generic/ option here - https://www.example.com/. It did the trick - thanks!

I have Parallels, and managed to find an installer that I'd archived for Catalina 10.15.3, so now have a clean 10.15.3 vm. It appears that the same problem is occurring there, which is interesting and suggests that it wasn't a recent change to the system that caused it. I am struggling to find a place to download an earlier 10.15.x installer. The downloads page of the developer site seems to only have the latest installer. I can find combo updater for 10.15.1 and 10.15.2, but I presume that they run on top of an existing install? I tried softwareupdate --fetch-full-installer --full-installer-version 10.15.1, but that doesn't seem to want to play ball. Is there an official location from which to obtain previous system installers?

I'm not sure if it's strictly speaking a build that all of the  That was supposed to say "a bug" rather than "a build". Autocorrect + lateness...

I tried with --destination, using various combinations of platform=iOS, id=dvtdevice-DVTiPhonePlaceholder-iphoneos:placeholder and name=Any iOS Device. Unfortunately that device shows up in the list of ineligible destinations for the scheme, and produces this output: xcodebuild: error: Unable to find a destination matching the provided destination specifier: { id:dvtdevice-DVTiPhonePlaceholder-iphoneos:placeholder } The requested device could not be found because no available devices matched the request.

Thanks Quinn.I will change my signing script to remove `--deep`. The script does actually recurse anyway, so the `--deep` was part belt-and-braces, and part legacy.I don't have access to a 10.15.3 system at the moment, but a hardening change between .3 and .4 was my number one suspicion, so it's good to hear that it's at least a possibility.

Actually, after further investigation, I think that XC11.4 was correct in saying that I had a library linked twice. I was depending on other libraries which were pulling in the static version of the shared library. This is a real mess for any non-trivial graph 😟.What we really need here is for SPM's `.automatic` product type to work, and do the right thing!

I think that you should indeed be using a dynamic library - by setting the product type of your SPM library to `.dynamic`.However, I have a similar example where I have a framework and a command-line app, both of which use a couple of SPM libraries. I've got both a static and a dynamic product defined in the SPM libraries, and have added the dynamic versions to the Link Binary With Libraries panel for both the framework and the command line target. And I'm still getting the above error with Xcode 11.4b1!Xcode 11.3.1 will build successfully, but I'm getting a runtime error about symbols being duplicated, so it looks like Xcode is actually ignoring the fact that I've added the dynamic versions to my targets, and is using the static versions instead.😟