Theory
Login without building login
Adding sign-in to an app normally means designing login and registration screens, wiring up buttons, validating input, showing errors, real work. FirebaseUI Auth offers a shortcut: a complete, prebuilt sign-in flow you drop into your app.
You tell it which sign-in methods to offer, launch it, and it presents polished login screens, handles the whole process, and hands you back the result. This lesson covers this fast path. The next lesson covers the alternative, calling the Firebase SDK directly with your own UI, so you can choose the right approach for each app.
Theory
How FirebaseUI Auth works
The idea is simple. You build a configuration: a list of the providers you want to offer (email/password, Google, and so on). You launch FirebaseUI's sign-in Intent with that configuration. FirebaseUI then takes over: it shows ready-made screens, lets the user register or log in, runs each provider's flow, handles errors, and, when done, returns the result to your activity.
On success, the user is signed in to FirebaseAuth exactly as if you had done it by hand, so auth.currentUser is now set. You wrote almost no UI; FirebaseUI did the heavy lifting while still using standard Firebase Authentication underneath.
Practical
Launching the FirebaseUI sign-in flow
// Choose which sign-in methods to offer
val providers = listOf(
AuthUI.IdpConfig.EmailBuilder().build(),
AuthUI.IdpConfig.GoogleBuilder().build(),
)
// Build the prebuilt sign-in Intent and launch it
val signInIntent = AuthUI.getInstance()
.createSignInIntentBuilder()
.setAvailableProviders(providers)
.build()
signInLauncher.launch(signInIntent) // FirebaseUI shows the login screens
// The result comes back to your registered ActivityResult callback.Formula
Convenience now, less control
FirebaseUI Auth's strength is speed and correctness: you get a working, best-practice login flow (with sensible screens, validation, and error handling) in a handful of lines, and it supports multiple providers out of the box.
The trade-off is control: the screens look the way FirebaseUI makes them, and the flow is what it provides. If your app needs a fully custom login look or unusual behaviour, you will reach for the SDK directly instead (next lesson). So FirebaseUI is ideal when you want login done quickly and well, and are happy with its ready-made experience.
Quiz
What is the main benefit of using FirebaseUI Auth instead of building the login screens yourself?
- It makes the app run without any internet
- It provides a complete prebuilt sign-in flow (screens, multiple providers, error handling) with minimal code
- It removes the need for a Firebase project
- It stores passwords in plain text for you
Show the answer
It provides a complete prebuilt sign-in flow (screens, multiple providers, error handling) with minimal code
FirebaseUI Auth gives you a ready-made, best-practice sign-in flow, polished screens, support for multiple providers, and built-in handling of registration, login, and errors, so you add authentication with very little code. Option A is wrong: authentication needs the network to reach Firebase; FirebaseUI does not make it offline. Option C is wrong: you still need a Firebase project and configuration; FirebaseUI builds on Firebase Auth, it does not replace the project setup. Option D is alarming and false: Firebase never stores passwords in plain text; it handles credentials securely, and FirebaseUI uses that same secure backend. The benefit is a complete login experience with minimal effort, trading some UI control for speed.
Think first
When should you NOT use FirebaseUI, and reach for the SDK instead?
FirebaseUI is so convenient. When would a developer deliberately skip it and call the Firebase SDK directly? Then tap.
Show the answer
You skip FirebaseUI when you need full CONTROL over the login experience, its look, flow, or behaviour, that its prebuilt screens cannot give you. FirebaseUI trades control for convenience: it provides fixed, sensible screens and a standard flow, which is perfect when any clean login will do. But some apps have requirements that do not fit that mould. Maybe the design demands login screens that match a very specific brand look, with custom layouts, animations, or copy that FirebaseUI's screens cannot produce. Maybe the flow needs to be unusual, extra steps, custom validation messages, combining login with onboarding, or tight integration with the rest of a bespoke UI. Maybe you want to handle each step yourself for finer error handling or analytics. In those cases you call the Firebase Authentication SDK DIRECTLY (the next lesson): you build your own login and registration screens and invoke methods like createUserWithEmailAndPassword and signInWithEmailAndPassword yourself. That means more code and more responsibility (you design the UI, handle the states, show the errors), but complete freedom over the experience. So the decision is a familiar engineering trade-off: FirebaseUI for speed and best-practice defaults when a standard login is fine; the SDK directly when you need a custom look or flow and are willing to build the UI. Match the tool to how much control the app actually requires. Convenience by default, control when you need it.
Summary
Key takeaways
- FirebaseUI Auth is a complete, prebuilt sign-in flow you drop into your app.
- You configure it with the list of providers to offer, launch its sign-in Intent, and it shows ready-made login screens.
- It handles registration, login, provider flows, and errors, then returns the result to your activity.
- On success the user is signed in to FirebaseAuth normally (auth.currentUser is set), with almost no UI code from you.
- Benefit: a working, best-practice login fast; trade-off: less control over the exact look and flow.
- Use the Firebase SDK directly (next lesson) when you need a custom login UI or unusual flow.
- Memory hook: FirebaseUI is drop-in login, list your providers and launch, it builds the screens for you.