The most obvious example is linking of dependent libraries. When you add a framework to your project, that framework already has encoded the libraries it depends on; simply drop the framework in, and no further changes are required to the list of libraries your project itself links to.
People/companies do this with static libraries as well, whereas it should be “the application developer's responsibility to add all required libraries in addition to the one they actually want to use”.
Of course, if ‘the one [library] they actually want to use’ is the only library they care about, then having a single ‘drop-in’ solution is preferable. However, once you depend on multiple libraries that might have common dependencies, there’s no way around having to have a dependency (versions) manager. Because while you can pull-off various symbol tricks with C libraries, you cannot with Objective-C. As in, there can only ever be one class/method registered for a given name in the runtime.
I feel like this was glossed over in your article and might lead some readers to draw incorrect conclusions. I.e. frameworks being the solution to all problems when doing dependency management.
In response to these issues, a variety of cultural shifts have occurred. Tools like CocoaPods automate the extraction of source code from a library project, generate custom Xcode workspaces and project files, and reproduce the build configuration from the library project in the resulting workspace. Through this complex and often fragile mechanism, users can integrate library code in a way that begins to approach the simple atomic integration of a framework, but at the cost of ideally unnecessary user-facing additions to their project's build environment, significant fragility around the process, and not insignificant overhead for library authors themselves.
To double-check, as I understand it you blame the problems to the fact that we have no easy way to integrate our third-party code into Xcode projects, right? (As in, I don’t believe any of these are inherently due to the way we decided to do things in CocoaPods, if there were better/sanctioned ways to do it, we’d use those and we will if/when they do in the future.)
Correct. The way I see it, there are two issues -- packaging and use of a single library, and distribution and dependency resolution across a dependency graph of libraries. I've been focused on the first; the blame for any issues with the mechanics of how CocoaPods provides the second lies firmly at the feet of Apple and the lack of better supported mechanisms -- that is, I agree that if Apple provided tools, you could easily shift to them and the core value of resolving a graph of dependencies would remain.