Until recently iOS only supported statically linked libraries which could lead to issues if you needed to use multiple components that had a shared dependency that you needed to upgrade for one reason or another. You couldn't touch the embedded version. Additionally there was no native package manager which made sharing libraries a clumsy affair. Cocoapods makes both cases easier.
This is correct. Starting with iOS 8 they finally allowed linking against custom frameworks which is why Carthage is now becoming much more popular. CocoaPods solved a critical problem of getting dependencies linked in, while creating a new problem of having your xcodeproj file and build settings be managed by them. I'll be happy enough to drop them for new projects going forward.
> Starting with iOS 8 they finally allowed linking against custom frameworks
I don't keep up with iOS development enough to know if anything has changed with respect to static/dynamic linking in iOS 8, but it has always been possible to use custom frameworks in iOS (eg, frameworks you build yourself, unless the community has another definition for 'custom framework').
The framework directory structure is a bit unorthodox, but it's really just your statically built library (absent any '.a' suffix) alongside any header files in a Headers folder. Again, not sure if this has changed with any support for dynamic linking.
Dynamic libraries don't help shared dependencies, do they? In both cases, you want the shared dependency to be in its own library. There is a difference in that duplicated dependencies in shared libraries will produce a subtle runtime error rather than an obvious build-time error, but that's not really better.
For the sake of brevity I didn't dive as deeply into the subject as I maybe should have, but the solution you get with Cocoapods to this is if you have two Pods that point at a shared dependency in another Pod you end up with just one copy. I forget how they handle version pinning as it's been a little while since I've had to actually worry about it (I do little iOS work these days) but I seem to remember that in this case the pinned version wins and if you have a version conflict it complains during the Pod installation.
I'm sure CocoaPods handles it, but what I'm wondering about is how static versus dynamic libraries come into the picture. As far as I can tell, that has no relevance to the problem of shared dependencies.
