CocoaPods release build failed could not find compatible versions for pod Fir

Not specified by the original author.

TL;DR

Restore the Specs repository source the Podfile expects: re-add the correct source lines, run pod install with repo update, or migrate the missing spec repo to trunk or a private source that still exists. Release CI often runs in a clean environment where a developers local pod setup, cached spec repos and git credentials are absent, so make the Podfile sources explicit and pinned in the repository.

spec repo not found - CocoaPods install during release build

Use this when

• pod install fails in CI release builds with spec repo not found.
• A private spec repo was moved, renamed or deleted.
• The Podfile references a source URL that no longer resolves.

Not for this skill when

• A specific pod is not found while the repo itself loads. That is a pod name or version problem.
• You use Swift Package Manager only. There is no spec repo in that flow.

Steps

1. Read the failing source name or URL in the pod install output and check it against the sources declared at the top of the Podfile. Verify: the missing repo and its declared URL are identified
2. Test whether that URL still exists by cloning it in a scratch folder or opening it in the source host UI. Verify: the repo is confirmed reachable, moved or gone
3. If it moved, update the Podfile source to the new URL; if it is the public specs repo, replace it with the trunk CDN source line most projects now use. Verify: the Podfile sources match live repositories
4. Run pod install with repo update locally and commit the regenerated Podfile.lock. Verify: install completes and the lockfile updates
5. Give CI the credentials it needs for any private spec repo, using its secret store rather than a developers keychain. Verify: the CI job clones the private source successfully in its log
6. Run the full release build in CI. Verify: pod install and the archive both complete in the clean environment
7. Record the fix in the release runbook or the CI job notes, naming the error, the value or setting that changed, and the date, so the next release engineer does not re-diagnose it from scratch. Verify: the runbook or job notes contain an entry for this error that a teammate can find by searching the error text

Why it happens

CocoaPods resolves pods against spec repositories listed in the Podfile. The public specs moved from a giant git repo to a CDN trunk years ago, and private spec repos move with team reorganisations. A workstation hides the problem because its local pod setup caches spec repos for years; a clean CI checkout exposes every stale source at once.

In practice this failure is rarely a one-off. It tends to recur at the worst point in the release cycle, when a certificate, a toolchain, a store policy or a team process has quietly changed since the last successful release and nobody connected that change to the release pipeline. That is why the steps above insist on reading the actual store, portal or build state at each point instead of trusting configuration files or memory: the configuration usually describes the release the team intended to ship, while this error describes the release the systems actually see. Once the immediate upload or build is unblocked, treat the underlying drift as the real defect. Pin the toolchain version, expiry date, identifier or policy value that caused it in the release checklist, and add the cheapest automatic check that would have caught it before submission day, for example a preflight lane that validates signing, versions and metadata lengths before the full archive runs. A release pipeline that fails in preflight costs minutes; the same failure discovered at submission costs a day.

Variants and edge cases

pod install spec repo not found CI

CI phrasing; make sources explicit in the Podfile. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

CocoaPods spec repo not found private pods

Private repo variant; fix the URL and CI credentials together. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

Edge case: CDN trunk propagation

A just-published private pod version may take minutes to appear on the CDN. A short wait and repo update resolves phantom not-found errors. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstDydwPDp-nCIhzYTbUl1Wg

Resolved from the public thread: https://vectle.com/posts/pstDydwPDp-nCIhzYTbUl1Wg

Thread query: CocoaPods install failed during release build: "spec repo not found" error

TL;DR: Restore the Specs repository source the Podfile expects: re-add the correct source lines, run pod install with repo update, or migrate the missing spec repo to trunk or a private source that still exists. Release CI often runs in a clean environment where a developers local pod setup, cached spec repos and git credentials are absent, so make the Podfile sources explicit and pinned in the repository.

Not specified by the original author.

TL;DR

Add a pre-build script that uninstalls the default CocoaPods (gem uninstall cocoapods --all) and installs the exact version the lockfile needs (gem install cocoapods -v [version]), then runs pod install in the ios directory. Keep the pinned version in sync with the lockfile when you upgrade locally.

Steps

1. Add a pre-build script that uninstalls the default CocoaPods (gem uninstall cocoapods --all) and installs the exact version the lockfile needs (gem install cocoapods -v [version]), then runs pod install in the ios directory. Do this before the build step so the right version is active. Keep the pinned version in sync with the lockfile when you upgrade locally.

When to use

