Troubleshoot the most common Firebase dependency failures on iOS: Swift Package Manager resolution conflicts, missing modules, and pod install errors, with fixes ordered by likelihood.
Firebase dependency problems show up in a handful of recognizable ways, and identifying which one you have narrows the fix. With Swift Package Manager, you might see package resolution failures where Xcode reports it cannot resolve firebase-ios-sdk to a compatible version, or a build error reading No such module 'FirebaseCore' or 'FirebaseFirestore' even though the package appears added. With CocoaPods, pod install may fail outright with dependency conflict messages, complaints about an incompatible platform version in the Podfile, or a successful install that then breaks the build with linker or module errors. You may also hit duplicate symbol errors if you accidentally integrate Firebase through both SPM and CocoaPods at once. The common thread is that Firebase is a large, modular, actively updated SDK with its own transitive dependencies like GoogleUtilities and gRPC, so version alignment and correct target membership matter more than with a small single-purpose library. Read the exact error text carefully, because it usually names the offending package or module, which tells you which of the fixes below to try first. Note the integration method you used and the Firebase version you are on, since those two facts determine most of what follows.
The most common self-inflicted failure is integrating Firebase through both Swift Package Manager and CocoaPods in the same project, which produces duplicate symbols, conflicting module definitions, and baffling linker errors. Pick one integration method and remove the other completely. If you want SPM, run pod deintegrate in the project directory, delete the Podfile, Podfile.lock, the Pods directory, and open the .xcodeproj rather than the .xcworkspace afterward, then add Firebase through File, Add Package Dependencies. If you want CocoaPods, remove the Firebase Swift packages from your project's Package Dependencies list and clean the build folder. After switching, delete derived data and do a clean build. This single mistake accounts for a large share of Firebase dependency reports, especially in projects that started with one manager and had Firebase added later with the other. Decide deliberately, and going forward keep every dependency in the chosen system so you never reintroduce the conflict. If you genuinely need both managers for unrelated dependencies, make absolutely sure Firebase itself lives in only one of them, because it is the duplication of Firebase's own modules that triggers the duplicate-symbol failures.
When Xcode cannot resolve firebase-ios-sdk, the cause is usually a version rule that conflicts with another package or a stale resolved-versions cache. First, in your project's Package Dependencies, check the version rule on firebase-ios-sdk; the safest choice is Up to Next Major Version starting from a recent release, which lets Xcode pick a compatible patch. If another package depends on a shared library like abseil or gRPC at an incompatible version, you may need to update that other package too. Then reset the resolution cache: in Xcode, choose File, Packages, Reset Package Caches, followed by File, Packages, Resolve Package Versions. If that stalls, close Xcode, delete the derived data folder and the Package.resolved file (found inside the .xcodeproj or .xcworkspace under xcshareddata/swiftpm), reopen, and let Xcode resolve fresh. Network issues behind a proxy can also cause resolution to hang, so confirm Xcode can reach github.com. After a clean resolve, build again; most version conflicts disappear once the cache is cleared and a compatible major version rule is set. If a specific transitive dependency is the sticking point, pinning firebase-ios-sdk to a slightly older but known-good release while you sort out the other package is a reasonable temporary measure.
A No such module error after the package resolves fine almost always means the specific Firebase library is not linked to the target that imports it. The Firebase package is modular, so adding the package is not enough; each product like FirebaseAuth or FirebaseFirestore must be explicitly added to your app target. Select your project in the navigator, choose the target, open the General tab, and look under Frameworks, Libraries, and Embedded Content. Confirm the Firebase products you import are listed there for that target. If one is missing, click the plus button, and add it from the resolved firebase-ios-sdk package. This is especially easy to miss when you have multiple targets, such as an app plus a widget or notification service extension, since each target needs its own product membership. Also ensure you are importing the correct module name, for example import FirebaseFirestore, not a guessed name. After linking the product to the target and rebuilding, the module import resolves. Clean the build folder first if the error persists from a cached state. If you use a shared framework or Swift package of your own that imports Firebase, remember that the final app target still needs the Firebase products linked so the symbols are present at link time.
If you are on CocoaPods and pod install fails, work through the likely causes in order. First, update the tool and repo: run gem install cocoapods to get a current version and pod repo update to refresh the spec index, since an outdated local spec repo frequently causes it to miss newer Firebase releases. Second, check your Podfile's platform line; Firebase requires a modern minimum iOS deployment target, so a line like platform :ios, '15.0' or newer, matching your project's actual deployment target, prevents version-unsatisfiable errors. Third, if you see conflicts, delete Podfile.lock and the Pods folder and run pod install again to let CocoaPods re-resolve from scratch. For persistent, hard-to-diagnose resolution problems, pod install --repo-update forces a spec refresh during install. After a successful install, always open the generated .xcworkspace, never the .xcodeproj, or your build will not see the pods. If linker errors remain, clean the build folder and delete derived data before rebuilding. It also helps to confirm your Podfile uses use_frameworks! where required for Swift pods, since Firebase's Swift-facing modules expect a framework or static-framework linkage rather than the old static-library default.
Firebase drops support for old iOS versions and old Xcode versions over time, so a mismatch between your project settings and the SDK's requirements produces errors that look like dependency problems but are really compatibility problems. Check that your target's minimum deployment target meets Firebase's current requirement; if your project targets an iOS version older than Firebase supports, resolution or build will fail, and raising the deployment target fixes it. Similarly, a very new Firebase release may require a newer Xcode and Swift toolchain than you have installed, so if you recently updated Firebase and builds broke, confirm your Xcode version is current or pin Firebase to a version compatible with your Xcode. The firebase-ios-sdk release notes and README document the minimum Xcode, Swift, and iOS versions for each release. When in doubt, either update Xcode or set the Firebase package's version rule to an earlier release that matches your toolchain, then reset caches and rebuild. Aligning these three, deployment target, Xcode, and SDK version, resolves a whole class of otherwise confusing failures. Before any major Firebase upgrade, read the release notes for the new minimum requirements so you can update Xcode first rather than discovering the requirement mid-build.
When you have tried a specific fix and things are still broken, a full clean often clears cached corruption. Close Xcode, delete the derived data directory (in Xcode, Settings, Locations shows its path), remove Package.resolved for SPM or Podfile.lock and Pods for CocoaPods, reopen the project, let dependencies resolve, then do Product, Clean Build Folder before building. This sequence resolves many stubborn errors that survive individual fixes because they were caused by stale build artifacts rather than your configuration. To prevent recurrence, commit your Package.resolved or Podfile.lock to version control so your whole team resolves to the same versions, avoid mixing dependency managers, and upgrade Firebase deliberately by reading the release notes rather than blindly jumping to the latest major version. When you do upgrade, bump one major change at a time and test the build before adding more. Treating the SDK version, your Xcode version, and your deployment target as a single coordinated set is the durable way to keep Firebase dependency issues from coming back. A short written note in your repository documenting the chosen integration method and the current Firebase version spares the next developer from reintroducing the very conflicts you just cleared.
No, not for the same dependency. Integrating Firebase through both at once causes duplicate symbols and module conflicts. Choose one manager, fully remove the other (deintegrate CocoaPods or delete the Swift packages), clean derived data, and rebuild. Mixing them is one of the most common causes of Firebase dependency errors.
The package resolved, but the specific Firebase product is not linked to your target. Firebase is modular, so each library must be added to the target under General, Frameworks, Libraries, and Embedded Content. Add the missing product to every target that imports it, including extensions, then clean and rebuild.
Set the version rule to Up to Next Major Version from a recent release, then File, Packages, Reset Package Caches and Resolve Package Versions. If it still fails, close Xcode, delete derived data and Package.resolved, reopen, and let it resolve fresh. Also confirm Xcode can reach github.com if you are behind a proxy.
Update CocoaPods with gem install cocoapods, refresh specs with pod repo update, and make sure your Podfile's platform line meets Firebase's minimum iOS version. If conflicts persist, delete Podfile.lock and the Pods folder and run pod install --repo-update. Afterward, open the .xcworkspace, not the .xcodeproj.
Yes. Firebase raises its minimum iOS, Xcode, and Swift requirements over time. If your deployment target or Xcode is older than the Firebase release requires, you get build failures that look like dependency issues. Either raise the deployment target and update Xcode, or pin Firebase to a version compatible with your toolchain.
Do a full clean: quit Xcode, delete derived data, remove Package.resolved (SPM) or Podfile.lock and Pods (CocoaPods), reopen, let dependencies re-resolve, then Product, Clean Build Folder before building. This clears stale artifacts that cause errors surviving more targeted fixes.