What they solve is that they are not just shared libraries, they include any other resources the library needs like translations, images, other data etc and for developers any header files.
But it works if you just treat them as shared libraied - just use -F on the compiler anlink rather than -l and the headers are not needed in /usr/include etc.
The are also versioned so easy for two apps to have different versions of the Framework.
Minor clarification: two apps can embed different, incompatible versions of the same framework without versioning — the versioning is a NeXTism that allows the system vendor to ship a newer, binary incompatible version of the framework.
NeXT used it with AppKit for a few releases, but when they came to Apple they realized it would be impossible to support something like Aqua with the desired UX without having to update all the versions of the framework every release, which would defeat some of the purpose, not to mention exploding the QA matrix.
True for Apple/NeXT Frameworks or others used by a lot.
I think versioning could work if your framework is not used by many apps - the link structure and version number is still there but I have not tried for 20 years.
The correct current practice is as you say to embed the framework in the app at build time so you don't link to outside non Apple Frameworks.
