Navigation is a fundamental part of almost every Flutter application.
Even a relatively small app usually needs to move between screens such as:
Splash
Login
Register
Home
Profile
Settings
Details
Flutter provides the built-in Navigator API for managing navigation. However, as applications become larger and require deep linking, authentication redirects, nested navigation, or web URL support, manually managing routes can become increasingly complicated.
This is where GoRouter becomes useful.
A common question among Flutter developers is:
Should I use GoRouter or Flutter Navigator?
The answer depends on the size and navigation requirements of your application.
In this guide, we’ll compare GoRouter vs Navigator in Flutter, understand how both approaches work, and build practical examples for common navigation scenarios.
What Is Navigator in Flutter?
Navigator is Flutter’s built-in navigation system.
At its core, Navigator manages screens using a stack.
Imagine the following navigation:
Home
↓
Products
↓
Product Details
Internally, you can think of it as:
┌─────────────────┐
│ Product Details │
├─────────────────┤
│ Products │
├─────────────────┤
│ Home │
└─────────────────┘
When the user goes back:
Product Details
↓
Pop
↓
Products
Flutter removes the top route from the navigation stack.
Basic Navigation with Navigator
The simplest Navigator example is:
Navigator.push(
context,
MaterialPageRoute(
builder: (context) => const ProfileScreen(),
),
);
To return:
Navigator.pop(context);
The flow is:
Home
↓
Navigator.push()
↓
Profile
Profile
↓
Navigator.pop()
↓
Home
For small Flutter applications, this approach can be perfectly sufficient.
What Is Navigator 1.0?
The traditional imperative navigation API is commonly referred to as Navigator 1.0.
You tell Flutter exactly what action should happen:
Navigator.push(...);
or:
Navigator.pop(...);
Other common methods include:
Navigator.pushReplacement(...);
Navigator.pushNamed(...);
Navigator.pushAndRemoveUntil(...);
The developer directly manipulates the navigation stack.
Named Routes with Navigator
Instead of creating MaterialPageRoute everywhere, you can define named routes.
MaterialApp(
initialRoute: '/',
routes: {
'/': (context) => const HomeScreen(),
'/login': (context) => const LoginScreen(),
'/profile': (context) => const ProfileScreen(),
},
);
Then navigate using:
Navigator.pushNamed(
context,
'/profile',
);
This is cleaner than creating routes repeatedly, but larger applications can still become difficult to manage.
What Is Navigator 2.0?
Flutter later introduced a more declarative routing architecture often called Navigator 2.0.
It provides APIs such as:
Router
RouteInformationParser
RouterDelegate
Page
Navigator.pages
Navigator 2.0 makes advanced routing scenarios possible, including:
- Deep linking
- Browser URL synchronization
- Complex navigation state
- Web navigation
- Nested navigation
However, manually implementing all of this can require significant boilerplate.
This is one of the main reasons routing packages became popular.
What Is GoRouter?
GoRouter is a routing package for Flutter that provides a higher-level routing API built around Flutter’s Router/navigation system.
Instead of manually managing complex Router configuration, you can define your application routes declaratively.
A basic configuration looks like:
final router = GoRouter(
routes: [
GoRoute(
path: '/',
builder: (context, state) {
return const HomeScreen();
},
),
GoRoute(
path: '/profile',
builder: (context, state) {
return const ProfileScreen();
},
),
],
);
Then connect it to your app:
MaterialApp.router(
routerConfig: router,
);
Navigation becomes:
context.go('/profile');
or:
context.push('/profile');
This creates a centralized, URL-oriented routing system.
GoRouter vs Navigator: Quick Comparison
| Feature | Navigator | GoRouter |
|---|---|---|
| Built into Flutter | Yes | Separate package |
| Simple push/pop | Excellent | Excellent |
| Small apps | Excellent | Good |
| Declarative routing | More manual | Easier |
| Deep linking | Possible | Easier |
| Flutter Web URLs | More setup | Strong support |
| Nested navigation | Possible | Easier to organize |
| Authentication redirects | Manual | Built-in routing pattern |
| Route parameters | Manual | Convenient |
| Query parameters | Manual | Convenient |
| Bottom navigation routing | Manual | ShellRoute available |
| Boilerplate for advanced routing | Higher | Lower |
| External dependency | No | Yes |
The difference becomes more noticeable as navigation complexity grows.
Installing GoRouter
Add GoRouter to your Flutter project.
dependencies:
go_router: <compatible-version>
Then run:
flutter pub get
Import it:
import 'package:go_router/go_router.dart';
Use the current package version compatible with your Flutter SDK rather than relying on a hardcoded version from an older tutorial.
Recommended Project Structure
For a medium or large Flutter project, keep routing centralized.
lib/
│
├── core/
│ ├── routes/
│ │ ├── app_router.dart
│ │ ├── app_routes.dart
│ │ └── route_guards.dart
│ │
│ ├── utils/
│ │ └── app_utils.dart
│ │
│ └── services/
│ └── auth_service.dart
│
├── features/
│ ├── auth/
│ │ ├── controllers/
│ │ ├── screens/
│ │ │ ├── login_screen.dart
│ │ │ └── register_screen.dart
│ │ └── widgets/
│ │
│ ├── home/
│ │ ├── controllers/
│ │ ├── screens/
│ │ │ └── home_screen.dart
│ │ └── widgets/
│ │
│ └── profile/
│ ├── controllers/
│ ├── screens/
│ │ └── profile_screen.dart
│ └── widgets/
│
└── main.dart
Feature screens remain inside their respective modules while global routing configuration stays in core/routes.
Creating Route Constants
Avoid scattering route strings throughout your application.
Instead of repeatedly writing:
context.go('/profile');
create constants.
class AppRoutes {
static const home = '/';
static const login = '/login';
static const register = '/register';
static const profile = '/profile';
static const settings = '/settings';
}
Then:
context.go(AppRoutes.profile);
This reduces typo-related routing bugs.
Basic GoRouter Configuration
Create:
lib/core/routes/app_router.dart
Then:
final GoRouter appRouter = GoRouter(
initialLocation: '/',
routes: [
GoRoute(
path: '/',
builder: (context, state) {
return const HomeScreen();
},
),
GoRoute(
path: '/login',
builder: (context, state) {
return const LoginScreen();
},
),
GoRoute(
path: '/profile',
builder: (context, state) {
return const ProfileScreen();
},
),
],
);
Configure Flutter:
MaterialApp.router(
debugShowCheckedModeBanner: false,
routerConfig: appRouter,
);
Your routing system is now centralized.
context.go() vs context.push()
This is one of the most important GoRouter concepts.
Consider:
context.go('/profile');
and:
context.push('/profile');
They are not always interchangeable.
go()
go() navigates to a location according to the router’s route hierarchy.
context.go('/home');
It is commonly useful when changing the current app location, such as:
Login → Home
Splash → Login
Splash → Home
push()
push() adds another route/page on top of the current navigation history.
context.push('/product/42');
This is useful for flows such as:
Products
↓
Product Details
where the user should naturally return to the previous page.
Practical go() vs push() Example
Suppose the user logs in.
You probably do not want:
Login
↓
Home
↓
Back
↓
Login
Instead:
context.go('/home');
can represent the new application location.
For product details:
context.push('/products/42');
Then:
context.pop();
returns to the product list.
A useful mental model is:
go()
→ change location
push()
→ add another page to navigation history
Actual behavior can also depend on your route hierarchy and shell configuration.
Passing Path Parameters
Suppose you have:
/products/42
where:
42
is the product ID.
Define:
GoRoute(
path: '/products/:id',
builder: (context, state) {
final id =
state.pathParameters['id'];
return ProductDetailsScreen(
productId: id!,
);
},
);
Navigate:
context.push('/products/42');
The screen receives:
productId = 42
This approach maps naturally to URLs.
Query Parameters
Suppose your URL is:
/products?category=shoes&page=2
Read parameters using:
final category =
state.uri.queryParameters['category'];
final page =
state.uri.queryParameters['page'];
This is particularly useful for:
- Filters
- Search
- Pagination
- Referral codes
- Sort options
- Web URLs
Passing Objects with extra
Sometimes you already have an object and do not want to fetch it again immediately.
For example:
context.push(
'/product-details',
extra: product,
);
Then:
GoRoute(
path: '/product-details',
builder: (context, state) {
final product =
state.extra as ProductEntity;
return ProductDetailsScreen(
product: product,
);
},
);
This is convenient for in-app navigation.
However, do not make essential deep-linked routes depend exclusively on an in-memory extra object.
A URL such as:
/products/42
can be opened independently.
An object passed through extra may not exist when someone opens the URL directly.
For deep-linkable screens, route IDs are often safer.
Navigator Arguments
With traditional Navigator navigation, you can pass data directly through constructors:
Navigator.push(
context,
MaterialPageRoute(
builder: (_) {
return ProductDetailsScreen(
product: product,
);
},
),
);
This is simple and type-friendly for straightforward application navigation.
Named-route arguments are also possible:
Navigator.pushNamed(
context,
'/product',
arguments: product,
);
Then the receiving route needs to extract those arguments correctly.
Returning Data from Navigator
Navigator makes returning values straightforward.
For example:
final result =
await Navigator.push<bool>(
context,
MaterialPageRoute(
builder: (_) =>
const EditProfileScreen(),
),
);
Then:
Navigator.pop(
context,
true,
);
The previous screen receives:
result == true
This is useful for dialogs, selection screens, editing screens, and similar workflows.
Returning Data with GoRouter
GoRouter also supports push-style navigation that can return values.
For example:
final updated =
await context.push<bool>(
'/edit-profile',
);
Then:
context.pop(true);
This means adopting GoRouter does not require giving up normal push/pop result flows.
Deep Linking
Deep linking means opening a specific application screen directly from a URL.
For example:
https://example.com/products/42
should open:
Product Details
Product ID = 42
This becomes important for:
- Email links
- Push notifications
- Marketing campaigns
- Password reset links
- Product sharing
- Referral links
- Flutter Web
GoRouter is especially useful when routes need to correspond naturally to URLs.
Deep Linking with Navigator
Deep linking is possible using Flutter’s routing APIs.
However, once your app requires:
URL parsing
Nested routes
Authentication
Route restoration
Browser navigation
Redirects
manual routing code can become more complex.
This does not mean Navigator cannot handle these requirements.
GoRouter mainly provides a more convenient abstraction around them.
Flutter Web Navigation
Navigation requirements become more important on Flutter Web.
Users expect URLs such as:
/
/products
/products/42
/profile
They may also expect:
Browser Back
Browser Forward
Direct URL opening
Bookmarking
URL sharing
GoRouter’s URL-oriented route configuration makes these scenarios easier to organize than an application built entirely around imperative Navigator.push() calls.
Authentication Redirects
One of GoRouter’s strongest features is declarative redirect logic.
Suppose:
Logged Out
↓
User opens /profile
↓
Redirect /login
A simplified configuration might look like:
final router = GoRouter(
redirect: (context, state) {
final loggedIn =
authService.isLoggedIn;
final loggingIn =
state.matchedLocation == '/login';
if (!loggedIn && !loggingIn) {
return '/login';
}
if (loggedIn && loggingIn) {
return '/home';
}
return null;
},
routes: [
// Routes
],
);
Now authentication rules are centralized.
Authentication with Navigator
With Navigator, developers often handle authentication manually:
if (isLoggedIn) {
Navigator.pushReplacement(
context,
MaterialPageRoute(
builder: (_) =>
const HomeScreen(),
),
);
} else {
Navigator.pushReplacement(
context,
MaterialPageRoute(
builder: (_) =>
const LoginScreen(),
),
);
}
This works.
However, if protected-route checks appear throughout many screens, navigation logic becomes fragmented.
A centralized routing system can be easier to maintain.
Avoid Checking Authentication on Every Screen
Avoid patterns like:
@override
void initState() {
if (!isLoggedIn) {
navigateToLogin();
}
super.initState();
}
across:
ProfileScreen
OrderScreen
SettingsScreen
WishlistScreen
DashboardScreen
Authentication access rules belong at the routing or application-state level rather than being duplicated across protected screens.
GoRouter Redirect After Login
Suppose the user attempts to open:
/orders
while logged out.
A polished flow is:
/orders
↓
Login
↓
Successful Login
↓
/orders
instead of always redirecting to:
/home
You can preserve the intended destination and navigate there after authentication.
This becomes particularly useful with:
- Deep links
- Email links
- Push notifications
- Protected web URLs
Nested Routes
Applications often contain hierarchical routes.
For example:
/products
/products/42
/products/42/reviews
GoRouter can represent that hierarchy:
GoRoute(
path: '/products',
builder: (context, state) {
return const ProductScreen();
},
routes: [
GoRoute(
path: ':id',
builder: (context, state) {
final id =
state.pathParameters['id']!;
return ProductDetailsScreen(
productId: id,
);
},
),
],
);
This makes route relationships easier to understand.
Bottom Navigation
Consider an app with:
Home
Search
Orders
Profile
Each tab may need to preserve its own navigation history.
For example:
Home
↓
Product
↓
Product Details
Then the user switches to Profile and later returns to Home.
Ideally, the Home navigation stack remains intact.
This is where nested navigation becomes important.
GoRouter ShellRoute
GoRouter provides ShellRoute for interfaces where a persistent UI surrounds child routes.
For example:
ShellRoute(
builder: (
context,
state,
child,
) {
return MainScreen(
child: child,
);
},
routes: [
GoRoute(
path: '/home',
builder: (_, __) =>
const HomeScreen(),
),
GoRoute(
path: '/search',
builder: (_, __) =>
const SearchScreen(),
),
GoRoute(
path: '/profile',
builder: (_, __) =>
const ProfileScreen(),
),
],
);
MainScreen can contain your:
AppBar
BottomNavigationBar
NavigationRail
Drawer
while the routed child changes.
StatefulShellRoute
For more advanced tab navigation, GoRouter also provides stateful shell routing patterns that can maintain separate navigation branches.
Conceptually:
Bottom Navigation
│
├── Home Navigator
│ ├── Home
│ └── Product Details
│
├── Search Navigator
│ ├── Search
│ └── Results
│
└── Profile Navigator
├── Profile
└── Settings
Each branch can maintain its own navigation stack.
This is especially useful for larger mobile applications.
Nested Navigator Without GoRouter
Flutter Navigator can also implement nested navigation.
For example, each bottom-navigation tab can own a separate:
Navigator(
key: navigatorKey,
...
)
This provides a lot of control.
The tradeoff is that you are responsible for more of the routing structure and stack management yourself.
GoRouter does not introduce the ability to create nested navigation—it makes common nested-routing configurations easier to describe.
Navigator Gives More Direct Stack Control
Traditional Navigator APIs are excellent when you want explicit imperative control.
For example:
Navigator.pushAndRemoveUntil(
context,
MaterialPageRoute(
builder: (_) =>
const HomeScreen(),
),
(route) => false,
);
This directly manipulates the navigation stack.
For specialized flows, that direct control can be convenient.
GoRouter takes a more route/location-oriented approach.
Error Pages with GoRouter
You can define routing error handling centrally.
For example:
GoRouter(
routes: [
// Routes
],
errorBuilder: (
context,
state,
) {
return const NotFoundScreen();
},
);
This is particularly useful for web and deep-link scenarios.
For example:
/products/999999
or an unknown route can be handled through a consistent error experience.
Route Names in GoRouter
Routes can also have names.
GoRoute(
name: 'productDetails',
path: '/products/:id',
builder: (context, state) {
return ProductDetailsScreen(
productId:
state.pathParameters['id']!,
);
},
);
Navigate using:
context.pushNamed(
'productDetails',
pathParameters: {
'id': '42',
},
);
This avoids manually constructing path strings everywhere.
Named Routes vs Path-Based Navigation
Path-based:
context.push(
'/products/42',
);
Named:
context.pushNamed(
'productDetails',
pathParameters: {
'id': '42',
},
);
Named navigation can be helpful when route paths change frequently.
For example:
/products/:id
could later become:
/store/products/:id
Code using route names may require fewer changes.
Page Transitions
Navigator gives straightforward access to custom routes.
For example:
Navigator.push(
context,
PageRouteBuilder(
pageBuilder: (
context,
animation,
secondaryAnimation,
) {
return const ProfileScreen();
},
transitionsBuilder: (
context,
animation,
secondaryAnimation,
child,
) {
return FadeTransition(
opacity: animation,
child: child,
);
},
),
);
GoRouter can also define custom pages.
GoRoute(
path: '/profile',
pageBuilder: (
context,
state,
) {
return CustomTransitionPage(
key: state.pageKey,
child: const ProfileScreen(),
transitionsBuilder: (
context,
animation,
secondaryAnimation,
child,
) {
return FadeTransition(
opacity: animation,
child: child,
);
},
);
},
);
Therefore, custom transitions are possible with either approach.
GoRouter with GetX
Using GetX for state management does not mean you must use GetX routing.
A Flutter project can use:
GetX
→ State management
→ Dependency injection
GoRouter
→ Navigation
→ Deep links
→ Redirects
For example:
class AuthController extends GetxController {
final isLoggedIn = false.obs;
Future<void> login() async {
// Login API...
isLoggedIn.value = true;
}
}
GoRouter can react to authentication state through an appropriate refresh/listenable architecture.
Keeping routing separate from feature controllers can make larger applications easier to reason about.
Navigation from Controllers
Avoid tightly coupling business logic to navigation when possible.
For example:
class LoginController {
Future<void> login() async {
await repository.login();
Get.offAllNamed('/home');
}
}
mixes:
Authentication Logic
+
Navigation Logic
A cleaner pattern is:
Controller
↓
Update Authentication State
↓
Router observes state
↓
Redirect
This keeps your controller focused on application state rather than screen transitions.
Navigator Is Still Used Underneath
Using GoRouter does not mean Flutter Navigator becomes irrelevant.
GoRouter works with Flutter’s routing and navigation infrastructure.
You can still encounter:
Navigator.of(context)
for appropriate local navigation operations.
For example, dialogs commonly use:
showDialog(
context: context,
builder: (_) {
return const AlertDialog();
},
);
and:
Navigator.pop(context);
may close them.
The real comparison is not:
Navigator OR GoRouter forever
Instead, it is about which routing abstraction should manage your application’s main navigation structure.
GoRouter Advantages
GoRouter is especially useful when your application needs:
Centralized route configuration
Routes can be organized in one routing layer.
Deep linking
URLs map naturally to application screens.
Flutter Web routing
Browser URLs become easier to manage.
Authentication redirects
Protected-route behavior can be centralized.
Nested routes
Parent-child route relationships are easier to represent.
Shell routes
Useful for bottom navigation, navigation rails, and persistent layouts.
Route parameters
Dynamic URL segments are convenient.
Query parameters
Useful for search, filters, and web navigation.
Declarative navigation
The router can respond to application state instead of requiring every screen to manually perform navigation.
GoRouter Disadvantages
GoRouter is not automatically better for every project.
Potential tradeoffs include:
Additional dependency
Navigator is part of Flutter itself, while GoRouter is a separate package.
More concepts
You may need to understand:
GoRoute
GoRouterState
redirect
ShellRoute
StatefulShellRoute
go
push
named routes
route hierarchy
Unnecessary complexity for tiny apps
If your entire application contains:
Home
↓
Details
then:
Navigator.push(...)
may be simpler.
Route hierarchy matters
Incorrect route structure can cause confusing behavior with go(), push(), nested navigation, or shell routes.
Navigator Advantages
Navigator remains an excellent choice.
No additional routing package
It is built directly into Flutter.
Easy to understand
For simple navigation:
Navigator.push(...)
Navigator.pop(...)
is very clear.
Direct stack control
Imperative APIs are useful for specialized navigation flows.
Great for small apps
Small applications may not need a full routing configuration.
Excellent for local flows
Temporary or highly localized flows can be straightforward with Navigator.
Navigator Disadvantages
Problems usually appear as application complexity increases.
You may eventually need to manually manage:
Named routes
Deep links
URL state
Authentication redirects
Nested navigators
Browser navigation
Route parsing
Unknown routes
Navigation state
Flutter provides APIs capable of supporting these requirements, but implementing the architecture manually can involve more code.
Performance: GoRouter vs Navigator
For most applications, navigation performance should not be the primary reason to choose one over the other.
Both ultimately operate within Flutter’s navigation system.
Your decision should focus more on:
Architecture
Maintainability
Deep-link requirements
Web support
Nested navigation
Authentication flows
Team familiarity
Application complexity
Poor screen performance is much more likely to come from expensive widget builds, large images, heavy computations, unnecessary rebuilds, or inefficient data loading than from simply choosing GoRouter instead of imperative Navigator.
Which One Is Easier to Learn?
For beginners, Navigator 1.0 is generally easier to understand.
Start with:
Navigator.push(
context,
MaterialPageRoute(
builder: (_) =>
const DetailsScreen(),
),
);
and:
Navigator.pop(context);
This teaches the navigation-stack concept clearly.
Once your application needs more advanced routing, GoRouter becomes valuable.
Understanding Navigator first also makes GoRouter easier to understand because the underlying concepts are still related to routes, pages, and navigation stacks.
Which Should You Use for a Small Flutter App?
Consider an app with:
Splash
Login
Home
Profile
with no complex deep links or web routing.
Traditional Navigator can be enough.
For example:
Navigator.push(
context,
MaterialPageRoute(
builder: (_) =>
const ProfileScreen(),
),
);
Adding a full routing architecture may not provide much benefit.
Which Should You Use for a Large Flutter App?
Consider:
Authentication
Dashboard
Products
Product Details
Orders
Order Details
Profile
Settings
Notifications
Bottom Navigation
Deep Links
Push Notification Routes
Flutter Web
Now route management becomes a real architectural concern.
A centralized GoRouter configuration can make this application easier to maintain.
For example:
/
├── login
├── home
├── products
│ └── :productId
├── orders
│ └── :orderId
├── notifications
└── profile
└── settings
The route structure itself describes much of the application’s navigation hierarchy.
Which Should You Use for Flutter Web?
For applications where browser URLs matter significantly, GoRouter is often a convenient choice.
A web application may require:
Direct URLs
Deep linking
Browser back
Browser forward
Bookmarkable pages
Path parameters
Query parameters
Authentication redirects
404 handling
These requirements align naturally with GoRouter’s route-oriented API.
Navigator/Router APIs can still implement them manually if you need lower-level control.
Which Should You Use for Authentication?
For simple authentication flows, either approach works.
For applications with many protected routes:
/profile
/orders
/dashboard
/settings
/admin
GoRouter’s centralized redirect system can make access control easier to organize.
Instead of every screen deciding:
Am I logged in?
the routing layer can make that decision consistently.
Remember that route guards improve application flow, but they are not a security boundary. Your backend must still enforce authorization.
Common GoRouter Mistakes
Using go() everywhere
Not every navigation action should replace/change the current route hierarchy.
Use push() when users should naturally return to the previous page.
Using push() everywhere
Authentication and major top-level location changes may be better represented by go() or redirect logic.
Depending only on extra
If a page must support deep linking, make sure it can load from URL parameters.
Putting business logic inside routes
Avoid turning app_router.dart into a repository or service layer.
Huge router files
For large applications, organize route configuration by feature when necessary.
Duplicate path strings everywhere
Use route names or centralized route definitions.
Using router guards as backend security
A user should not gain access to protected server data merely because a client-side route is hidden.
Authorization belongs on the server too.
Common Navigator Mistakes
Calling Navigator everywhere
If controllers, repositories, services, and widgets all manipulate routes, navigation becomes difficult to follow.
Huge named-route switch statements
Large applications can end up with massive route-generation files.
Incorrect context
Calling:
Navigator.of(context)
with the wrong Navigator context can cause unexpected behavior in nested navigation.
Removing route history accidentally
Methods such as:
pushReplacement
pushAndRemoveUntil
should be used intentionally.
Reimplementing complex routing manually
If you find yourself building custom deep-link parsing, authentication guards, URL synchronization, and multiple nested navigation stacks, a routing abstraction may reduce complexity.
Practical Decision Guide
Use traditional Navigator when your application is relatively simple:
Few screens
Simple push/pop navigation
No complex deep links
No major web routing requirements
Minimal nested navigation
Consider GoRouter when your application has:
Many screens
Deep links
Flutter Web
Authentication redirects
Route parameters
Query parameters
Nested routes
Bottom-navigation branches
Complex navigation state
Shareable URLs
The choice should be based on application requirements rather than assuming one solution is universally superior.
GoRouter vs Navigator Architecture
Navigator-style application
UI
↓
Navigator.push()
↓
Screen
↓
Navigator.push()
↓
Another Screen
This is simple and imperative.
GoRouter-style application
Application State
↓
Router
↓
Route Configuration
↓
Navigation Hierarchy
↓
Screen
This provides a more centralized navigation architecture.
Example Production GoRouter Structure
A larger application might use:
lib/
├── core/
│ └── routes/
│ ├── app_router.dart
│ ├── app_routes.dart
│ └── route_refresh_listenable.dart
│
├── features/
│ ├── auth/
│ │ ├── screens/
│ │ └── controllers/
│ │
│ ├── home/
│ │ ├── screens/
│ │ └── controllers/
│ │
│ ├── products/
│ │ ├── screens/
│ │ ├── controllers/
│ │ ├── models/
│ │ └── widgets/
│ │
│ └── profile/
│ ├── screens/
│ ├── controllers/
│ └── widgets/
│
└── main.dart
Then the application flow can be:
main.dart
↓
AppRouter
↓
Authentication Redirect
↓
Shell / Route
↓
Feature Screen
↓
Feature Controller
Navigation stays centralized while each feature remains modular.
Final Comparison
| Requirement | Navigator | GoRouter |
|---|---|---|
| Basic screen navigation | Excellent | Excellent |
| Push/pop | Excellent | Excellent |
| Small project | Very suitable | Suitable |
| Large route hierarchy | More manual | Easier to organize |
| Deep links | Supported | Convenient |
| Web URLs | More manual configuration | Strong fit |
| Path parameters | Possible | Convenient |
| Query parameters | Possible | Convenient |
| Auth redirects | Usually manual | Centralized |
| Nested routes | Supported | Easier configuration |
| Bottom-navigation branches | Manual nested navigators | Shell routing available |
| Custom transitions | Yes | Yes |
| Return values | Yes | Yes |
| External package | No | Yes |
| Direct stack control | Excellent | Available through routing/navigation APIs |
| Declarative routing | Lower-level APIs available | Easier high-level API |
Final Thoughts
The GoRouter vs Navigator comparison is not about one being universally better.
Navigator is Flutter’s fundamental navigation system and remains excellent for straightforward push/pop flows.
For a small application:
Home
↓
Details
↓
Profile
using:
Navigator.push(...)
may be all you need.
However, when your project grows into:
Authentication
+
Deep Linking
+
Bottom Navigation
+
Nested Routes
+
Dynamic Parameters
+
Flutter Web
+
Protected Routes
a centralized routing solution becomes much more valuable.
GoRouter provides a higher-level way to organize those requirements:
GoRouter
↓
Route Configuration
↓
Authentication Redirects
↓
Nested/Shell Routes
↓
Deep Links & URLs
↓
Flutter Screens
For developers learning Flutter, understanding basic Navigator.push() and Navigator.pop() is still important because it teaches how Flutter navigation works.
For larger production applications—especially projects targeting mobile and web, using deep links, authentication redirects, or complex bottom-navigation structures—GoRouter can provide a cleaner and more maintainable routing architecture.
The right choice is therefore based on the complexity of your navigation requirements, not simply the number of screens in your Flutter project.
