Introduction

If CocoaPods fails to reinstall after you removed it, the root cause is usually not CocoaPods itself. Most reinstall problems come from a mismatched Ruby environment, stale gem binaries left on your PATH, missing Xcode command line tools, or permission issues caused by mixing system Ruby with user-managed gems. The fastest fix is to verify which Ruby and gem directory you are actually using before you install anything again.

Start With Environment Checks

On macOS, pod is just a Ruby gem executable. That means a reinstall succeeds only if your shell, Ruby, and gem paths all point to the same toolchain. Start by inspecting the active environment:

1which ruby
2ruby -v
3which gem
4gem env home
5which pod

If which pod still points to an old location after uninstalling, you probably removed the gem from one Ruby installation but your shell is still seeing a leftover executable from another one. That happens often when developers switch between:

• system Ruby
• Homebrew Ruby
• 'rbenv'
• 'rvm'

Until those paths are consistent, reinstall attempts tend to fail in confusing ways.

Clean Out the Old Installation

Before reinstalling, remove stale executables and confirm that the shell no longer finds pod.

gem uninstall cocoapods
hash -r
which pod

If which pod still prints a path, inspect and remove that leftover binary manually:

ls -l "$(which pod)"
rm -f "$(which pod)"
hash -r

Do this carefully and only after confirming the file is an orphaned gem stub. The goal is not to delete random system tools, only to remove a stale pod launcher that is masking the real installation state.

Install With a Consistent Ruby Setup

The most reliable approach is to avoid the system Ruby and use a user-managed Ruby environment. If you already use rbenv or rvm, activate that Ruby first and then install CocoaPods normally:

ruby -v
gem install cocoapods
pod --version

If you must use the system Ruby, permission errors are common because the system gem directory is protected. In that case, developers often reach for sudo gem install cocoapods, which can work, but it also mixes privileged files into a setup that is harder to maintain. A cleaner option is to install gems into a user directory:

1mkdir -p "$HOME/.gem/bin"
2export GEM_HOME="$HOME/.gem"
3export PATH="$HOME/.gem/bin:$PATH"
4gem install cocoapods
5pod --version

If that works, make the GEM_HOME and PATH changes permanent in your shell profile.

Check Xcode Command Line Tools

CocoaPods depends on the Apple development toolchain. If Ruby installs cleanly but pod install fails later with native extension or build errors, verify the command line tools:

xcode-select -p
xcodebuild -version

If those commands fail, reinstall the tools:

xcode-select --install

After installation, accept any pending Xcode license prompt:

sudo xcodebuild -license

That step is easy to miss, and some CocoaPods operations fail until the toolchain is fully initialized.

When Homebrew Is Involved

Some developers install Ruby through Homebrew and then install CocoaPods through gem. That setup is fine, but make sure Homebrew Ruby appears earlier on PATH than the system Ruby:

1brew install ruby
2echo 'export PATH="/opt/homebrew/opt/ruby/bin:$PATH"' >> ~/.zshrc
3source ~/.zshrc
4ruby -v
5gem install cocoapods

On Intel Macs, the Homebrew prefix may be /usr/local instead of /opt/homebrew. The important part is consistency: the ruby, gem, and pod commands should all come from the same installation flow.

Verify the Reinstall End to End

Once pod --version succeeds, test it in a project directory instead of assuming the issue is gone:

cd /path/to/ios/project
pod repo update
pod install

If the command now fails with a project-specific message, the reinstall problem is solved and you are dealing with a different CocoaPods issue, such as an invalid Podfile or an outdated source repo.

Common Pitfalls

The most common pitfall is uninstalling CocoaPods from one Ruby and reinstalling it into another. The command names look the same, but the gem homes are different, so the shell keeps finding the wrong binary.

Another pitfall is using sudo once and then later switching back to a user-local gem setup. That can leave files behind in multiple directories and make future upgrades harder.

Developers also forget to clear the shell command cache with hash -r after removing or reinstalling executables. That can make it look like the old pod command still exists even after you deleted it.

Finally, do not treat every failure as a CocoaPods package-manager bug. If Ruby, Xcode tools, or PATH are inconsistent, CocoaPods is just the first thing that exposes the environment problem.

Summary

• Reinstall failures usually come from Ruby path mismatches, stale pod binaries, or permission issues.
• Check which ruby, which gem, and which pod before reinstalling.
• Prefer a user-managed Ruby environment over the system Ruby when possible.
• Verify Xcode command line tools because CocoaPods depends on them.
• After reinstalling, run pod install in a real project to confirm the toolchain works end to end.