Just convenience, I think. Auto-updating rather than re-cloning and dragging files back into your project. This is fraught, of course.
CocoaPods also functions as a discovery engine. The experience is very unpolished, but it will surface the code that other people have written with the explicit intention of offering as a library to other people. Which is a subset of "code other people have released on github", obviously.
I'm a skeptic too. I've played with it, but requiring a couple dozen additional ruby gems and editing my Xcode project files underneath me creeps me out, so I won't use it for personal or client work.
I've been hired into existing projects that used it though, and it works fine as long as you manage it as a glorified drag-n-drop. You can blow yourself up if you trust it like a vendor-approved auto-upgrade mechanism. That's as much a factor of the ecosystem as the tool, and I hope Pods and Pod authors will coalesce around a level of maturity that's useful in shipping code environments.
> Auto-updating rather than re-cloning and dragging files back into your project
That's the least usable way to do it, though. Use static library projects in submodules and a workspace/nested projects, and updated submodules will Just Work (unless there are breaking API changes, but Cocoapods can't help you there).
The main advantage of Cocoapods is shared dependencies. If you don't have those, it doesn't offer you much besides a non-git-native way to manage dependencies. Also, not having to manually edit your Xcode project to get the correct, single component path (instead of an absurd relative one) for a static library after changing to BUILT_PRODUCTS_DIR (why this has never been fixed, I have no idea).
Yes, CocoaPods can’t fix API breaking changes, but as we use semantic-versions and encourage authors to follow those, it can at least be mitigated more easily. E.g. A version requirement of: ‘~> 1’ should then install the latest v1.x.x, but not v2 which has API breakage.
Obviously this is not fool-proof and many are still getting used to it.
It's not simply that Xcode project files are edited that creeps me out. Cocoapods is actually trying to solve a complex problem, more so than other package managers like RubyGems or Pip or CPAN. Project files will therefore need to be edited.
It's really the fact that Xcode makes it inconvenient to do the work CocoaPods is trying to accomplish. I do trust you guys to do things right, I do not trust that Apple will keep your needs in mind when they make changes to Xcode.
There are features of CocoaPods that I just don't use, preferring to perform things manually. I don't use those features mostly due to the concerns described above, and my comfort level with doing them myself. If I did break my habits and use those features, the convenience might outweigh the complexity introduced.
I'd love to see Apple explicitly target CocoaPods compatibility as a beta testing goal.
Unfortunately this is a problem with most monolithic tools. The only sensible solution is to keep points of integration as minimal as possible so you can adapt when there are changes.
Minimalism combined with the fact that CocoaPods has a pretty large active community we should be able to adapt if large changes do occur.
CocoaPods also functions as a discovery engine. The experience is very unpolished, but it will surface the code that other people have written with the explicit intention of offering as a library to other people. Which is a subset of "code other people have released on github", obviously.
I'm a skeptic too. I've played with it, but requiring a couple dozen additional ruby gems and editing my Xcode project files underneath me creeps me out, so I won't use it for personal or client work.
I've been hired into existing projects that used it though, and it works fine as long as you manage it as a glorified drag-n-drop. You can blow yourself up if you trust it like a vendor-approved auto-upgrade mechanism. That's as much a factor of the ecosystem as the tool, and I hope Pods and Pod authors will coalesce around a level of maturity that's useful in shipping code environments.