[ChrisMarshallNY]

Ah. I see why this has not been an issue with me for most (maybe not all) of my projects. Most have only a single-layer dependency.

Looks like this happens for chained dependencies ("a Swift package with binary dependencies", below), in apps with extensions (I have none).

This is from the 12.4 notes[0]:

> If you use a Swift package with binary dependencies in an app with extensions, the build system incorrectly embeds the binary dependencies alongside the extension in the PlugIns directory, causing validation of the archived app to fail. (69834549) (FB8761306) Workaround: Add a scheme post-build action which removes the embedded binaries from the PlugIns directory after the build, e.g. rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app"/PlugIns/.framework.*

I do not see a note in the 12.5 notes addressing this[1].

[0] https://developer.apple.com/documentation/xcode-release-note...

[1] https://developer.apple.com/documentation/xcode-release-note...

[AJRF]

Do you know the difference between dynamic and embedded binaries?

[ChrisMarshallNY]

Any particular reason for the insult? I don't remember saying anything bad about you.

Maybe, we could have found more in common than you may think. We both seem to be passionate about the same kind of stuff.

I was under the impression that we should make an effort to be a wee bit more respectful with each other, than we might in venues like Reddit or SO (where they have the "digital sneer" down to a science).

That was the only thing I could find that mentioned anything like it at all.

I checked my builds every which way from Sunday, and I never had a double-embedded static lib. I was wondering if they may have been mixed up.

Otherwise, there's nothing at all about it.

I pretty much always use static libs, but sometimes, I may need a .framework. I've been using SPM for months, and have published a bunch of libs. I do tend to be conservative, and reduce the surface of dependencies wherever possible. I eat my own dog food, and am the only consumer (that I know of) of my packages. My chains tend to be short.

[AJRF]

Insult? No no no! I didn't mean to insult you at all, I was trying to find a good common ground to try explain why the Xcode 12.5 release fixes this issue without belabouring points you already know!

A swift package manager product before 12.5 will be embedded inside your target and statically linked.

If you have more than one target using that product, you will end up embedding it more than once, which creates duplicated symbols in your binary, which leads to undefined behaviour when calling that symbol at runtime (which Apple don't allow for apps on the AppStore - ironically Big Sur on M1 Macs has a lot of duplicated libraries for x86 and arm64 which will cause a warning about undefined behaviour when you call them - do as I say, not as I do).

What happens now in 12.5 onwards is those products will be dynamically linked, meaning there will be one copy of it in your binary, that each of your targets can call symbols on, which gets rid of the duplication and the potential for undefined behaviour.

[ChrisMarshallNY]

OK. My apologies for being prickly. I guess I spend too much time on SO. I love electronic communications. They give us whole new realms, in which to explore rancor.

I understand. I have not encountered that. I'll look again. In most of my projects, the executables are test harnesses, and not all use SPM. Most of my dependencies are so small, that I might actually be better off directly linking in the source file from inside the package. I do that with the Carthage variants, but the static libs are so small, that I don't sweat it, and it makes life easier, all around.

I know that dylibs are fairly recent additions to SPM. One of the issues that I had with Carthage, was that I was constantly screwing up the signing. Since the libs were so small, I just said "Bugger this for a lark," and directly linked the source files. Since Carthage checks out in the project dir, this was easy. I use a separate derivedData directory, so it's not so straightforward to directly embed SPM source files. I haven't tried the new resources in SPM modules, yet.

Thanks for following up, and again, my apologies for overreacting.