FirebaseUI split its iOS install in two: SwiftPM for auth, CocoaPods for lists

What the library actually is: bindings, not a Firebase client

FirebaseUI is described as a library for connecting common UI elements to Firebase for data storage, so views update in realtime as data changes, with simple interfaces for displaying lists or collections of items.

The scope is deliberately narrow. It does not replace the Firebase SDKs themselves; it sits on top of them and handles the repetitive part, wiring a table view or collection view to a query and updating it as results arrive. What it is not is a general purpose UI component library, a state management solution, or a backend.

The second half is SwiftUI authentication, described separately as modern SwiftUI components that simplify Firebase authentication by integrating with common identity providers.

There is a separate FirebaseUI project for Android and one for web, so the three platforms share a name and a purpose rather than an implementation.

The repository is Apache-2.0 licensed, so there is no licensing obstacle to using it in a commercial app.

Seven SwiftPM modules, and CocoaPods only for three

The install instructions are where this library is currently awkward, and the reason is stated directly.

For SwiftUI authentication and modern features, Swift Package Manager is recommended. You add the repository URL in Xcode and select the modules you need:

https://github.com/firebase/FirebaseUI-iOS

The modules are FirebaseAuthSwiftUI for core authentication, then FirebaseGoogleSwiftUI, FirebaseFacebookSwiftUI, FirebasePhoneAuthSwiftUI, FirebaseAppleSwiftUI, FirebaseTwitterSwiftUI, and FirebaseOAuthSwiftUI for generic OAuth providers.

For UIKit data binding features, the instructions point at CocoaPods, with subspecs per product:

pod 'FirebaseUI/Firestore'
pod 'FirebaseUI/Database'
pod 'FirebaseUI/Storage'

That split is the single most important operational fact in this repository. A modern SwiftUI app that wants provider login and a Firestore list has to bring in both dependency managers, and the two do not share a resolution mechanism. Anyone who has managed that combination in a large app knows it is a real cost rather than a formality.

The subspec approach also means you pull in only the data binding you use, which is a genuine advantage of CocoaPods for a project that needs Storage but not Firestore.

iOS 17 and Xcode 15, and a Podfile snippet that says 13.0

The README states FirebaseUI supports iOS 17.0 or later and Xcode 15 or later. That is a modern floor and rules out a lot of existing projects without changes.

There is an inconsistency worth noting rather than glossing over. The CocoaPods section says that if you include FirebaseUI in a project, make sure you also have:

platform :ios, '13.0'
use_frameworks!

The stated support level is 17.0 and the Podfile guidance says 13.0. Either the snippet is stale or the deployment target is the minimum the podspec accepts while the maintained surface is iOS 17. Nothing in the README resolves it. Set your deployment target to what your app actually needs, and expect to be building with 17.0 for anything using the current SwiftUI components.

If your project is on an older iOS floor, the honest read is that this library is no longer a candidate, and the per-component READMEs are where you would confirm.

Per-component READMEs hold everything the top level README omits

The README states plainly that the READMEs for components of FirebaseUI can be found in their respective project folders, and then lists four: SwiftUI Authentication in FirebaseSwiftUI/README.md, and the UIKit data binding components Database in FirebaseDatabaseUI/README.md, Firestore in FirebaseFirestoreUI/README.md, and Storage in FirebaseStorageUI/README.md.

The repository layout confirms those are separate podspecs and separate source directories, each with its own README, so the modules really are independent rather than one library with folders inside it. FirebaseUI.podspec and FirebaseUI.h sit at the root as the umbrella, with FirebaseDatabaseUI.podspec, FirebaseFirestoreUI.podspec and FirebaseStorageUI.podspec alongside their directories, plus Package.swift and Package.resolved for the SwiftPM side.

Other directories indicate the testing and release machinery. e2eTest/ exists, and there are shell entry points for the different concerns: test.sh, local_test.sh, swiftui-tests.sh, lint-swift.sh, format-swift.sh with .swiftformat and .clang-format at the root, and release.sh, release-swift.sh and staging.sh. A Gemfile and Gemfile.lock sit alongside, which is the CocoaPods dependency set.

There is also an okf-bundle/ directory and an .opensource/ directory, plus AGENTS.md and CLAUDE.md at the root.

Samples: one SwiftUI auth app, and Objective-C and Swift data binding apps

The local setup instructions assume you will build a sample, which is the fastest way to see what configuration is required.

For SwiftUI components you clone the repository, then cd into samples/swiftui/FirebaseSwiftUISample and open FirebaseSwiftUISample.xcodeproj. For the UIKit components you cd into FirebaseDatabaseUI, or FirebaseFirestoreUI or FirebaseStorageUI, and run pod install.

Configuration for the SwiftUI sample is four steps. Download GoogleService-Info.plist from the Firebase Console and copy it into the sample project folder. Then update URL Types in Project Settings, Info tab, Url Types, with REVERSED_CLIENT_ID taken from the plist for Google Sign-In, and fb{your-app-id} for Facebook Login. For Facebook you also update Info.plist with FacebookAppID and enable Keychain Sharing.

These are two important sample setup requirements.

The data binding samples live in samples/objc/ and samples/swift/, and they need the plist copied to samples/objc/GoogleService-Info.plist or samples/swift/GoogleService-Info.plist, then pod install. The Chat sample needs anonymous authentication enabled in the console, and the Storage sample needs Storage Security Rules configured. A dummy plist is checked in at samples/GoogleService-Info-dummy.plist, which is what you replace rather than creating from nothing.

Release cadence, contribution gate and the real cost of this dependency

The repository is not archived and the last push was on 2026-10-14. Tagged releases show a steady major-version cadence: v16.1.0 on 2026-05-20, v16.0.0 on 2025-12-02 and v15.1.0 on 2025-07-01. A 16.0.0 release in December 2025 implies breaking changes somewhere in the 15 to 16 transition, which is worth reading about before upgrading rather than discovering in your build.

Contributions require a Contributor License Agreement, individual for solo contributors and corporate for company contributions. The process is issue first, then agreement if accepted, then fork, develop and test, conform to existing style, have passing unit tests, then pull request.

The honest cost assessment: this is a convenience layer, and convenience layers age. The components that matter most to FirebaseUI, the providers themselves and the underlying SDKs, move fast. Adopting it is reasonable if your app is already deeply Firebase and you want the SwiftUI auth buttons specifically; adopting it to avoid writing view controllers is a weaker argument.

Apache-2.0 includes a patent grant, but its licensing terms still apply.

Editorial conclusion

Adopt FirebaseUI for iOS if your app is already on Firebase and you want working list views and provider login buttons rather than a bespoke UI layer, and you accept splitting your dependencies between Swift Package Manager and CocoaPods. Do not adopt it as a general purpose component library or for a backend other than Firebase. Before starting, confirm iOS 17 and Xcode 15 as acceptable floors, note that the README still shows platform :ios, '13.0' in its CocoaPods snippet which is lower than the stated support level, and follow the per-component READMEs since the top level README delegates all usage detail to them.

Frequently asked questions

Official sources

1. firebase/FirebaseUI-iOS on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases