Why should you include Podfile.lock under version control?

Question

First of all, I'd like to mention that I've read the cocoapods guide https://guides.cocoapods.org/using/pod-install-vs-update.html

Still it seems somewhat unclear why should we commit Podfile.lock, in a setup where everyone is using only pod install command and we have all versions specified strictly in the podfile. The .lock file seems redundant then.

Let's say we have a project that uses ReactiveSwift. ReactiveSwift has dependency on Result pod in its podspec as follows:

  s.dependency 'Result', '~> 3.2' 

My assumption is that I shouldn't really care what the ReactiveSwift depends on, since i'm just gonna do a pod install of my strictly specified ReactiveSwift version.

For the pods that I develop myself, i can influence their podfile and podspec to strictly specify one version that i would like to use.

So the simplified flow in my project without podfile.lock would be:

1. Develop a feature, if it needs a change in a dependency version - just directly specify it in a podfile, without ever commiting the Podfile.lock

2. Merge the feature to master branch, the CI then runs a pod install command with the new podfile

3. Now the CI has all correct versions of pods its using and can correctly build my app

Would the Podfile.lock be needed in that scenario ?

Answer 1

Your Podfile specifies the versions of your direct dependencies, but it can allow a bit of ambiguity. For instance, maybe you need version 2.2 of a library, but you don't care if you get 2.2.1 or 2.2.2. The first time you do a pod install, Cocoapods will just get the latest version of 2.2.x.

However, maybe 2.2.2 has a bug that you unknowingly depend on in your app. The maintainer releases 2.2.3, and if you haven't checked in your lock file one of your co-workers or maybe your CI system builds a crashing version of the app and causes all sorts of confusion. (It still works on your machine!)

In addition to locking down the exact versions of your direct dependencies, locking down your transitive dependencies is just as important.

In summary, Podfile.lock makes sure you don't accidentally upgrade the libraries you pull in, while keeping your Podfile concerned only with your direct dependencies.

Answer 2

First of all, I would like to reference the official doc:

What is Podfile.lock

This file is generated after the first run of pod install, and tracks the version of each Pod that was installed. For example, imagine the following dependency specified in the Podfile:

pod 'RestKit'

Running pod install will install the current version of RestKit, causing a Podfile.lock to be generated that indicates the exact version installed (e.g. RestKit 0.10.3). Thanks to the Podfile.lock, running pod install on this hypothetical project at a later point in time on a different machine will still install RestKit 0.10.3 even if a newer version is available. CocoaPods will honour the Pod version in Podfile.lock unless the dependency is updated in the Podfile or pod update is called (which will cause a new Podfile.lock to be generated).

---

Back to your question:

As you mentioned above, if you're in a setup where everyone is only using pod install command and every dependency version is specified strictly in the podfile and the related podspec, then Podfile.lock seems redundant.

However, I argue this is rare, and not the common usage case of Cocoapods.

For example, we can

• Ignore specifying version to always use the latest version of the pod, like pod 'RestKit'
• Use operator ~> 0.1.2 to specify version 0.1.2 and the versions up to 0.2, not including 0.2
• Add 3rd party pods, which podspecs are not under the control
• etc

In these case, committing Podfile.lock will be pretty useful.

---

btw, I think the question title is better changed from

Why should you include Podfile.lock under version control?

to

Why should I include Podfile.lock under version control in this scenario?