State management is the most debated technical decision inside a Flutter project. Ask five experienced Flutter developers which approach they use and you will get five different answers, each with genuine reasoning behind it. The debate exists because the decision is real: the wrong state management choice for your team and application complexity will cost you in maintainability, testability, and developer velocity.

This article covers the two state management approaches that are worth serious consideration for production Flutter applications, Bloc and Riverpod, explains how each works architecturally, shows real code for both, and gives you a clear decision framework based on your project and team. Both packages are documented in detail at bloclibrary.dev and riverpod.dev.

This article is part of our Complete Guide to Flutter App Development. State management sits inside the presentation layer of a well-structured Flutter project; if you have not yet made your architecture decision, read our Flutter Clean Architecture guide first. How you manage state also has direct implications for how you write tests, our Flutter testing guide covers how to test Blocs and Riverpod providers in isolation.

Ready to build? Our Flutter development team is available for a free consultation.

Diagram: Bloc routes every UI update through a named event; Riverpod lets widgets read providers directly.

What Is State Management in Flutter and Why Does It Matter

A Flutter application is a tree of widgets. When data changes, a user logs in, a list loads, a form field updates, the UI needs to reflect that change. The question state management answers is: where does that data live, and how does a change in that data trigger the right widgets to rebuild?

Flutter's built-in answer is setState(). When state is local to a single widget and does not need to be shared with anything else, setState() is the correct tool. Tap a checkbox, toggle a switch, expand a list tile, setState() is appropriate for all of these.

But real applications have state that crosses widget boundaries. An authenticated user's identity needs to be accessible in the navigation layer, the home screen, the profile screen, and the settings screen simultaneously. A shopping cart total needs to be visible in the app bar and the checkout screen at the same time. An active network request's loading status needs to prevent a button from being tapped on one screen while another screen is being prepared.

Passing this state through constructor parameters, a pattern called prop drilling, breaks down immediately in any non-trivial application. The widget three levels above the one that needs the data has to accept and pass the data even though it has no use for it. Every layer in between becomes a coupling point.

State management provides a structured way to hold state outside of widgets and make it available anywhere in the widget tree without prop drilling, while controlling exactly which widgets rebuild when specific pieces of state change.

The Flutter State Management Options

Flutter has more state management options than nearly any other framework. The options that appear most frequently in the ecosystem include:

setState, built in, appropriate for local widget state, not suitable for shared or complex state.

Provider, a dependency injection and state management package that was once the Flutter team's recommended approach for most use cases. Still widely used but has been largely superseded by Riverpod, which was built by the same author to address Provider's limitations.

Riverpod, a complete rewrite of Provider that addresses its core limitations. Does not require BuildContext to access state. Supports code generation. Actively maintained and increasingly the default choice for mid-size production applications.

Bloc, a stream-based event/state pattern that provides strict separation between UI and business logic. Mature, well-documented, and the choice of many large enterprise Flutter teams.

GetX, a package that combines state management, dependency injection, and navigation in a single solution. Popular for its low boilerplate but controversial for its opinionated coupling of concerns and its deviation from Flutter's widget composition model.

MobX, a reactive state management approach ported from the JavaScript ecosystem. Less common in Flutter production codebases than Bloc or Riverpod.

For production applications, particularly those that need to be maintained, scaled, and tested over time, only Bloc and Riverpod are worth serious evaluation. The rest of this article focuses exclusively on Bloc and Riverpod.

Bloc, How It Works and When to Use It

The Core Concept

Bloc stands for Business Logic Component. It is a pattern, and a package, built around the idea that every state change in an application should be the result of an explicit, named event. The UI dispatches events. The Bloc processes events and emits states. The UI observes states and rebuilds.

The flow is strictly unidirectional:

UI dispatches Event ? Bloc processes Event ? Bloc emits State ? UI rebuilds

There is no way for the UI to directly manipulate the Bloc's internal state. It can only dispatch an event and wait for a state to be emitted. This strictness is deliberate, it is what makes Bloc applications predictable and auditable.

Bloc vs Cubit

The flutter_bloc package provides two options: Bloc and Cubit.

Cubit is a simplified version of Bloc. Instead of events, the Cubit exposes methods that the UI calls directly. The Cubit emits states in response to those method calls. Cubit has less boilerplate and is appropriate for simpler state scenarios.

Bloc uses the full event/state model. Every state transition is triggered by a named event class. This is more verbose but produces a complete, auditable record of everything that happened in the application, which is valuable for debugging, logging, and compliance in complex applications.

