<"Will CocoaPods stop development now that Swift has a built-in package manager?"
As of writing, the Swift Package Manager (SPM) is in "early design and development" [1]. It does not currently support iOS, watch OS, or Objective-C [2][3]. CocoaPods will continue development supporting both Swift and Objective-C while SPM develops. As SPM approaches maturity, we will evaluate the best course forward for CocoaPods and the CocoaPods community.
<“Why not just use git submodules?”
CocoaPods is not about downloading code. While it does do that, it’s arguably the least interesting part.
What defines CocoaPods are the (cross) dependency resolution, (semantic) version management, and automating the ‘integrating it into Xcode’ parts.
Finally, even if you’re looking just for a downloader, consider that there are in fact other SCMs being used than just git. CocoaPods, on the other hand, is agnostic and handles Subversion, Mercurial, and zip/tarballs from local or HTTP locations.
<“How can I donate to CocoaPods?”
TL;DR: While we very much appreciate the sentiment, the project (as an entity) does not accept financial donations. We have a great blog post on this.
<“CocoaPods doesn’t do X, so it’s unusable.”
First see point #2, then consider that unless you tell us about the missing feature and why it is important, it won’t happen at all. We don’t scour Twitter to look for work, so please file a ticket, or, better yet, in the form of a pull-request.
<“CocoaPods doesn’t do dependency resolution.”
CocoaPods has always done dependency resolution, but until version 0.35 it lacked automatic conflict resolution. As of now, CocoaPods can resolve any conflict that is possible to resolve.
<“CocoaPods is bad for the community, because it makes it too easy for users to add many dependencies.”
This is akin to saying "we should not have cars", as they make us lazy and we forget walking/running. Or "we should not use IDEs" as they make us bad programmers, who can't code in editor and can't remember syntax. Furthermore, this reasoning applies to basically any means of fetching code (e.g. git) and as such is not a discussion worth having.
What is worth discussing, however, is informing the user to be responsible. Ironically enough, the original author of CocoaPods is convinced using a lot of dependencies is a really bad idea. For practical advice on how to deal with this, you should read this blog post by Manfred Stienstra.
<“CocoaPods uses workspaces, which are considered user data. Why does it not use normal sub-projects?”
Starting from Xcode 4, Apple introduced workspaces for this very purpose.
Since then, they have also added workspace files to each xcodeproj document, leading people to believe that a workspace is user data only. This is simply incorrect and you should not ignore workspace documents any longer, if you were doing so.
Note that CocoaPods itself does not require the use of a workspace. If you prefer to use sub-projects, you can do so by running pod install --no-integrate, which will leave integration into your project up to you as you see fit.
<“Why do I have to install Ruby to use CocoaPods?”
You don’t, macOS comes with a Ruby 2.0.0 or newer pre-installed in /usr/bin/ruby which are our baselines and these should work out of the box.
<“Can I change the default CocoaPods repositories folder?”
By default CocoaPods stores repositories in your home folder in ~/.cocoapods and caches Pods in ~/Library/Caches/CocoaPods.
You can set CP_HOME_DIR in your environment to change this to another folder, e.g. export CP_HOME_DIR=another-pods-dir. Both caches and repositories will now be in this folder.