I’ve gone back and forth on the debate with whether or not we should be checking in the dependencies for a project supplied by CocoaPods. In the past I felt it was best to only check in the Podfile and maybe the lock file. I believe I’ve finally made a decision with recent experiences and my development practices with Git.
I’m checking in the whole effing workspace.
Why?
- Every branch, especially master, should be compilable and archivable up to a point.
- Caveat 1: Xcode is a piece of shit sometimes and will break things because it can between versions.
- Caveat 2: Provisioning Profiles.
- CocoaPods is a well-maintained tool, however, Specs are a crap-shoot.
- Specs can disappear.
- Specs can be unofficially maintained.
- Specs can be wrong.
- Checking in your Pods directory ensures the best possible snapshot of the pre-binary code.
- Forcing a pod install every time someone checks out code doesn’t ensure the same state of code is maintained for testing bugs in previous versions.
- You may decide to drop Pods support and forget how to use it.
- Wouldn’t it be nice to do diffs on your dependency classes?
- Xcode Bots doesn’t work well enough yet with CocoaPods for me to want to install Pods every build
- I’m also not sold on Xcode Bots itself – it’s quite unreliable and likes to smoke my server’s CPU.
- CocoaPods needs to not be a hinderance – its pretty innocuous when the risky work (installing Pods) is done and checked in.
That sums up my thoughts. I primarily work on WordPress for iOS which is a heavily forked and contributed to repository. I don’t think the project could be a success with the amount of branching and pull requests performed if we didn’t check in the Pods directory.