gistfile1.md

Besides, CocoaPods hides the version of the library that you use and their dependencies, and you may find yourself using something that you did not want to use, or an older or newer version than expected.

What do you mean by hiding versions? They’re all listed in Podfile.lock.

For example, just by installing RestKit you will find other 5 or 6 dependent libraries installed, which are supposed to work properly, but make you lose some control of your project.

You can control the versions being used by specifying one of those dependencies before the RestKit dependency, but with version requirements. For example, at the time of writing SOCKit is at version 1.0, which is what you would get if you depend only on RestKit, but you can limit it to 0.0.1 like so:

dependency 'SOCKit', '= 0.0.1'
dependency 'RestKit'

Autoupdate: Whenever you run “pod install” the tool recreates the Pod project and downloads any updates related to your libraries. In a perfect world this would be a bless! you could be updated at any time just by running one command! However, we do not live in such a perfect world, but in one where the libraries often drop backward compatibility when upgrading or where things that are compatible do not work in the same way from one version to the next one! And believe me, people will update the specs of your libraries to new versions!

Indeed. This is going to be fixed when we finally get to implementing pod update. See #131.

Code tracking: Linked to the previous problem, if you do not keep the status of your Pods in your CMS you may face a problem when trying to recompile an old version of an app. You should always keep a copy of all your project files (in the exact state that they were) when you build a release version, or otherwise you could be unable to reproduce a bug if something goes wrong later.

This will also be fixed once #131 is implemented, as it will use the Podfile.lock file to install the exact versions used at that point in time. It might still be a good idea to keep source in your SCM, though, in case the source location ever ceases to exist.

Thanks for your comments Eloy! However, I have to disagree at certain point to this:

You can control the versions being used by specifying one of those dependencies before the RestKit dependency, but with version requirements. For example, at the time of writing SOCKit is at version 1.0, which is what you would get if you depend only on RestKit, but you can limit it to 0.0.1 like so:

dependency 'SOCKit', '= 0.0.1'
dependency 'RestKit'

Altought it is true that you can control it this way, the key problem from my point of view is that you do not know in advance what dependencies will the library use. For example, I would never imagine that Reskit will include UDTableView, and in fact this lib was the cause of a crash in one of our apps when running on iOS4.2.
The other problem related to this that we had is the following: we have a build server machine using an old version of CocoaPods (0.5.1) whereas our developing machines where using the 0.6-rc3, with a newer Specs branch. Every test was done on the app from the build server, which seems ok. However, we made a huge mistake when we created the AppStore version! we did it with our machines and the app crashed because of this RestKit dependency! This is not a problem of CocoaPods itself, and of course it is our mistake in ultimate instance because we should never have this differences and build with the dev machine, but CocoaPods make it more likely to happen because it hides what it is going underneath. Checking the Podfile.lockI think would have not helped too much because the Spec number was the same, but with some dependency differences. I think that it would help if somehow we avoid people from changing specs already existing in the repo and force them to create a new one with the changes the want to introduce.

Anyway, as I've said a thousand times, good job guys! it is an amazing tool!