State Management in Flutter: Provider vs Riverpod vs Bloc

There's No Single "Right" Answer — Only the Right Fit for Your Team

Flutter deliberately doesn't ship an opinionated state management solution, which is both its biggest strength and its most-asked question. Here's an honest comparison of the three most common choices.

Provider — the pragmatic default

ChangeNotifierProvider(
  create: (_) => CartModel(),
  child: const MyApp(),
);

// Consuming:
final cart = context.watch();

Pros: Minimal boilerplate, easy to teach, officially recommended by the Flutter team for a long time. Cons: Relies on ChangeNotifier and manual notifyListeners() calls, which gets messy in larger apps, and testing requires more setup than the newer alternatives.

Riverpod — Provider's stricter, safer successor

final cartProvider = StateNotifierProvider(
  (ref) => CartNotifier(),
);

// Consuming:
final cart = ref.watch(cartProvider);

Pros: Compile-time safety (no more "Provider not found" runtime crashes), doesn't need BuildContext to read state, excellent testability since providers are just objects you can override in tests. Cons: Steeper learning curve, more concepts to learn upfront (providers, notifiers, families, autoDispose).

Bloc — the most structured, most opinionated

class CounterCubit extends Cubit {
  CounterCubit() : super(0);
  void increment() => emit(state + 1);
}

// Consuming:
BlocBuilder(
  builder: (context, count) => Text('$count'),
);

Pros: Enforces a strict unidirectional data flow (events in, states out), which scales very well on large teams where consistency matters more than speed of iteration. Excellent for apps with complex, auditable state transitions (fintech, anything with a compliance requirement). Cons: The most boilerplate of the three; overkill for small apps or prototypes.

Choosing between them

If you're coming from a Compose/MVVM background, Riverpod's ref.watch model will feel the most familiar — it mirrors StateFlow collection reasonably closely. Bloc will feel more like a formalized Redux, which some backend-minded engineers actually prefer for its explicitness.