On MacOS, you would distribute a library as a 'Framework' (a package containing the binary shared object, headers, documentation, resources, sub frameworks...).
In Xcode, you can quickly add a framework dependency. And if you need to modify the framework too, you can use “sub projects” (the sub project build the framework you are using in the super project). With recent Xcode versions, it works reasonably well.
In this world, you don't need CocoaPods at all. Everything is nicely compositional.
You would have expected that they had extended this mechanism when they introduced the iPhone?<p>But they manage to totally screw that. First of all, they drop the support for Frameworks!! So if you want to ship a cross platform (MacOS/iOS) library, you must maintain two targets (one static lib for iOS (and good luck to manage its inner resources), one framework for MacOS). You also have to be careful to have compatible architecture between the sub project and the parent project, a problem that is aggravated by the multiplication of iOS architectures (armv 5, 6, 7, 8, 9, ...). Apparently, forwarding the required architectures from a parent project down to its dependant sub projects is a very difficult problem...<p>Then, the community feels the need to fix this mess to have a working environment where you can easily share your work: CocoaPods was born.