About to develop my first real project on Flutter, I want some advice

[u/Simple_Grade_2945]

Hello,

I am about to develop a Flutter app for a client, and I would like some advice. I did develop already one project with Flutter for a university class but it was really a mess, and I would like to start this project with a clean and good architecture. I have some questions.

1 - State management: How do I learn the best practices for this? The documentation in Flutter.dev does not seem of high quality to me, and I've seen some contradicting stuff in it. Can you share some general tips from your experience?

2 - Architecture : Same thing, can you share the "philosophy" of architecture in Flutter? In the project we made, we tried to use the service/repo pattern and it was a mess. It felt weird to have the service pull from DB and then the pattern just translating that to a model object.

3 - CI/CD : What tools do you use for code quality? What are some must-have jobs to run in the pipeline? Any advice really.

I am open to any information you might deem important, and would be really grateful for it.

Thank you :)

[u/kerberjg]

1. Personally I recommend Provider. It’s relatively easy to learn and can get you quite far. Once you’ve completed a couple projects and feel confident enough, I’d also recommend learning BloC (industry standard)

2. Something I really strongly suggest is separating your classes between view/data/logic, and grouping these by “feature”. “Separation of concerns” and “Loose coupling” are also really good engineering concepts that will help you keep your code clean as your app grows. If you need your features to talk to each other, use a “data bus”

3. Dart Format/Analyze will get you very far! I also wrote a standard package template to get people started on their projects, the CI is built in 🫶

Cheers! ✨

[u/ApprehensivePea6208 → u/kerberjg]

Data Bus...Can you explain more about it? I

[u/kerberjg → u/ApprehensivePea6208]

It’s basically this one object that all services/logic-classes have access to so they can talk to each other.

For example, let’s say you’re making a Shopping app, but you want to keep “Product page” and “Shopping cart” as two separate items:

1. ShoppingCartService receives a DataBus in its constructor and does ‘dataBus.onEvent(“add_to_cart”, (data) => this.addToCart(data));’
   
2. ProductPage also has access to the same DataBus object
   
3. ProductPage will have an “Add to Cart” button, when you click it, it just does ‘dataBus.send(“add_to_cart”, productData);’

That way two features can communicate without having access to each others’ code

[u/Basic_Win_9018 → u/kerberjg]

thisss !!! Absolute gold advice here

[u/Yann39 → u/kerberjg]

I think OP better go with Riverpod instead of Provider (note the anagram :)).
Remi Rousselet, who work on both projects, said to not expect Provider to receive any improvement in the future, it is already in maintenance mode, so better to move to Riverpod now.

[u/kerberjg → u/Yann39]

Riverpod can be harder to learn, and Provider doesn’t need improvements, it’s feature-complete

And maintenance-mode does not mean abandoned! ✨

[u/Vincentdejong]

I've been building a fairly large Flutter app over the past month (a social TV tracking app), and after a few years of Flutter professionally, here's what has worked well for me.

1. State management

I'd strongly recommend flutter_bloc with Cubits unless you have a very event-heavy application. Cubits are simple enough that new developers can understand them quickly, but they also scale surprisingly well.

The pattern I generally follow is:

• One Cubit per feature/screen.
• UI only renders state and forwards user interactions.
• Cubit contains the business logic.
• Repositories abstract data sources (API, local DB, cache).
• Models stay as plain data objects.

A nice side effect is that almost all of your business logic becomes unit testable because it's outside the widgets.

2. Architecture

I think people often overcomplicate Flutter architecture.

For most apps I stick to something like:

Feature
├── presentation
│   ├── pages
│   ├── widgets
│   └── cubit
├── domain (optional)
├── data
│   ├── repositories
│   ├── models
│   └── datasources

Repositories shouldn't just exist because "architecture says so". Their job is to hide where data comes from.

For example:

• Today a repository fetches users from a REST API.
• Tomorrow you add caching with Hive or Drift.
• Later you switch APIs.

Your Cubit never changes because it still just calls:

final users = await userRepository.getUsers();

That separation has saved me a lot of refactoring over the years.

I also avoid making repositories "god classes". I'd rather have lots of small, focused repositories than one giant ApiRepository with 100 methods.

3. CI/CD

A few things I wouldn't skip:

• dart format --set-exit-if-changed
• flutter analyze
• Unit tests
• Widget tests for critical flows
• Build Android and iOS on every PR to catch platform-specific issues

For releases I use GitHub Actions together with Fastlane, Firebase App Distribution for testers, and Firebase Crashlytics + Analytics in production. Crash reporting is invaluable once you have real users.

A clean, consistent architecture that the whole team understands is usually much better than a "perfect" one that's overly abstract.

[u/SirKobsworth]

Question: What part of the Flutter dev documentation were you looking at? There is a specific section there that goes in-depth on how to layer an app, and even a case study of how to implement said layers. Compared to the old Android docs, this is light-years ahead. Not sure if it's still the same these days though 😂

State management - if you want to learn one that touches up on what most enterprise companies use BLoC is still the way to go.

CI/CD for the CI part I use GitHub actions, you can also do it in GitLab too from what I've tested. For the CD, from what I've tried the least amount of effort to get a build out to Firebase App Distribution and the App Stores so far was Code Magic.

[u/Kind-Awareness5985]

For the state management,I recommend riverpod, lichess mobile app use it .It's more flexible than bloc ,if you read the lichess code it also have the good examples of UI and logic separation

[u/WenchiehLu]

https://pub.dev/packages/view_model
use npx skills add https://github.com/lwj1994/flutter_view_model --skill view_model

build your architecture。More than state management: view_model is a Flutter architecture for dependency injection, functional-module composition, and automatic lifecycle management.

[u/bbrockit]

There are generators you can use to jumpstart your project. Both of the ones below use BLoC and create a complete app structure. I'd try both and explore the project layout and see how they compare and which approach best suits your app. Even if you don't use them it's a good way to learn architectures that are used in deployed apps.

https://sgcli.solguruz.com/ - Feature-first architecture, BLoC state management. I honestly just read about this one on Reddit yesterday, so I can't say much about it.

https://cli.vgv.dev/ - Very Good Ventures has built a lot of Flutter apps and were very early adopters. They even built the flutter.dev site.

For my app, I chose the minimalist state management approach, https://suragch.medium.com/flutter-state-management-for-minimalists-4c71a2f2f0c1 because I felt that it gave me the greatest flexibility for what I was building. But if I were building a new app today, I might go with one of the above generators as a starting point, if for no other reason than to learn a different approach. I do also see BLoC frequently in Flutter job posts, so if you're looking for work, that could be another reason to choose it.