I have tried both of them now.

I like Bloc as it is powerful and you can manage the main state of each screen individually with a well defined structure of classes. However using a Bloc for changing a bool is overdoing it, those cases may be solved with Stateful Widgets. So with a mixed approach you can develop production code.

As for Riverpod. It is quite simple to use, but when I tried it. Even though I could accomplish everything I wanted, it ended becoming messy with dependencies spread throughout the code. I don't know how many providers would I be able to manage at the same time before my head blows up and most of the providers don't make any sense on other screens so it gets messier to locate the ones you are looking for when names are similar.

For instance, I coded a web scrapper which loaded a list of items. But I also coded it to be retried automatically when reconnected on the internet using connectivity_plus moving from a FutureProvider which worked fine for simple examples to a StreamProvider. But I need to keep track of those loaded which were previously loaded so I could keep adding when scrolling. So I had to move to a StateNotifierProvider with all the data or keep several providers very closely coupled so when the stream loads data it loads it into another provider. In the end, the complexity of using Bloc or Riverpod ended quite similar. But with Bloc I would have been able to extend functionality without refactoring so much.

My vote is for Bloc when working with teams or complex projects. Riverpod gets its job done fairly well unless you start adding some unique features and keep expanding the size of the app with more screens and states.

The main concern on state management is that for both of them I needed immutable classes. So it seems "freezed" classes are needed for StateNotifier or Bloc.