I\'ve been doing iOS development for a couple of months now and just learned of the promising CocoaPods library for dependency management.
I tried it out on a person
I'm in the camp of developers who do not check in libraries, assuming we have a good copy available in another location. So, in my .gitignore I include the following lines specific to CocoaPods:
Pods/
#Podfile.lock # changed my mind on Podfile.lock
Then I make sure that we have a copy of the libraries in a safe location. Rather than (mis-)use a project's code repository to store dependencies (compiled or not) I think the best way to do this is to archive builds. If you use a CI server for your builds (such as Jenkins) you can permanently archive any builds that are important to you. If you do all your production builds in your local Xcode, make a habit of taking an archive of your project for any builds you need to keep. Something like: 1. Product --> Archive
Distribute... Submit to the iOS App Store / Save for Enterprise or Ad-hoc Deployment / what have you
Reveal your project folder in Finder
Right click and Compress "WhateverProject"
This provides an as-built image of the entire project, including the complete project and workspace settings used to build the app as well as binary distributions (such as Sparkle, proprietary SDKs such as TestFlight, etc.) whether or not they use CocoaPods.
Update: I've changed my mind on this and now do commit the Podfile.lock to source control. However, I still believe that the pods themselves are build artifacts and should be managed as such outside of source control, through another method such as your CI server or an archive process like I describe above.