Cocoapods
Downgrade Cocoapods
Install Older Version
Ruby Gems
Software Version Control

How to downgrade or install an older version of Cocoapods

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Teams often need an older CocoaPods version because existing iOS projects were generated and locked against a specific toolchain. Installing the wrong version can create lockfile churn, dependency resolution changes, and inconsistent CI behavior. The safest downgrade workflow is the one that stays reproducible per project instead of depending on machine-wide shell state.

Check Current CocoaPods Source and Version

Before changing anything, verify what binary is actually running. Many machines have CocoaPods from both Homebrew and RubyGems.

bash
1which pod
2pod --version
3gem list cocoapods
4brew list --versions cocoapods

If which pod points to a Homebrew path while your team expects Bundler and gems, fix that mismatch first.

Install a Specific Version with RubyGems

To install an older global version via gems:

bash
sudo gem install cocoapods -v 1.11.3
pod --version

To remove an unwanted version:

bash
sudo gem uninstall cocoapods -v 1.13.0

This can work for single project machines, but global installs are fragile when you switch between repos with different requirements.

For team consistency, define CocoaPods in a Gemfile and run it through Bundler so local machines and CI use the same executable path.

ruby
source "https://rubygems.org"

gem "cocoapods", "1.11.3"

Install and use:

bash
bundle install
bundle exec pod --version
bundle exec pod install

This ensures local and CI environments use the same version without relying on global shell state.

Use a Ruby Version Manager for Isolation

Ruby managers such as rbenv or rvm isolate gem environments and reduce cross project conflicts.

bash
1rbenv install 3.1.4
2rbenv local 3.1.4
3gem install bundler
4bundle install
5bundle exec pod install

Pairing project Ruby version with project CocoaPods version gives predictable onboarding and fewer environment specific bugs.

Resolve Homebrew and Gem Path Conflicts

If Homebrew CocoaPods is not part of your workflow, remove it to reduce ambiguity.

bash
brew uninstall cocoapods
hash -r
which pod

Then verify that pod resolves from your Ruby environment or use bundle exec pod consistently.

CI Setup for Deterministic Pod Installs

CI should always run through Bundler, even if global CocoaPods is installed on the runner.

bash
bundle config set path vendor/bundle
bundle install --jobs 4 --retry 3
bundle exec pod install --repo-update

Commit both Gemfile and Gemfile.lock so new environments resolve the same gem versions.

Practical Downgrade Workflow

A clean downgrade process for an existing project:

  1. Add or update Gemfile with target CocoaPods version.
  2. Run bundle install.
  3. Run bundle exec pod --version to confirm.
  4. Run bundle exec pod deintegrate.
  5. Run bundle exec pod install.
  6. Verify iOS build and test steps.

The reintegration step catches hidden plugin and environment drift that plain install might miss.

Troubleshooting Common Errors

If installation fails, check these areas:

  • Ruby version incompatible with selected CocoaPods release.
  • Outdated RubyGems or Bundler.
  • Missing Xcode command line tools.
  • Broken permissions in gem directories.

Useful repair commands:

bash
1gem update --system
2gem install bundler
3xcode-select --install
4bundle exec pod repo update

On Apple Silicon, make sure the Ruby environment and native gems match architecture expectations.

Common Pitfalls

  • Downgrading globally and assuming every project should use that same version.
  • Running plain pod install after pinning version in Bundler.
  • Keeping both Homebrew and gem CocoaPods binaries and not controlling shell path precedence.
  • Editing lockfiles with one version and installing with another.
  • Treating version check as enough without validating a full clean install cycle.

Summary

  • Confirm current CocoaPods source before changing versions.
  • Use RubyGems global install only when machine scope control is acceptable.
  • Prefer Bundler pinning for per project reproducibility.
  • Use Ruby version managers to isolate environments across repositories.
  • Enforce bundle exec pod in local and CI workflows to avoid hidden tool drift.

Course illustration
Course illustration

All Rights Reserved.