When pod install hangs on updating the spec repo or fails to resolve a version, the fix usually involves the CDN source, cache, or version constraints. Here is how to fix it.
A pod install that hangs for a long time, often on a message about updating the spec repo, is one of the most reported CocoaPods annoyances. It usually relates to how CocoaPods fetches its index of available libraries.
Historically, CocoaPods cloned an enormous master specs repository locally, which was slow and disk-heavy. Modern CocoaPods uses a CDN-backed source instead, which is much faster when configured correctly.
Most slowness and failures come from either an outdated local specs setup, network or CDN hiccups, or an unnecessary repo update being triggered.
Understanding which of these you are hitting points you straight at the right fix rather than blindly retrying.
Look at the top of your Podfile for a source line. The modern CocoaPods CDN source is the trunk URL, and using it avoids cloning the giant legacy specs repo.
If your Podfile has no source line, CocoaPods generally defaults to the CDN, which is what you want. If it points at the old Git specs repo, consider switching to the CDN source.
The CDN resolves individual specs on demand rather than downloading everything, so installs are dramatically lighter, especially the first time on a machine.
Confirming your source is a quick, high-value check before you start clearing caches or blaming your network.
A plain pod install should not need to re-download the entire spec index every time. If it always seems to, something is forcing an update.
You can run pod install with the --no-repo-update flag to explicitly skip the spec repo refresh. If that makes the install fast, the update step was the bottleneck.
Use this when you know your specs are current and you just want to install what the Podfile requests. It is a great time-saver during iterative work.
Just be aware that if you genuinely need a newer spec that your local index lacks, you will want to allow an update, which the next section covers.
The error unable to find a specification for a pod means your local spec index does not yet know about the version you requested. This is common right after a library publishes a new release.
Run pod repo update to refresh your local spec metadata, then run pod install again. Updating the index makes the new version discoverable.
Alternatively, pod install --repo-update combines both steps in one command. It refreshes the index and then installs.
If the pod still cannot be found after updating, double-check the spelling of the pod name and that any required private source is declared in your Podfile.
If installs fail with connection timeouts or CDN errors, the problem may be transient network trouble, a corporate proxy, or a temporary CDN issue.
First, verify basic connectivity and try again after a short wait, since CDN blips are often momentary. Retrying resolves many one-off failures.
Behind a corporate firewall or proxy, ensure your environment allows CocoaPods to reach its CDN and GitHub, since some libraries fetch source from GitHub. Proxy misconfiguration is a common enterprise blocker.
If you suspect the CDN specifically, the official CocoaPods status resources and GitHub issues will indicate any known outages, so you know whether to wait or dig deeper.
Sometimes a partially downloaded or corrupted cache causes strange resolution or checksum failures. Clearing the cache forces clean downloads.
You can clear cached pods with pod cache clean followed by a pod name, or clear everything with pod cache clean --all. This removes the cached copies so the next install re-fetches them.
After clearing, run pod install again. The fresh download often resolves errors that repeated retries could not.
Combine this with removing the local Pods directory and reinstalling if a specific pod remains stubbornly broken. Clean state is a reliable reset.
If pod install reports that it cannot satisfy your constraints, two or more pods likely require incompatible versions of a shared dependency.
Read the error carefully; CocoaPods usually names the conflicting pods and the versions each demands. That message is your roadmap to the conflict.
Relax an overly strict version pin, or update one of the conflicting pods to a release that agrees on the shared dependency. Sometimes updating everything to current releases resolves it.
When conflicts are stubborn, check each library's release notes for compatibility requirements. Occasionally you must wait for a library to publish a compatible update.
Not every dependency comes from the CDN. When a Podfile entry points at a Git repository directly, CocoaPods clones that repo, and a large history can make the fetch slow.
If a specific Git-sourced pod is the bottleneck, pinning it to a tag or commit rather than a branch can help, since it gives CocoaPods a precise target instead of re-checking a moving branch.
Network access to the host matters too. If the source lives on a platform your network throttles or blocks, the clone will crawl or fail regardless of CocoaPods settings.
For internal Git-hosted pods, keeping repositories reasonably small and well-tagged keeps these fetches quick. When possible, prefer versioned releases over live branches so installs stay both fast and reproducible.
Keep CocoaPods itself updated, since improvements to the CDN handling and resolver land in newer versions. An old CocoaPods can reintroduce solved slowness.
Use --no-repo-update for routine installs and only refresh the index when you actually need a new version. This keeps day-to-day installs snappy.
Commit your Podfile.lock so teammates install known-good versions and avoid re-resolving from scratch. Reproducibility reduces surprise conflicts.
Finally, remember these are dependency-fetching issues, not problems with your app. Once resolved, you are back to building native Swift or Objective-C in Xcode, which is still what ships your app through the Apple Developer Program.
Slow installs are often caused by CocoaPods updating the entire specs repository when it does not need to.
Make sure your Podfile uses the CDN source line at the top, which lets CocoaPods fetch only the specs it needs instead of cloning a huge local index. This alone dramatically speeds up a first install on many machines.
Avoid habitually adding --repo-update to pod install; only use it when a pod genuinely cannot be found. Running a plain pod install skips the expensive index refresh.
If an install still hangs, run pod install --verbose to see exactly which step is slow, and check your network, since corporate proxies and VPNs frequently throttle the CDN and Git fetches.
It is usually re-fetching the spec index. Modern CocoaPods uses a fast CDN source, so confirm your Podfile uses it. For routine installs where your specs are current, run pod install --no-repo-update to skip the refresh entirely.
Your local spec index does not know about the requested version yet, common right after a library releases an update. Run pod repo update then pod install, or use pod install --repo-update to do both at once. Also double-check the pod name spelling.
Make sure your Podfile uses the CDN trunk source so CocoaPods resolves specs on demand instead of cloning the whole index. Use pod install --no-repo-update for routine installs, and keep CocoaPods itself up to date.
Run pod cache clean followed by a pod name to clear one pod, or pod cache clean --all to clear everything. Then run pod install again to force clean downloads, which resolves many checksum and corruption errors.
Two or more pods require incompatible versions of a shared dependency. Read the error, which names the conflict, then relax a strict version pin or update a conflicting pod to a compatible release. Sometimes you must wait for a library to publish an update.