Our project at work depends on a dynamic library that is called "LibraryAlpha". Also, our project at work depends on a dynamic library that is called "LibraryBeta". And also, it just so happens to be that "LibraryBeta" also depends on "LibraryAlpha".
Our project embeds .framework's built by different, i.e. embeds targets from separate .xcodeproj's.
What are the chances of symbols and implementations (functions and classes) of "LibraryAlpha" in this or another way being embedded in the bundle of our project twice in the following cases:
Additionally, it's commonly expected for .xcodeproj's produced with SPM to feature dependencies modules' as separate targets in the project which are linked against and embedded in the main (that one that declares its dependencies) module's bundle. So the question is, what happens if in our project I link and embed "LibraryAlpha" not as a target from a project "LibraryAlpha", but that one generated target for "LibraryAlpha"'s files in the project of "LibraryBeta"?
The question is wrong. Some cases presented in it can not be reproduced in real life.
Firstly, the concept that was mentioned in the question of "one framework linking against and embedding another framework" is not even a thing-- in fact, the whole concept of dynamic linkage was elevated in pursue of reusing same shared objects between multiple users, without the need to make the same code available (read, embed) more than once.
Keeping previous statement in mind, the first case becomes literally impossible to reproduce in real life right away since the case states
"LibraryAlpha"'s project target embedded into "LibraryBeta"'s bundle.
"LibraryBeta" might be linked against "LibraryAlpha"'s project target and in order to use "LibraryBeta" at runtime, the executable needs to embed the "LibraryAlpha". The repetition of symbols is unachievable here since "LibraryAlpha" will appear in bundle only once.
"LibraryAlpha"'s source code statically linked with the source code of "LibraryBeta"
This case will lead to repetition of code being compiled. Once it will be present in bundle in the form of dynamic library "LibraryAlpha" and once statically linked to "LibraryBeta".
Caveat:
Actually, in this case you will not be able to compile "LibraryBeta" at all, assuming any of your source code files declares at the top
import LibraryAlpha. Modules in Swift can not be declared manually and their source code must reside in separate targets in order to be importable. The case features source code in the same module as "LibraryBeta", so the compiler will error out withNo such module LibraryAlpha.
"LibraryBeta" only linking against, without embedding, "LibraryAlpha"
The actual working solution, won't cause any of code repetition.
...link and embed "LibraryAlpha" not as a target from a project "LibraryAlpha", but that one generated target for "LibraryAlpha"'s files in the project of "LibraryBeta"
No code repetition will occur in this case.
For the cases like 4th, except you thrive not to reuse targets.
By linking "LibraryBeta" against one dynamic library, but embedding another dynamic library... There are two outcomes. Hypothetically the same source code and same configuration should produce the same dynamic library, same .framework folders with same object code, .swiftmodule's, .swiftdoc's, dSYM's and everything, even if it's two different targets in different projects. So in case, if the resulting .framework's happened to be absolutely same 2 different compilations in 2 different projects as 2 different targets, then your executable i.e. our project should link to whichever .framework is present at runtime just fine!
However, if output of "LibraryAlpha"'s own target will be somewhat different from "LibraryBeta"'s "LibraryAlpha" target, well... memes... I didn't bother checking what would happen in this case. But the logic tips that whichever "LibraryAlpha" was included, will not link to the opposite target properly, and dynamic linkage will fail. If somebody would like to check this behavior yourself, be my guest.