Fix: CocoaPods Specs Repository Is Too Out-of-Date in Flutter iOS

You add or upgrade a Flutter plugin, often firebase_core or firebase_crashlytics. Android builds fine. On iOS, flutter run stops during pod install with this error:

CocoaPods's specs repository is too out-of-date to satisfy dependencies.

Running pod repo update on its own often changes nothing. Here is why, and how to clear it.

Why this happens

CocoaPods resolves versions from two places. The first is your Podfile.lock, which records the exact version of every pod from the last successful install. The second is the local copy of the spec repository (the trunk CDN cache in ~/.cocoapods/repos). When a version you need isn’t in either place, CocoaPods reports that the specs repo is out of date.

In Flutter projects the lock file is usually the real problem. Your log may show a line like Using Firebase SDK version '6.26.0' defined in 'firebase_core' while the new plugin needs a newer Firebase pod. Podfile.lock still pins the old Firebase version. CocoaPods won’t move a locked pod during a plain pod install, so the dependency graph can’t be satisfied. That’s why pod repo update alone doesn’t help: the repo gets refreshed, but the lock file still holds the old version.

A second, related failure shows up once the versions resolve. Newer Firebase pods need a higher minimum iOS version than the default CocoaPods assigns when the Podfile’s platform line is commented out.

How to fix it

1. Reset Pods and Podfile.lock, then reinstall

This is the fix most people need. Run each command from your Flutter project root:

flutter clean
rm -rf ios/Pods
rm -f ios/Podfile.lock
flutter pub get
cd ios
pod install --repo-update
cd ..
flutter run

What each step does:

• flutter clean removes old build output.
• Deleting ios/Pods and ios/Podfile.lock removes the pinned versions, so CocoaPods can resolve again from scratch.
• flutter pub get regenerates the plugin symlinks and Generated.xcconfig that the Podfile depends on.
• pod install --repo-update refreshes the spec repo and installs in one step.

A common one-liner version of this uses rm -rf /ios/Pods with a leading slash. That points at a folder in the root of your disk, not your project, so it silently does nothing. Use the relative path ios/Pods as shown above.

If you prefer one line, chain the commands with && so the sequence stops at the first failure:

flutter clean && rm -rf ios/Pods ios/Podfile.lock && flutter pub get && cd ios && pod install --repo-update && cd .. && flutter run

2. Update only the pods that are stuck

You may not want to throw away the whole lock file, for example on a team project where other pod versions should stay fixed. In that case, update just the pods that conflict:

cd ios
pod update Firebase

Unlike pod install, pod update <PodName> is allowed to move a locked pod to a newer version. It then updates that pod’s dependencies to match. Commit the new Podfile.lock afterward so your teammates get the same resolution.

3. Rebuild the local trunk spec cache

If the error persists even with no lock file, the local CDN cache may be corrupted or stale. Remove it and let CocoaPods download it again:

pod repo remove trunk
cd ios
pod install --repo-update

The next install re-creates the trunk source. Expect the first run to take a bit longer.

4. Raise the iOS deployment target in the Podfile

After the versions resolve, you may hit a follow-up error like this:

[!] CocoaPods could not find compatible versions for pod "cloud_firestore":
...
Specs satisfying the dependency were found, but they required a higher minimum deployment target.

You may also see a warning that CocoaPods is Automatically assigning platform iOS with version 9.0 on target Runner. Open ios/Podfile, uncomment the platform line near the top, and set a version that your Firebase plugins support:

platform :ios, '12.0'

Check the plugin’s documentation for its current minimum, because it goes up over time. Then make the Runner target’s iOS Deployment Target in Xcode (Build Settings) match or exceed this value, and run pod install --repo-update again.

5. Apple silicon Macs: check your CocoaPods install

Older guides tell M1 users to run sudo arch -x86_64 gem install ffi and then arch -x86_64 pod install --repo-update. That workaround dates from early Apple silicon, when CocoaPods’ ffi dependency had no native build. A current CocoaPods install runs natively, so first try updating CocoaPods itself (for example brew upgrade cocoapods if you installed it with Homebrew). Use the Rosetta commands only as a fallback if you see ffi-related load errors.

6. Upgrade plugins together

FlutterFire plugins share one Firebase iOS SDK version, which firebase_core defines. If you bump firebase_crashlytics but leave firebase_auth or firebase_messaging on old releases, their pod requirements can conflict. Upgrade all firebase_* packages in pubspec.yaml to compatible releases at the same time, run flutter pub get, then repeat fix 1.

How to prevent it

• Upgrade all Firebase/FlutterFire packages together, never one at a time.
• After changing plugin versions, run pod install --repo-update instead of plain pod install.
• Keep the platform :ios line uncommented in your Podfile with an explicit version.
• Commit Podfile.lock, and use pod update <PodName> for intentional upgrades so the whole team resolves the same versions.
• Keep CocoaPods itself current so it understands the latest trunk CDN format.

FAQ

Is it safe to delete Podfile.lock?

Yes. CocoaPods regenerates it on the next pod install. The only cost is that every pod may resolve to a newer version allowed by your constraints, so test the build afterward and commit the new lock file.

Why does Android build fine but iOS fails?

Android resolves native dependencies through Gradle, which doesn’t use CocoaPods’ lock file or spec repo. The iOS side has its own pinned versions in Podfile.lock, so it can fall out of sync with your updated pubspec.yaml.

What’s the difference between pod repo update and pod update?

pod repo update only refreshes the local list of available pod specs. pod update actually changes the versions in your project and rewrites Podfile.lock. A locked old version needs the second one, or a deleted lock file.