CocoaPods how to install only one new library

Question

I have a list of libraries in my Pod file. I decide to add new one to Pod file. But I want to keep all my previous libraies without updates and just install (add) this one library

pod 'JSAnimatedImagesView', '~> 1.0.0'

so pod update and pod install update all libraries to newer versions, but I don't want to update them just install pod 'JSAnimatedImagesView', '~> 1.0.0'

Answer 1

pod install --no-repo-update

This installs new items without updating existing repos (versioned or not).

It's also just quicker if you have a lot of repos and want a fast install of a new item.

Answer 2

(As of March 15, 2019)

To install 1 new pod: add the 1 desired new pod into your Podfile. Then run:

pod install --no-repo-update

It will not update any other pods when running this.

Answer 3

If you don't want to update the specific libraries you should lock them at the versions you want to keep

pod 'AFNetworking', '1.2.0'
pod 'JSAnimatedImagesView', '~> 1.0.0'

Would keep AFNetworking on V1.2.0 but get the latest JSAnimatedImagesView

This makes the podfile transferrable to other locations (and developers) and saves you from forgetting to revert your podfile until you intend to update pods

Answer 4

When starting out with a project it is likely that you will want to use the latest version of a Pod. If this is the case, simply omit the version requirements.

pod 'SSZipArchive'

Later on in the project you may want to freeze to a specific version of a Pod, in which case you can specify that version number.

pod 'Objection', '0.9'

More info http://guides.cocoapods.org/syntax/podfile.html#pod

Answer 5

You can try to use update command https://guides.cocoapods.org/terminal/commands.html#pod_update

pod update [POD_NAMES ...]

Updates the Pods identified by the specified POD_NAMES. If no POD_NAMES are specified it updates all the Pods ignoring the contents of the Podfile.lock.

Answer 6

Add new pod repo to your podfile and use bellow command

pod install

Source of example form pod install vs. pod update

Scenario Example

Here is a scenario example to illustrate the various use cases one might encounter during the life of a project.

Stage 1: User1 creates the project

user1 creates a project and wants to use pods A,B,C. They create a Podfile with those pods, and run pod install.

This will install pods A,B,C, which we'll say are all in version 1.0.0.

The Podfile.lock will keep track of that and note that A,B and C are each installed as version 1.0.0.

Incidentally, because that's the first time they run pod install and the Pods.xcodeproj project doesn't exist yet, the command will also create the Pods.xcodeproj and the .xcworkspace, but that's a side effect of the command, not its primary role.

Stage 2: User1 adds a new pod

Later, user1 wants to add a pod D into their Podfile.

They should thus run pod install afterwards, so that even if the maintener of pod B released a version 1.1.0 of their pod since the first execution of pod install, the project will keep using version 1.0.0 — because user1 only wants to add pod D, without risking an unexpected update to pod B.

That's where some people get it wrong because they use pod update here — probably thinking this as "I want to update my project with new pods"? — instead of using pod install — to install new pods in the project.

Stage 3: User2 joins the project

Then user2, who never worked on the project before, joins the team. They clone the repository then use pod install.

The contents of Podfile.lock (which should be committed to the git repo) will guarantee they will get the exact same pods, with the exact same versions that user1 was using.

Even if a version 1.2.0 of pod C is now available, user2 will get the pod C in version 1.0.0. Because that's what is registered in Podfile.lock. pod C is locked to version 1.0.0 by the Podfile.lock (hence the name of this file).

Stage 4: Checking for new versions of a pod

Later, user1 wants to check if any updates are available for the pods. They run pod outdated which will tell them that pod B has a new 1.1.0 version, and pod C have a new 1.2.0 version released.

user1 decides they want to update pod B, but not pod C; so they will run pod update B which will update B from version 1.0.0 to version 1.1.0 (and update the Podfile.lock accordingly) but will keep pod C in version 1.0.0 (and won't update it to 1.2.0).