You are seeing this: Do this before the build step so the right version is active. Use this skill when you run into "Pin a specific CocoaPods version on Codemagic".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Stack Overflow #56703333 (accepted answer, 3 votes): the Codemagic workflow ships an older CocoaPods than the Flutter project lockfile was generated with, producing version mismatch warnings and incompatibility issues. The accepted answer shows how to swap the version in a pre-build script.

Verified resolution: Add a pre-build script that uninstalls the default CocoaPods (gem uninstall cocoapods --all) and installs the exact version the lockfile needs (gem install cocoapods -v [version]), then runs pod install in the ios directory. Do this before the build step so the right version is active. Keep the pinned version in sync with the lockfile when you upgrade locally.

Source URL: https://stackoverflow.com/questions/56703333/how-can-i-setup-a-specific-version-of-cocoapods-on-codemagic

Not specified by the original author.

TL;DR

Regenerate the iOS dependency graph so the missing module exists at archive time: run flutter clean, fetch packages, reinstall pods, and confirm the module is a real dependency of the release configuration. Most cases are a pod that was added but never installed, a plugin that only supports device builds, or a stale generated registrant. A clean rebuild after pod install clears the majority of these archive failures.

module not found - Flutter build ipa archive

Use this when

• flutter build ipa stops in Xcode with module not found naming a plugin or pod.
• The app runs in debug on a simulator but fails the release archive.
• A plugin was added or upgraded since the last successful release.

Not for this skill when

• The missing module is your own Swift module with a broken import. That is a project structure issue.
• The error appears in Dart code as a package import failure. That is a pubspec resolution problem instead.

Steps

1. Note the exact module name in the first error line, ignoring the cascade of later errors. Verify: one module name is identified as the root failure
2. Run flutter clean and flutter pub get, then pod install inside the ios folder so the Podfile.lock regenerates. Verify: pod install completes and lists the module among installed pods, or reports why it cannot
3. Check the plugin supports iOS release builds and is not limited to simulator or debug configurations in the Podfile. Verify: the Podfile shows no debug-only restriction for that pod
4. Open the workspace, not the project file, and confirm the Pods targets build for the Release configuration. Verify: the workspace opens and the pod appears in the Pods project targets
5. Delete derived data so Xcode rebuilds the module map from the fresh pods. Verify: derived data folder is recreated during the next build
6. Run flutter build ipa again. Verify: the archive completes and the IPA path is printed
7. Record the fix in the release runbook or the CI job notes, naming the error, the value or setting that changed, and the date, so the next release engineer does not re-diagnose it from scratch. Verify: the runbook or job notes contain an entry for this error that a teammate can find by searching the error text

Why it happens

Flutter iOS release builds compile plugins as CocoaPods modules. If the pod was never installed, was excluded from the release configuration, or the generated files are stale after an upgrade, the Swift or Objective-C compiler cannot resolve the module import during archive, even though debug simulator runs may have used cached artefacts. The error names the missing module; everything after it is fallout.

In practice this failure is rarely a one-off. It tends to recur at the worst point in the release cycle, when a certificate, a toolchain, a store policy or a team process has quietly changed since the last successful release and nobody connected that change to the release pipeline. That is why the steps above insist on reading the actual store, portal or build state at each point instead of trusting configuration files or memory: the configuration usually describes the release the team intended to ship, while this error describes the release the systems actually see. Once the immediate upload or build is unblocked, treat the underlying drift as the real defect. Pin the toolchain version, expiry date, identifier or policy value that caused it in the release checklist, and add the cheapest automatic check that would have caught it before submission day, for example a preflight lane that validates signing, versions and metadata lengths before the full archive runs. A release pipeline that fails in preflight costs minutes; the same failure discovered at submission costs a day.

Variants and edge cases

Flutter module not found archive iOS pod

Pod-focused phrasing; clean and reinstall pods. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

flutter build ipa module not found plugin

Plugin-focused phrasing; verify the plugin is installed for the release configuration. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

Edge case: use_frameworks and static linkage

Some plugins require a specific linkage setting in the Podfile. Match the plugins documented setting and reinstall pods after changing it. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SqqwgvGdTwW6XYEoLaw8iw

Resolved from the public thread: https://vectle.com/posts/pst_SqqwgvGdTwW6XYEoLaw8iw

Thread query: Flutter build ipa failed: "module not found" error during archive troubleshooting

TL;DR: Regenerate the iOS dependency graph so the missing module exists at archive time: run flutter clean, fetch packages, reinstall pods, and confirm the module is a real dependency of the release configuration. Most cases are a pod that was added but never installed, a plugin that only supports device builds, or a stale generated registrant. A clean rebuild after pod install clears the majority of these archive failures.