Firebase Apple SDK: SPM, CocoaPods and the October 2026 Cutoff
Firebase SDK for Apple App Development
At a glance
- What is it?
- The firebase-ios-sdk repository holds the open source Apple libraries behind Firebase, minus Analytics. The interesting decision is no longer which product to use, but how you install it, because CocoaPods publication stops in October 2026.
- Who is it for?
- Adopt firebase-ios-sdk if you are shipping an Apple app and want Firebase products as source you can read, with Swift Package Manager as the install path. Do not adopt it if you need FirebaseAnalytics source, which is not open source, or if you are targeting watchOS or visionOS heavily, where support is community driven and the documentation itself notes gaps.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What firebase-ios-sdk actually ships, and what it leaves out
This repository is the source for the Apple platform Firebase libraries, with one deliberate hole: FirebaseAnalytics. The README states plainly that the repository contains the source code for all Apple platform Firebase libraries except FirebaseAnalytics, and that Analytics is not open source, though its pre-compiled binaries arrive when you install Firebase through Swift Package Manager or CocoaPods. That split matters more than it first appears. If your team's compliance process requires reading every line that runs in your binary, Analytics will always be the exception you have to document separately.
The products that are here span a wide range: FirebaseAI, FirebaseAppCheck, FirebaseAppDistribution, FirebaseAuth, FirebaseFirestore, FirebaseFunctions, FirebaseMessaging, FirebaseCrashlytics, FirebaseInAppMessaging, FirebasePerformance, FirebaseDatabase, FirebaseRemoteConfig and FirebaseStorage. That is a backend surface area, not a single utility. The practical consequence is that a team rarely adopts this repository as one thing. You pull in the podspecs or package products you need, and the rest stays out of your build.
Who it is for is therefore narrower than the Firebase marketing suggests. It is for Apple platform developers who have already decided on Firebase services and now need the client libraries, either as a dependency or as readable source. If you are still choosing a backend, this repository will not help you decide.
How the repository is organised: podspecs, source directories and a CMake path
The layout is one directory per product, paired with a podspec at the top level. FirebaseAuth sits next to FirebaseAuth.podspec, FirebaseFirestore next to FirebaseFirestore.podspec, and so on down the list. There are also interop podspecs such as FirebaseAuthInterop.podspec and FirebaseAppCheckInterop.podspec, plus testing support podspecs like FirebaseFirestoreTestingSupport.podspec. That naming convention tells you something about the architecture: products are meant to be consumed independently, and the interop layers exist so one product can use another without pulling in the full dependency graph.
A few entries are worth noticing because they are not products in the same sense. CoreOnly/ and FirebaseCoreInternal.podspec suggest a minimal core that other pieces build on. Crashlytics/ appears as its own top-level directory alongside FirebaseCrashlytics.podspec. FirebaseDataConnect/ has a directory but no podspec in the visible list, which is a reminder that the top-level listing is not a complete manifest of what ships.
There is also a CMakeLists.txt and a CMAKE.md at the root. The README does not explain the CMake path in the portion available, so treat it as a build system for parts of the repository rather than a supported installation route for app developers. For an app, the documented routes are Swift Package Manager, CocoaPods, GitHub source snapshots, experimental Carthage on iOS only, and use from a framework or library.
Installing firebase-ios-sdk with Swift Package Manager
The README points to the Firebase get started documentation for Swift Package Manager instructions rather than reproducing them, and notes that where a Swift-suffixed library is available you should prefer it when writing Swift. In Xcode, the mechanics are the usual ones: add the package by URL, then select the products you need. The repository URL is the one shown in the README's GitHub install examples.
https://github.com/firebase/firebase-ios-sdk.gitAfter the package resolves, Xcode lists the individual library products. Pick only what you use. Adding every product increases build time and binary size, and the repository is structured precisely so you do not have to.
If you would rather pin a source snapshot than a released version, the README shows Podfile directives for branch and local path access. These are CocoaPods syntax, but they illustrate the two ways to point at unreleased code.
pod 'FirebaseCore', :git => 'https://github.com/firebase/firebase-ios-sdk.git', :branch => 'main'
pod 'FirebaseFirestore', :git => 'https://github.com/firebase/firebase-ios-sdk.git', :branch => 'main'The README's second example uses a checked-out copy instead of a remote branch, with :path pointing at the local repository directory. Both are documented as ways to reach other branches, tags or commits, not as recommended production setups.
The CocoaPods deprecation is the main decision point right now
The README carries a warning that new versions of the Firebase Apple SDK will no longer be published to CocoaPods after October 2026. Existing CocoaPods versions remain available and installations remain functional, and a migration guide is linked. The installation section repeats the same note.
Read that carefully, because the two halves have different consequences. Existing versions staying available means a project pinned to a CocoaPods release will not break on its own. It means the version you are on is where you stay, unless you move to another distribution channel. Security fixes and new Firebase features arriving after October 2026 will not reach a CocoaPods-only project.
For a shipping app with a long support window, that is a planning constraint, not an emergency. The migration path the README documents is Swift Package Manager, which is also the path it recommends for Swift code. The awkward case is a mixed dependency graph where some other pod forces CocoaPods to remain in the project. You can run both systems, but you then have two places to check when a Firebase version question comes up.
The repository's own release cadence shows how much you would be freezing: 12.18.0 on 2026-08-19, then 12.19.0 and 12.19.1 on 2026-09-09. Releases arrive faster than most apps ship.
Platform support is uneven, and the README says so
Firebase provides official beta support for macOS, Catalyst and tvOS. visionOS and watchOS are described as community supported, with thanks to community contributions for the multi-platform pull requests. The README also states that gaps remain, especially on visionOS and watchOS, and points to a support matrix chart in the Firebase documentation for the current picture.
This is the honest part of the documentation and worth taking at face value. Community supported is not a synonym for broken, but it does describe where fixes come from and how quickly a platform-specific issue gets attention. If your roadmap is watchOS-first, the support matrix is the first thing to check, not the product list.
There is one specific trap documented for visionOS. Firestore via Swift Package Manager requires the source distribution rather than the binary one. The README gives the workaround: quit Xcode and open the project from the command line with an environment variable set.
open --env FIREBASE_SOURCE_FIRESTORE /path/to/project.xcodeprojThat is a real constraint on a build pipeline. An environment variable set on a developer's machine does not automatically exist in CI, and the README's instruction assumes an interactive Xcode launch. Teams building visionOS with Firestore through SPM need to verify how that variable reaches their build agents.
Alternatives, and when Firebase is the wrong layer
The obvious alternative for Apple developers is CloudKit, which is Apple's own backend and requires no third-party SDK at all. The difference in approach is fundamental. CloudKit ties your data to Apple's ecosystem and to the user's iCloud account, and it does not give you an Android or web client for free. Firebase's model is the opposite: one backend, clients on every platform, and identity managed by Firebase Authentication rather than by the platform vendor. If your product is Apple-only and your users expect their data in iCloud, CloudKit removes a dependency instead of adding one. If you need the same account and the same database on iOS and Android, CloudKit is not the tool.
Within the Firebase world, the more interesting comparison is between products in this repository. Realtime Database and Cloud Firestore solve overlapping problems with different data models, and the repository ships both as separate directories and podspecs. Choosing between them is a design decision about query patterns and offline behaviour, not an installation one, and the README does not attempt to make that choice for you.
A third path is to skip the client SDK entirely and call Firebase's REST APIs directly. That removes a large dependency from your binary. It also means reimplementing token refresh, offline caching and platform integration that this repository already provides, which is rarely a good trade for an app with more than a trivial backend surface.
Licence and the cost of staying current
The repository is Apache-2.0, and the README's badge row links the licence badge to the repository's licence file. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices, which is generally straightforward for app developers to comply with. This is a description of the licence identifier, not legal advice; if you redistribute modified Firebase source, read the licence text and your own legal review process.
One licence detail is easy to miss. FirebaseAnalytics is not open source, yet its pre-compiled binaries are included when you install Firebase via Swift Package Manager or CocoaPods. So a dependency tree that looks entirely Apache-2.0 at the repository level may contain a binary under different terms. If your organisation tracks licence obligations per binary, Analytics needs its own entry.
The upgrade cost is dominated by the CocoaPods timeline rather than by the licence. Releases land frequently, as the August and September 2026 versions show, and the repository is not archived, with the last push on 2026-09-15. That is a project that moves. Being on a channel that stops receiving new versions in October 2026 means your upgrade cost is front-loaded into a migration rather than spread across routine version bumps. Doing that migration while your dependency graph is small is cheaper than doing it later.
Editorial conclusion
Adopt firebase-ios-sdk if you are shipping an Apple app and want Firebase products as source you can read, with Swift Package Manager as the install path. Do not adopt it if you need FirebaseAnalytics source, which is not open source, or if you are targeting watchOS or visionOS heavily, where support is community driven and the documentation itself notes gaps. Before you start, verify three things: that your chosen products are in the supported list in the README, that your Podfile or Package.swift does not depend on a CocoaPods release after October 2026, and, if you use Firestore on visionOS with Swift Package Manager, whether you need the FIREBASE_SOURCE_FIRESTORE source distribution.
Frequently asked questions
What is the Firebase SDK and what does it do?
It is an app development platform with libraries, services and tools for building, growing and monetising an app, according to the README. This repository contains the Apple platform source for products such as Authentication, Cloud Firestore, Cloud Messaging, Crashlytics, Realtime Database, Remote Config and Storage.
How do I add the Firebase iOS SDK in Xcode?
The README directs you to the Firebase get started documentation for Swift Package Manager, where you add the package and select the products you need. It notes that where a Swift-suffixed library is available, installing it gives the best experience when your app is written in Swift.
How do I install the Firebase iOS SDK?
The README lists Swift Package Manager, CocoaPods, installing from GitHub, experimental Carthage for iOS only, and use from a framework or library. It recommends Swift Package Manager or CocoaPods for getting the pre-compiled FirebaseAnalytics binaries, and notes that new versions will no longer be published to CocoaPods after October 2026.
What is the Firebase iOS SDK?
It is the set of Apple platform Firebase libraries whose source lives in this repository, covering products from FirebaseAuth and FirebaseFirestore to FirebaseMessaging and FirebaseCrashlytics. FirebaseAnalytics is the exception: the README states it is not open source, though its pre-compiled binaries ship with Swift Package Manager and CocoaPods installs.
Community notes