Bloc and Riverpod solve the same problem — predictable, testable state outside the widget tree — from different angles. Neither is "wrong," but they push a codebase toward different shapes as it grows.
Bloc: explicit, ceremonial, easy to audit
Bloc's event-in, state-out model makes every state transition a named, traceable thing. For a team where multiple engineers touch the same feature, that explicitness pays for itself: you can read a bloc file and know every possible state and every event that can trigger a transition, without running the app. The cost is boilerplate — a new feature typically means an event class, a state class (often sealed with several subtypes), and the bloc itself, before you write any real logic.
class CheckoutBloc extends Bloc<CheckoutEvent, CheckoutState> {
CheckoutBloc(this._repo) : super(CheckoutInitial()) {
on<SubmitOrder>(_onSubmitOrder);
}
Future<void> _onSubmitOrder(SubmitOrder event, Emitter<CheckoutState> emit) async {
emit(CheckoutLoading());
try {
final order = await _repo.submit(event.cart);
emit(CheckoutSuccess(order));
} catch (e) {
emit(CheckoutFailure(e.toString()));
}
}
}
Riverpod: less ceremony, more compiler help
Riverpod drops the event/state class ceremony in favor of providers that compute and expose state directly, with compile-time safety that Provider (its predecessor) never had — no more runtime "no provider found" crashes. For CRUD-heavy screens and anything with a lot of derived state (a filtered list depending on three other providers, say), Riverpod's ref.watch composition is noticeably less code than the equivalent Bloc-to-Bloc listening setup.
Where each one wins
We now default to Riverpod for new projects — the boilerplate savings compound as the app grows, and riverpod_generator removes most of what's left. We still reach for Bloc on apps with complex, multi-step business workflows (insurance claims, multi-stage checkout) where the explicit event log is genuinely valuable for debugging production issues after the fact — being able to say "here is the exact sequence of events that led to this state" has saved us real support time.
Testability, honestly
Both are equally testable once set up correctly — this is less a differentiator than blog posts often claim. The real testability gap in Flutter apps is almost always in the widget layer, not the state layer, regardless of which library you pick.
The switch cost us roughly two sprints per app to migrate incrementally, feature by feature, running both libraries side by side during the transition — which is the only way we'd recommend doing it on a live production app.
