The client shows you the app prototype. Everything works, looks perfect. Then you add a button, change some data, and the UI doesn't update. Or worse, the shopping cart resets itself. Welcome to the classic Flutter problem: managing state.
If you're a team building mobile apps, you know that state management isn't a technical detail—it's the architecture everything else rests on. Get it wrong, and you get fragile code, impossible-to-reproduce bugs, and ballooning development time. We at Meteora Web see it every day in projects we're called to fix. Provider used poorly, Bloc over-engineered, or worse, global state thrown into mutable variables.
In this guide we won't give you an abstract recipe. We'll show you Provider, Riverpod, and Bloc with real code, the context where each shines, and how to choose without regrets. Below you'll find a link to our Flutter pillar for the full picture.
What is state management? (and why ignoring it costs you money)
State is the set of data that changes over time: an e-commerce cart, the list of read posts, GPS coordinates. In Flutter every Widget can have its own state, but when two screens need to share the same data, chaos reigns. Without a state management pattern, you end up with:
- Prop drilling – passing data through constructors.
- Global variables that anyone can mutate.
- Unnecessary API re-fetching because you don't know if data is stale.
The result? An app that goes to production with sync bugs, users losing data, and one-star reviews. Every hour spent chasing these bugs is an hour you didn't spend improving the product. That's why the Provider vs Riverpod vs Bloc dilemma isn't just technical—it's economical. Choosing the right tool means more predictable, maintainable, and faster-to-develop code.
Sponsored Protocol
Provider — the first step (and the simplest)
Provider was the officially recommended solution by Google for a long time. It works on a dependency + notification model: a ChangeNotifier exposes data and methods, and Widgets subscribe to receive updates.
When to use it
Provider is good for small-to-medium apps with not-too-complex state and small teams. If you have an e-commerce with cart, favorites, and logged-in user, you're fine. If you need to orchestrate dozens of async flows and cross-validations, look further.
Practical example: counter with Provider
import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
// 1. State model
class Counter extends ChangeNotifier {
int _count = 0;
int get count => _count;
void increment() {
_count++;
notifyListeners(); // notify Widgets
}
}
// 2. Provide the model to the tree
void main() {
runApp(
ChangeNotifierProvider(
create: (_) => Counter(),
child: MyApp(),
),
);
}
// 3. Consuming Widget
class CounterLabel extends StatelessWidget {
@override
Widget build(BuildContext context) {
final counter = context.watch<Counter>();
return Text('${counter.count}');
}
}Note: notifyListeners() is a double-edged sword. Call it too often and you rebuild Widgets unnecessarily. Provider has no built-in auto-disposal (you must call dispose manually).
Sponsored Protocol
Riverpod — Provider without the chains
Riverpod was born precisely from Provider's limitations. Same philosophy, but without depending on Flutter's context. Every provider is a global object declared outside the Widget tree, which means:
- You can test and access state without a BuildContext.
- Providers auto-dispose when no longer needed (ref-counting).
- Native support for async, caching, and composing providers.
When to use it
Riverpod is today the best choice for most new Flutter apps. It's flexible, lightweight, and scalable. We recommend it for projects that look to the medium term: ready to grow without rewriting everything.
Example: fetching data with Riverpod
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:http/http.dart' as http;
// 1. Async provider that calls an API
final apiDataProvider = FutureProvider<List<String>>((ref) async {
final response = await http.get(Uri.parse('https://api.example.com/items'));
if (response.statusCode != 200) throw Exception('Error');
return (response.body as List).cast<String>();
});
// 2. Consumer Widget
class DataList extends ConsumerWidget {
@override
Widget build(BuildContext context, WidgetRef ref) {
final asyncData = ref.watch(apiDataProvider);
return asyncData.when(
loading: () => CircularProgressIndicator(),
error: (err, stack) => Text('Error: $err'),
data: (items) => ListView.builder(
itemCount: items.length,
itemBuilder: (ctx, i) => ListTile(title: Text(items[i])),
),
);
}
}Notice how FutureProvider handles loading and catch automatically. No setState, no manual notifications. Data is only requested when at least one Widget is listening.
Sponsored Protocol
Bloc — the bulletproof enterprise choice
Bloc (Business Logic Component) is the most structured pattern. It's based on Events and States: the user (or system) sends an Event, the Bloc processes it and produces a new State. Everything is immutable and separated from the UI.
When to use it
Bloc excels in complex projects: apps with dozens of screens, multi-step authentication flows, cross-validated modules. If your team is large, Bloc imposes a discipline that keeps code readable. The downside? More boilerplate. For a simple app, it's a cannon to kill a mosquito.
Example: login with Bloc
// events
abstract class AuthEvent {}
class LoginPressed extends AuthEvent {
final String email, password;
LoginPressed(this.email, this.password);
}
// states
abstract class AuthState {}
class AuthInitial extends AuthState {}
class AuthLoading extends AuthState {}
class AuthSuccess extends AuthState {}
class AuthFailure extends AuthState {
final String message;
AuthFailure(this.message);
}
// Bloc
class AuthBloc extends Bloc<AuthEvent, AuthState> {
final AuthRepository repo;
AuthBloc(this.repo) : super(AuthInitial()) {
on<LoginPressed>((event, emit) async {
emit(AuthLoading());
try {
await repo.login(event.email, event.password);
emit(AuthSuccess());
} catch (e) {
emit(AuthFailure(e.toString()));
}
});
}
}
// UI – BlocProvider and BlocBuilder
BlocProvider(
create: (_) => AuthBloc(repo),
child: BlocBuilder<AuthBloc, AuthState>(
builder: (context, state) {
if (state is AuthLoading) return CircularProgressIndicator();
if (state is AuthFailure) return Text(state.message);
if (state is AuthSuccess) return Text('Welcome!');
return LoginForm();
},
),
);Every event produces a new state. The UI is a pure function of state: easier to test, easier to debug. With Bloc you can also use BlocListener for one-shot actions (e.g., navigate after login).
Sponsored Protocol
How to choose: a decision cheaper than refactoring
Here's a practical rule we use in our projects:
- Prototype or app with fewer than 10 screens → Provider is okay, but if starting from scratch go with Riverpod.
- Medium app (e.g., e-commerce, social, dashboard) → Riverpod. Less boilerplate than Bloc, more power than Provider.
- Enterprise app, multi-team, complex requirements → Bloc. The structure pays off when the project lasts years.
Don't mix patterns in the same project unless you really know what you're doing. We've seen codebases with Provider + Bloc + GetX coexisting: a nightmare.
Sponsored Protocol
In summary — what to do now
- If you're starting a new Flutter project, use Riverpod. It's the most balanced choice between simplicity and power. Study the official docs: riverpod.dev.
- If you have an existing Provider project, don't rewrite everything in a hurry. Migrate one module at a time to Riverpod (a bridge package exists).
- If your team already uses Bloc and the app is stable, stick with Bloc. You've already paid the learning curve. Invest in good folder structure and tests.
- Read our main Flutter pillar for the full cross-platform development picture: Flutter Mobile App — The Definitive Pillar.
- Always test state. Write unit tests for your providers or blocs before writing UI. With Riverpod and Bloc it's straightforward and prevents regressions.
There is no perfect solution for every project. But there is a wrong one for yours: the one you choose without reasoning about the why. We at Meteora Web chose Riverpod as our standard for our proprietary social management platform, but we use Bloc for critical modules like invoicing. The right choice is the one you understand and can sustain over time.
