Why Does Navigator.pushAndRemoveUntil Fail in initState with FirebaseAuth authStateChanges?

Below is one common solution: instead of pushing a new route inside initState (which can lead to problems because the MaterialApp already “owns” its navigation), restructure your app to choose which screen to show based on the auth status. For example, wrap your home widget in a widget that listens to auth changes and then returns the correct child. This “AuthWrapper” pattern avoids trying to navigate imperatively during widget initialization. Here’s how you can refactor your code:

DARTCopied
import 'package:app/authentication/email_auth.dart';
import 'package:app/authentication/landing.dart';
import 'package:app/authentication/signup.dart';
import 'package:app/authentication/login.dart';
import 'package:app/home_screen.dart';
import 'package:flutter/material.dart';
import 'package:flutter/services.dart';
import 'package:google_fonts/google_fonts.dart';
import 'package:firebase_core/firebase_core.dart';
import 'package:firebase_auth/firebase_auth.dart';
import 'firebase_options.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Firebase.initializeApp(
    options: DefaultFirebaseOptions.currentPlatform,
  );
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    SystemChrome.setSystemUIOverlayStyle(SystemUiOverlayStyle(
        statusBarIconBrightness: ThemeMode.system == ThemeMode.light
            ? Brightness.dark
            : Brightness.light));
    return MaterialApp(
      title: 'MyApp',
      routes: {
        Login.routeName: (context) => const Login(),
        Signup.routeName: (context) => const Signup(),
        EmailAuth.routeName: (context) => const EmailAuth(),
        Landing.routeName: (context) => const Landing(),
        HomeScreen.routeName: (context) => HomeScreen(),
      },
      // Instead of a fixed home widget, use an auth wrapper.
      home: const AuthWrapper(),
      themeMode: ThemeMode.dark,
      theme: ThemeData(scaffoldBackgroundColor: const Color(0xff222531)),
      darkTheme: ThemeData(
        scaffoldBackgroundColor: const Color(0xff222531),
        bottomAppBarTheme: const BottomAppBarTheme(color: Colors.red),
        useMaterial3: true,
        textTheme: TextTheme(
          labelMedium: GoogleFonts.inter(
              color: Colors.white, fontWeight: FontWeight.bold, fontSize: 20),
          labelSmall: GoogleFonts.inter(
              color: Colors.white, fontWeight: FontWeight.bold, fontSize: 13),
          bodyLarge: GoogleFonts.inter(
              color: Colors.white, fontWeight: FontWeight.w500, fontSize: 24),
          headlineSmall: GoogleFonts.inter(
              color: Colors.white, fontWeight: FontWeight.w400, fontSize: 22),
          displayMedium: GoogleFonts.montserrat(
              color: Colors.white, fontWeight: FontWeight.bold, fontSize: 40),
          headlineLarge: GoogleFonts.inter(
              color: Colors.white, fontWeight: FontWeight.w400),
        ),
      ),
    );
  }
}

class AuthWrapper extends StatelessWidget {
  const AuthWrapper({super.key});

  @override
  Widget build(BuildContext context) {
    // Listen to auth state changes. The builder will be called whenever the auth state updates.
    return StreamBuilder<User?>(
      stream: FirebaseAuth.instance.authStateChanges(),
      builder: (context, snapshot) {
        // If the snapshot has data, it means the user is signed in.
        if (snapshot.hasData && snapshot.data != null) {
          return HomeScreen();
        } else {
          return const Landing();
        }
      },
    );
  }
}

Explanation

• AuthWrapper Widget
  Instead of trying to navigate imperatively in initState, the AuthWrapper widget uses a StreamBuilder to watch the auth state. When a user signs in (or out), the builder rebuilds and instantly shows the appropriate screen (e.g., HomeScreen for signed in users or Landing for non-authenticated users).

• Benefits

  • No need to deal with context issues during initState.
  • The widget tree itself responds to auth state changes.
  • Navigation no longer depends on post-frame calls or delays.

Additional Tips

• If you must perform a navigation call (for example, if your app flow requires side effects), consider using a GlobalKey for your Navigator. For instance:

  DARTCopied
  final GlobalKey<NavigatorState> navigatorKey = GlobalKey<NavigatorState>();

  Then, pass it to your MaterialApp via the navigatorKey property and call:

  DARTCopied
  navigatorKey.currentState?.pushAndRemoveUntil(
      MaterialPageRoute(builder: (context) => HomeScreen()),
      (route) => false,
  );

• Always ensure that your navigation calls are made when the context is guaranteed to be mounted. The wrapper pattern is often a cleaner approach because it removes the timing issues.

Switching to one of these methods should resolve your issue with navigation not occurring, ensuring the UI reflects the authentication state.