<RubyGems + Bundler
For many, CocoaPods is the first introduction to dependency management in programming projects. A lot of ideas for CocoaPods came from similar projects ( for example RubyGems, Bundler, npm and Gradle).
Understanding Ruby dependency management is useful because it allows you to specify versions of CocoaPods or other gems and ensure all developers in your team have the exact same version. This guide is for people looking to ensure consistency in their team dependencies or for using un-released versions of CocoaPods.
<RubyGems
RubyGems is a hosted ruby library service. It centralizes where you look for a library, and installing ruby libraries / apps.
You'll have seen gem install xxx. These are installed into a central database of versions. If you imagine that CocoaPods
installs all libraries/frameworks into a System folder and they are linked at runtime, then you have the rough idea
of how RubyGems keeps all the gems.
The downside of this is that there is no way to ensure that a project needing a specific version of a library can use that, it would always use the latest version. So as a developer, you would be cautious installing a new version of a library because it would be used in every library / app. This is the problem bundler solves.
<Bundler
Bundler creates a consistent application environment for your application, by allowing you to specify the version of libraries.
We took this idea almost whole-sale for CocoaPods. You define a Gemfile that says what libraries you want to include, and can
optionally specify a version or range. You run bundle install and it will generate a Gemfile.lock saying the exact version of
all of your libraries and then anyone else running bundle install with that project gets the exact same versions.
<What is a Gemfile?
If you have read the guide on the Podfile, it will feel very similar. A Gemfile is a ruby file that defines your ruby dependencies. Here is an existing one from a Cocoa project.