Introduction

The CocoaPods error about not finding compatible versions for Firebase/CoreOnly usually means your dependency graph is asking for incompatible Firebase versions at the same time. Firebase/CoreOnly is often pulled in indirectly, so the real fix is to align pod versions and update the local specs source rather than trying random Podfile edits.

Why Firebase/CoreOnly Appears in the Error

You often do not add Firebase/CoreOnly directly. Other Firebase pods depend on it internally. When CocoaPods prints an error mentioning it, that usually means:

• one pod requires one Firebase version range
• another pod or plugin requires a different range
• CocoaPods cannot choose a single version that satisfies both

A typical example is mixing an older plugin with newer Firebase pods in the same project. The error message names the internal pod because that is where the version ranges collide.

Start by Updating the Specs and Inspecting the Podfile

First, make sure your local podspec repo is up to date:

pod repo update
pod install

Or in one step:

pod install --repo-update

Then inspect the Podfile for version mismatches. A cleaner Podfile usually looks like this:

1platform :ios, '13.0'
2
3target 'MyApp' do
4  use_frameworks!
5
6  pod 'Firebase/Analytics'
7  pod 'Firebase/Messaging'
8end

When possible, let related Firebase pods resolve together instead of pinning mismatched versions manually. Also check the iOS deployment target, because some Firebase releases require a higher minimum platform than older projects declare.

Align Plugin and Pod Versions

If your project uses wrappers such as Flutter, React Native, or a third-party SDK, the conflict may not be in your visible Podfile at all. The wrapper can pin a Firebase version range underneath.

In that case, the real fix is often:

• upgrade the wrapper package so it supports newer Firebase pods
• or downgrade your direct Firebase version pins to the compatible range

What you should avoid is forcing one pod to an arbitrary version without checking the dependency tree. That can move the error instead of solving it.

Reset Pod State If the Lockfile Is Stale

If the Podfile is already aligned but CocoaPods still insists on an impossible version, clear stale resolution state:

rm Podfile.lock
rm -rf Pods
pod install --repo-update

This forces CocoaPods to resolve dependencies again from scratch. It is not the first fix to try, but it is reasonable when the lockfile preserves an older incompatible graph. In shared projects, commit the new lockfile only after the dependency graph resolves intentionally.

Common Pitfalls

The biggest mistake is focusing on Firebase/CoreOnly as if it were the real top-level dependency you chose. It is usually only the conflict surface, not the actual design choice that caused the mismatch.

Another issue is mixing explicit Firebase version pins with third-party packages that already manage Firebase versions. That often creates contradictory constraints.

Developers also sometimes skip pod repo update, which means CocoaPods is trying to solve the graph using stale local metadata.

Finally, avoid editing the Podfile randomly until the error disappears. Read the dependency ranges in the error output and make version alignment intentional.

Summary

• The Firebase/CoreOnly error usually points to conflicting Firebase version requirements.
• Update CocoaPods specs first with pod install --repo-update.
• Align your direct Firebase pods and any wrapper package versions.
• Remove stale Podfile.lock and Pods/ only when a fresh resolution is needed.
• Treat Firebase/CoreOnly as a symptom of version mismatch, not usually the root dependency choice.