You can never get 100% isolation. Because a pod may have some shared dependencies and if you attempt to update your single pod, then it would update the dependencies of other pods as well. If that is ok then:
tl;dr use:
pod update podName
Why? Read below.
pod update
will NOT respect the podfile.lock
. It will override it — pertaining to that single podpod install
will respect the podfile.lock
, but will try installing every pod mentioned in the podfile based on the versions its locked to (in the Podfile.lock).This diagram helps better understand the differences:
The major problem comes from the ~>
aka optimistic operator.
Podfile
is not enoughSome might think that specifying exact versions of their pods in their Podfile
, like pod 'A', '1.0.0'
, is enough to guarantee that every user will have the same version as other people on the team.
Then they might even use pod update
, even when just adding a new pod, thinking it would never risk updating other pods because they are fixed to a specific version in the Podfile
.
But in fact, that is not enough to guarantee that user1 and user2 in our above scenario will always get the exact same version of all their pods.
One typical example is if the pod A
has a dependency on pod A2
— declared in A.podspec
as dependency 'A2', '~> 3.0'
. In such case, using pod 'A', '1.0.0'
in your Podfile will indeed force user1 and user2 to both always use version 1.0.0 of the pod A, but:
A2
in version 3.4
(because that was A2
's latest version at that time)pod install
when joining the project later, they might get pod A2
in version 3.5
(because the maintainer of A2
might have released a new version in the meantime).
That's why the only way to ensure every team member work with the same versions of all the pod on each's the computer is to use the Podfile.lock
and properly use pod install
vs. pod update
.The above excerpt was all derived from pod install vs. pod update
I also highly recommend watching what does a podfile.lock
do