FirebaseUI-Android: prebuilt auth and list adapters for Firebase apps

The boilerplate FirebaseUI-Android removes

Every Firebase Android app starts with the same chores: an email and password form, a Google sign-in button, a list that updates when the database changes. FirebaseUI-Android exists to absorb that work. The README describes it as an open-source library that lets you "quickly connect common UI elements to Firebase APIs", and the repository splits that promise into four modules: auth/, firestore/, database/ and storage/. Each module targets one Firebase product, so you take only the piece you need. The audience is Android developers already committed to Firebase who want a working sign-in screen or a bound list without writing the adapter plumbing themselves. It is not a general-purpose UI kit, and it does not abstract Firebase away; it sits on top of the SDKs rather than replacing them.

How the four modules map onto Firebase SDKs

The dependency graph in the README is explicit. firebase-ui-auth depends on com.google.firebase:firebase-auth and com.google.android.gms:play-services-auth. firebase-ui-database depends on com.google.firebase:firebase-database. firebase-ui-firestore depends on com.google.firebase:firebase-firestore. firebase-ui-storage depends on com.google.firebase:firebase-storage. The README states that each FirebaseUI library has a transitive dependency on the appropriate Firebase SDK, so you do not add those separately. That design keeps the modules independent, which is why the repository has one top-level directory per product. The practical consequence is version coupling: the Firebase SDK arrives with the UI library, and overriding it means declaring every transitive dependency yourself at the version you want. The README lists those dependencies per module, including androidx.lifecycle, androidx.browser, androidx.cardview, androidx.constraintlayout, androidx.legacy and com.google.android.material for the auth module. Miss one and Gradle resolves a mix.

Installing FirebaseUI-Android in app/build.gradle

FirebaseUI is published as a collection of libraries, and installation is a dependency block. The README gives this example for app/build.gradle, with the 10.0.0-beta05 version from the recent releases. Add only the modules you use.

dependencies {
    // FirebaseUI for Firebase Realtime Database
    implementation 'com.firebaseui:firebase-ui-database:10.0.0-beta05'

    // FirebaseUI for Cloud Firestore
    implementation 'com.firebaseui:firebase-ui-firestore:10.0.0-beta05'

    // FirebaseUI for Firebase Auth
    implementation 'com.firebaseui:firebase-ui-auth:10.0.0-beta05'

    // FirebaseUI for Cloud Storage
    implementation 'com.firebaseui:firebase-ui-storage:10.0.0-beta05'
}

After the project is synchronized, the README says you are ready to use Firebase functionality. If you include firebase-ui-auth, the README points to a separate configuration step in auth/README.md; skipping it is the usual reason a first build fails. To see the components in action rather than reading about them, the repository ships a sample app in the app/ directory that the README says demonstrates most features. It requires a Firebase project, an Android app added to that project, the generated google-services.json copied into app/, and anonymous authentication enabled in the console. The README also warns that importing via Project from Version Control leaves the project unlinked from Gradle, and recommends a manual git checkout followed by Import from external model.

The 10.x beta line and the upgrade path

The current releases are 10.0.0-beta05, 10.0.0-beta04 and 10.0.0-beta03, published between 2026-07-09 and 2026-09-10. The README's installation example itself uses 10.0.0-beta05, so the beta is the documented path, not a side channel. If that matters to your release process, note that the repository also hosts snapshot builds on oss.jfrog.org for people who want the next release early, with a repository entry in build.gradle and a dependency on com.firebaseui:firebase-ui-auth:$X.Y.Z-SNAPSHOT. Snapshots are for evaluation. For upgrades, the README links migration guides in docs/, one per major version from 1.2.0 through 9.1.1 to 10.x.x. That is a long paper trail, and it tells you something about the cost of staying current: a major version bump has historically required reading a guide, not just changing a version string.

Where FirebaseUI-Android is the wrong choice

The library owns the UI it provides. If your product needs a sign-in screen that does not look like the standard FirebaseUI flow, or a list whose recycling and diffing logic is tied to your own data layer, the component you would be customizing is the one the library controls. The README does not document per-widget theming or a supported way to swap the internal adapter for your own, so the realistic options are to accept the default presentation or to drop the module and use the Firebase SDK directly. There is a second constraint around versions. Because the Firebase SDK comes in transitively, an app pinned to a specific Firebase version has to redeclare the full dependency list shown in the README for the module it uses. That is manual work, and it is easy to leave one androidx artifact at the wrong version. Finally, the 10.x line is beta; if your policy forbids beta dependencies in production, the stable option is the 9.x line and its own migration guide.

FirebaseUI-Android versus hand-written Firebase code

The alternative is not another library; it is writing the integration yourself against the Firebase SDK. The difference in approach is ownership. FirebaseUI gives you a finished auth flow and list adapters, and you configure them. Hand-written code gives you the same Firebase APIs with no intermediate layer, so you control the layout, the state handling and the exact version of every dependency, and you also own the sign-in error cases that FirebaseUI already handles. The trade is time against control. For a standard email and Google sign-in screen, or a RecyclerView that mirrors a Firestore collection, the library removes a meaningful amount of code. For anything unusual, the library becomes the thing you work around. The repository's own structure supports this reading: separate modules per Firebase product, each documented in its own README, so you can adopt one and write the rest yourself.

Licence, maintenance and the cost of upgrading

FirebaseUI-Android is licensed under Apache-2.0, the same permissive licence family Firebase itself uses, which generally allows commercial use and modification provided the licence and notices are preserved. That is a statement about the licence text, not legal advice; check the LICENSE file and your own counsel before shipping. On maintenance, the last push to the repository was on 2026-09-22, one day before the date used for this review, and the repository is not archived. Releases are frequent enough that three betas landed between 2026-07-09 and 2026-09-10. The upgrade cost is the part to budget for. The README maintains a migration guide for every major version from 1.2.0 onward, and the 10.x line is still in beta, so a team adopting now should expect at least one more migration document to read before 10.x stabilizes. Dependabot-style version bumps will not be enough; the transitive dependency list in the README is the checklist.

Editorial conclusion

Adopt FirebaseUI-Android when your app needs a standard sign-in flow or a RecyclerView backed by Firestore, Realtime Database or Storage, and you are willing to run a 10.0.0-beta release. Do not adopt it if you need a fully custom authentication screen, since the library owns that UI and you would be fighting it. Before adding the dependency, read the upgrade guide for your current version in the docs/ directory, confirm which Firebase SDK version the artifact pulls in transitively, and check the auth/ README configuration steps if you plan to use firebase-ui-auth.

Frequently asked questions

Official sources

1. firebase/FirebaseUI-Android on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases