How to update a single pod without touching other dependencies

Question

Make sure you have the latest version of CocoaPods installed.

$ pod update PODNAME was introduced recently.

See this issue thread for more information:

$ pod update

When you run pod update SomePodName, CocoaPods will try to find an updated version of the pod SomePodName, without taking into account the version listed in Podfile.lock. It will update the pod to the latest version possible (as long as it matches the version restrictions in your Podfile).

If you run pod update without any pod name, CocoaPods will update every pod listed in your Podfile to the latest version possible.

To install a single pod without updating existing ones-> Add that pod to your Podfile and use:

pod install --no-repo-update

To remove/update a specific pod use:

pod update POD_NAME

Tested!

It's 2015

So because pod update SomePod touches everything in the latest versions of cocoapods, I found a workaround.

Follow the next steps:

1. Remove SomePod from the Podfile

2. Run pod install

pods will now remove SomePod from our project and from the Podfile.lock file.

3. Put back SomePod into the Podfile

4. Run pod install again

This time the latest version of our pod will be installed and saved in the Podfile.lock.

just saying:

pod install - for installing new pods,

pod update - for updating existing pods,

pod update podName - for updating only specific pod without touching other pods,

pod update podName versionNum - for updating / DOWNGRADING specific pod without touching other pods

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 pod
• pod 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.

Using exact versions in the Podfile is not enough

Some 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:

• user1 might end up with pod A2 in version 3.4 (because that was A2's latest version at that time)
• while when user2 runs 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