For most features, Cubit is sufficient. For complex business logic with multiple event types and conditional state transitions, full Bloc is the right choice.

Bloc in Code, A Complete Example

Define the events:

// presentation/blocs/auth/auth_event.dart
abstract class AuthEvent {}

class LoginRequested extends AuthEvent {
  final String email;
  final String password;
  LoginRequested({required this.email, required this.password});
}

class LogoutRequested extends AuthEvent {}

Define the states:

// presentation/blocs/auth/auth_state.dart
abstract class AuthState {}

class AuthInitial extends AuthState {}
class AuthLoading extends AuthState {}

class AuthAuthenticated extends AuthState {
  final User user;
  AuthAuthenticated({required this.user});
}

class AuthUnauthenticated extends AuthState {}

class AuthError extends AuthState {
  final String message;
  AuthError({required this.message});
}

Implement the Bloc:

// presentation/blocs/auth/auth_bloc.dart
import 'package:flutter_bloc/flutter_bloc.dart';
import '../../../domain/usecases/login_usecase.dart';

class AuthBloc extends Bloc<AuthEvent, AuthState> {
  final LoginUseCase loginUseCase;

  AuthBloc({required this.loginUseCase}) : super(AuthInitial()) {
    on<LoginRequested>(_onLoginRequested);
    on<LogoutRequested>(_onLogoutRequested);
  }

  Future<void> _onLoginRequested(
    LoginRequested event,
    Emitter<AuthState> emit,
  ) async {
    emit(AuthLoading());
    final result = await loginUseCase(
      email: event.email,
      password: event.password,
    );
    result.fold(
      (failure) => emit(AuthError(message: failure.message)),
      (user) => emit(AuthAuthenticated(user: user)),
    );
  }

  Future<void> _onLogoutRequested(
    LogoutRequested event,
    Emitter<AuthState> emit,
  ) async {
    emit(AuthUnauthenticated());
  }
}

Use it in the UI:

// In the widget
BlocBuilder<AuthBloc, AuthState>(
  builder: (context, state) {
    if (state is AuthLoading) return const CircularProgressIndicator();
    if (state is AuthAuthenticated) return HomeScreen(user: state.user);
    if (state is AuthError) return ErrorWidget(message: state.message);
    return const LoginScreen();
  },
)

// Dispatch an event
context.read<AuthBloc>().add(LoginRequested(
  email: emailController.text,
  password: passwordController.text,
));

What Bloc Does Well

Complete auditability. Every state transition in a Bloc application is the result of a named event. You can log every event and every state. You can replay a user's session to reproduce a bug. In regulated industries, fintech, healthcare, enterprise software with audit requirements, this is not a nice-to-have, it is a compliance feature.

Strict separation of concerns. The UI cannot mutate state directly. It can only dispatch events. Business logic cannot leak into widgets because widgets have no mechanism to perform business logic, they can only communicate through the event dispatch interface.

Excellent testability. The bloc_test package provides a purpose-built testing API for Bloc and Cubit:

blocTest<AuthBloc, AuthState>(
  'emits AuthLoading then AuthAuthenticated on successful login',
  build: () => AuthBloc(loginUseCase: mockLoginUseCase),
  setUp: () => when(() => mockLoginUseCase(
    email: 'test@example.com',
    password: 'password',
  )).thenAnswer((_) async => Right(tUser)),
  act: (bloc) => bloc.add(LoginRequested(
    email: 'test@example.com',
    password: 'password',
  )),
  expect: () => [AuthLoading(), AuthAuthenticated(user: tUser)],
);

The test reads exactly like the requirement: given a successful login use case, expect loading then authenticated.

Riverpod, How It Works and When to Use It

The Core Concept

Riverpod is a reactive state management library built by Remi Rousselet, the same developer who created Provider. Riverpod was built specifically to address Provider's limitations, the most significant of which is Provider's dependency on BuildContext to access state.

In Riverpod, state lives in providers, objects defined at the top level of a file, outside any widget, that hold and expose state. Any widget or class that needs that state can read from it without needing a BuildContext, without traversing the widget tree, and without caring about where in the tree it is called from.

Riverpod 2.0 introduced code generation through the @riverpod annotation, which significantly reduces the boilerplate required to define providers and has become the recommended approach for new projects.

Providers and Notifiers

Riverpod has several provider types. For state management specifically, the two most relevant are:

NotifierProvider, for synchronous state that the notifier manages and exposes to the UI.

AsyncNotifierProvider, for asynchronous state, such as data loaded from a network or database.

Example, an async notifier for user profile state:

