How to Check the Installed Version of a CocoaPods Pod

Why this happens

Two different things are called “version” in a CocoaPods project, and the output of pod install does not make it obvious which one you are looking at.

The first is the version of the CocoaPods tool itself — the Ruby gem you run as pod. The second is the version of each individual pod (FlurrySDK, Alamofire, Firebase, and so on) that CocoaPods resolved and installed into your workspace. Running pod --version answers only the first question. The line Installing FlurrySDK (4.2.3) answers the second, but only for that one run and only in your terminal scrollback.

There is a second source of confusion: CocoaPods does not re-resolve versions on every install. Once a version is written into Podfile.lock, pod install keeps using that exact version. That is why an update can appear to do nothing — the lockfile is still pinning the old one. The lockfile, not the terminal output, is the source of truth.

How to fix it

1. Read the resolved version from Podfile.lock

Podfile.lock is generated next to your Podfile and records the exact version of every pod that was installed. Open it and find the PODS: section:

PODS:
  - FlurrySDK (4.2.3)

DEPENDENCIES:
  - FlurrySDK

SPEC CHECKSUMS:
  FlurrySDK: <checksum>

PODFILE CHECKSUM: <checksum>

COCOAPODS: 1.15.2

The number in parentheses after the pod name is the installed version. If the pod ships subspecs, you will see several lines, all sharing the same version:

PODS:
  - FlurrySDK (4.2.3)
  - FlurrySDK/Core (4.2.3)

The COCOAPODS: line at the bottom records which version of the CocoaPods tool generated the file — useful when a teammate’s build behaves differently from yours.

Do not edit this file by hand. It is regenerated by pod install and pod update.

2. Grep for one pod instead of scrolling

On a large project the lockfile is long. Search it directly from the project folder:

grep -n "FlurrySDK" Podfile.lock

That prints every matching line with its line number, including the version in parentheses. It also works for checking whether a pod is present at all.

3. Ask CocoaPods what is outdated

To see whether a newer version exists than the one in your lockfile, run:

pod outdated

CocoaPods compares the versions in Podfile.lock against the specs in your local spec repos and prints the pods that have updates available, with the currently locked version and the newer one. If FlurrySDK does not appear in that list, you are already on the newest version your spec repos know about. If it does appear, the lockfile is holding you back until you explicitly update.

4. Check the CocoaPods tool version separately

These commands answer the other question — which CocoaPods installation you are running:

pod --version
gem list cocoapods
which pod

pod --version prints the version of the pod executable on your PATH. gem list cocoapods shows every installed CocoaPods gem, which matters if you have more than one Ruby environment (system Ruby, rbenv, rvm, asdf). which pod tells you which binary actually runs, so you can confirm it belongs to the Ruby you think it does.

pod env prints a fuller picture: the CocoaPods version, the Ruby version and paths, the installation root, and the spec repos in use. It is the fastest way to diagnose “it works on my machine” differences.

5. Update one pod and confirm the result

If the lockfile shows an older version than you want, update that single pod rather than everything:

pod update FlurrySDK

Then re-read the lockfile to confirm the change:

grep "FlurrySDK" Podfile.lock

You can also pin the version in the Podfile so it cannot drift:

pod 'FlurrySDK', '4.2.3'

After editing the Podfile, run pod install — not pod update — so CocoaPods respects the constraint you just wrote.

6. If the project uses Bundler, check Gemfile.lock

Many teams pin CocoaPods itself with Bundler so everyone runs the same tool version. In that setup the Gemfile contains a line like:

gem 'cocoapods', '1.15.2'

and the resolved tool version lives in Gemfile.lock. Run CocoaPods through Bundler so the pinned version is used:

bundle exec pod install
bundle exec pod --version

If pod --version and bundle exec pod --version disagree, you are running the wrong installation for that project.

7. Watch for “Using” versus “Installing”

When pod install prints Using FlurrySDK (4.2.3), the pod was already at that version and nothing changed. When it prints Installing FlurrySDK (4.2.3), CocoaPods wrote that version into the sandbox during this run. Seeing Installing for the same version twice usually means the Pods directory was cleaned or the lockfile was removed.

How to prevent it

• Commit Podfile.lock to version control so every machine and CI job resolves the same pod versions.
• Use pod update PODNAME for a targeted upgrade; plain pod update re-resolves every pod and produces large, hard-to-review diffs.
• Pin critical dependencies in the Podfile with an explicit version when a surprise upgrade would break the build.
• Never hand-edit Podfile.lock — let pod install regenerate it.
• Keep Pods/Manifest.lock in sync. It is a copy of Podfile.lock, and Xcode fails the build with The sandbox is not in sync with the Podfile.lock when the two differ.
• Pin the CocoaPods gem with Bundler if your team has mixed Ruby setups.

FAQ

Does pod --version tell me which version of my framework is installed?

No. It prints the version of the CocoaPods command-line tool. The installed version of each pod is recorded in Podfile.lock under the PODS: section.

Why did pod install not update my pod to the latest version?

Because pod install only resolves versions that are not already pinned in Podfile.lock. To move a pod to a newer version, run pod update PODNAME, then check the lockfile again.

Where does CocoaPods store the version it actually built with?

The resolved versions live in Podfile.lock, and a copy is kept at Pods/Manifest.lock. The COCOAPODS: line at the bottom of Podfile.lock records the tool version that generated the file.