Targeting a specific version of CocoaPods can be helpful for a team to stay in sync and prevent breaking changes between development environments which may have different versions of Ruby or CocoaPods installed. These examples show how to configure a Gemfile for a specific CocoaPod version.
A Gemfile works with the Ruby bundler which is run with bundle install as shown
below. It creates Gemfile.lock which defines the versions which are installed when that command is run.
The lock file is used when bundle exec is used to run commands which are Ruby scripts. It is necessary
to prefix all pod commands with bundle exec once a Gemfile is used to manage versions.
Once the Gemfile is set the following commands should be used.
bundle install
bundle exec pod installIt is necessary to use bundle exec to run pod install so that it uses the version of
CocoaPods which is set in Gemfile.lock after running bundle install.
The example Gemfiles show how to use versions 0.39, 1.0 and 1.1 with the Semantic Version or with a Git reference and tag. Both configuration options make it possible to target a specific version of CocoaPods. For a pre-release version of CocoaPods it may be necessary to use a Git reference and tag as there won't be a release published yet.
The following files will be in your working folder once the gems and pods are installed and should be managed by source control. The lock files are important for managing dependency versions.
- Gemfile
- Gemfile.lock
- Podfile
- Podfile.lock
The contents of the Pods folder can also be managed in source control, which is recommended by the CocoaPods team, still many teams still choose to not include this folder in source control. Having the files in the Pods folder can cause merge conflicts are dependencies are updated which is one reason why teams choose to not include these files in source control. Alternatively, having the files in the Pods folder in your source control repository ensures you can always build your project if a dependency disappears.
You can choose what is appropriate for your team. One step you could take is to archive the contents of the Pods folder for each release. If a critical dependency does disappear it will be possible to recreate it from a previous release. It is also a good idea to fork depenencies so that if one disappears a simple update to the Podfile will allow that legacy dependency to be used.