// presentation/providers/profile_provider.dart
import 'package:riverpod_annotation/riverpod_annotation.dart';
import '../../domain/entities/user.dart';
import '../../domain/usecases/get_user_usecase.dart';

part 'profile_provider.g.dart';

@riverpod
class ProfileNotifier extends _$ProfileNotifier {
  @override
  Future<User> build(String userId) async {
    final getUserUseCase = ref.watch(getUserUseCaseProvider);
    return await getUserUseCase(userId);
  }

  Future<void> refresh(String userId) async {
    state = const AsyncValue.loading();
    state = await AsyncValue.guard(
      () => ref.read(getUserUseCaseProvider)(userId),
    );
  }
}

Use it in the UI:

// In the widget, no BuildContext juggling, no InheritedWidget traversal
class ProfileScreen extends ConsumerWidget {
  final String userId;
  const ProfileScreen({required this.userId, super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final profileAsync = ref.watch(profileNotifierProvider(userId));

    return profileAsync.when(
      loading: () => const CircularProgressIndicator(),
      error: (error, _) => ErrorWidget(message: error.toString()),
      data: (user) => ProfileContent(user: user),
    );
  }
}

What Riverpod Does Well

No BuildContext dependency in business logic. This is the most practically impactful improvement over Provider. In Provider-based code, accessing a provider from outside a widget build method requires storing a reference to a BuildContext or using a workaround. In Riverpod, providers can be read from anywhere using ref, no context required.

Composable providers. Riverpod providers can depend on other providers using ref.watch(). A cartTotalProvider can watch a cartItemsProvider and recompute automatically when the cart changes. A userSettingsProvider can depend on an authProvider and invalidate itself when the user logs out. This composability scales naturally as application complexity increases.

AsyncValue for loading and error states. Riverpod's AsyncValue type is a sealed union that represents one of three states, loading, error, or data, with a clean .when() API. Handling all three states in the UI is one expression, not a series of if checks on separate boolean flags.

Simpler dependency injection. Riverpod providers are also dependency injection containers. You do not need get_it or injectable separately, providers can be overridden in tests to inject mock dependencies:

// In tests, override any provider with a mock implementation
ProviderContainer(
  overrides: [
    getUserUseCaseProvider.overrideWithValue(mockGetUserUseCase),
  ],
);

Lower boilerplate with code generation. The @riverpod annotation and build_runner generate the provider class boilerplate automatically. You write the logic; the tool generates the registration.

Bloc vs Riverpod, Direct Comparison

Which Should You Choose, The Decision Framework

Choose Bloc when:

Your application has complex, branching business logic where the sequence of state transitions matters and needs to be auditable. Fintech applications where every action must be logged, healthcare applications with compliance requirements, and enterprise applications with multi-step workflows are all strong Bloc fits.

Your team is large, five or more Flutter developers working on shared features. Bloc's strict event dispatch model prevents accidental state mutation from any direction, which reduces the surface area for cross-team bugs.

You value predictability over flexibility. Bloc's stricter structure means there is only one way to do most things. On a large team, that consistency is worth the extra boilerplate.

Choose Riverpod when:

Your team is small, two to four developers, and iteration speed matters more than strict auditability. Riverpod's lower boilerplate and built-in dependency injection get features shipped faster.

Your application has moderate complexity with clear data flows but without strict compliance or auditability requirements. Consumer applications, productivity tools, e-commerce, and content applications all fit Riverpod well.

You are building a new project and want a modern, actively evolving approach to state management. Riverpod 2.0 with code generation is the direction the Flutter community is moving, and its composability model scales well as features are added.

Avoid choosing based on:

Popularity alone, both are popular. Framework version, both are actively maintained. What you used in your last project, the right answer depends on your current team and application, not your previous one.

A Note on Mixing Both

Some teams use Bloc for complex, high-stakes features, authentication, payments, multi-step onboarding, and Riverpod for simpler features like theme preferences, UI toggle state, and cached reference data. This is a valid approach but introduces cognitive overhead. If you choose to mix, establish a clear written rule for when each is used, and ensure every developer on the team understands it.

Next Steps

State management is one of the decisions that shapes every feature you will build from here. If you have chosen Bloc, the next step is understanding how to structure your Blocs within a Clean Architecture codebase. If you have chosen Riverpod, the next step is understanding how providers compose with your use cases and repositories.

Both paths lead to the same place: a Flutter application where business logic is tested, UI state is predictable, and features can be added without breaking what already exists.

Continue with our Flutter Clean Architecture guide to see how state management fits into the larger structural picture, or our Flutter testing guide to learn how to test Blocs and Riverpod providers in isolation.