Swift 5 Module Stability Workaround for Binary Frameworks
instabug.com
instabug.com
Versioning a library makes it "easy" to break compatibility by allowing you to have an ever increasing number of copies of each library, but that comes at the cost of old software using old (potentially buggy and insecure) versions of libraries.
It also hurts performance as you're more likely to have to load multiple copies of almost identical libraries. That hits memory usage and launch time performance.
Finally having "versioned" libraries doesn't help if you have one application using libraries that have been built targeting different library versions. What does it mean if you have an API passing a struct/class/record around if different libraries have different ideas of what the in memory layout of that struct is?
OSX and iOS solve this by saying that the platform is ABI and API stable, and so something written and compiled 5 years ago still works today.
Windows does similar, the specific DLL hell problem that windows had was that they didn't make the compiler SDK part of the OS, so apps had to bring a copy of their particular SDK with them. Then they just copied them blindly into the win\system or whatever directory, because lazy programming (also a lot of apps had to ship copies of DLLs because windows didn't include basic behavior as part of the OS).
Linux does not handle this problem at all - it's considered a given that end users should expect to recompile apps after an update. Versioning the libraries just means you can maintain the string name of the library, rather than acknowledging that your unstable (in the api sense) is a different library.
Windows is a prime example which uses versioning and still allows to share modules by the means of a proper ABI, COM (__stdcall and friends, yuck). It is absolutely common to embed multiple C (yes, even C has no stable ABI on Windows!) and C++ runtimes in a single binary and use COM as the ABI. Something like that would have worked for Swift as well, precisely as demonstrated by the article, using the simpler ObjC runtime as the ABI.
> What does it mean if you have an API passing a struct/class/record around if different libraries have different ideas of what the in memory layout of that struct is
That is precisely what an ABI declares and is used for. In the context of the post, the ABI is the _ObjC_ runtime, which is stable. That potentially different Swift versions being linked have different layouts doesn't matter.
The primary issue with Linux is that it doesn't have explicit support for two level namespaces within dynamic linking. Though it is again also not uncommon to mix ABI-unstable languages like C++ by the means of a stable ABI (either C or for example the ABI defined by Apache).