A case for switching to CocoaPods from Git Submodules

In a previous post, I linked to Sam Vermette’s article on Switching from Git Submodules to CocoaPods. Now I’d like to explain why we did it for our projects, and why you might want to, too.

The problem with git submodules is this: your project doesn’t have the source for code you depend on. It only has a reference to the submodule’s repository. And most of the time you don’t even control that repository. So…

Let’s say your project depends on AFNetworking. You add it as a git submodule, and then, someday, due to an Act of God (or just because the author feels like it), AFNetworking disappears from its home on GitHub. It’s all gone, vanished into thin air. Now when someone new clones your project repo, they run git submodule update --init …and it fails. So now they can’t build the project. And you’d better be careful, too, cause if you lose the AFNetworking source code, you can’t build either…

So now we use CocoaPods, and we push the source for each dependency to our central repo. Now when someone git clones a repo, they get all the code they need, and they can build the project just fine. They don’t even need CocoaPods to build the app – it just works.

(Thanks to Mark for being my sounding board as I wrote this.)