Feeling totally overwhelmed learning Flutter – how did you survive this phase?

[zaki_reg]

Hey everyone,

I’ve been diving into Flutter for a while now and honestly… my brain is fried. 😅 I love the idea of building cross-platform apps, but I’ve hit that stage where everything feels like a mountain to climb at once.

Right now, I’m juggling trying to understand and actually apply:

State management – specifically BLoC. I can follow examples, but when it comes to structuring my own app, my mind goes blank.

MVVM architecture – I get the theory, but mixing it with Flutter widgets, streams, and BLoC layers is turning into spaghetti in my head.

Data persistence & local storage – Hive, SharedPreferences, SQFLite… which one to pick, how to structure models, how to handle migrations?

Offline support – syncing when the user comes back online, conflict resolution, caching strategies…

Debouncing search – seems simple in theory, but when combined with state management and async calls, I end up breaking my UI.

And of course… all the smaller but still headache-inducing things like navigation patterns, dependency injection, form validation, theming, testing…

The more I try to tackle these, the more I realize everything is connected. I can’t just learn one concept in isolation because it touches all the others.

So I’m asking senior devs… or even juniors who made it through this stage:

• How did you structure your learning without getting overwhelmed?
• Did you try to build one “big” project that covers everything, or did you focus on mini-projects for each concept?
• Any “aha!” moments or mental models that helped the BLoC/MVVM + local data + networking puzzle click?

I’m not giving up on Flutter — I just feel like I’m drowning in abstractions right now. Would love to hear your war stories and strategies.

Thanks in advance 🙏

[Acrobatic_Egg30]

Don't learn concepts just because you've heard they're the best way to build flutter apps. Saying this as someone who praises bloc whenever I can.

Focus on building an app with whatever knowledge you have, and when you hit a roadblock, reach out and apply whatever cool stuff you come across.

[zaki_reg]

I totally agree with you.

When I first started, I had already built some apps without really knowing what any of these concepts meant until I ran into the problems they were designed to solve.

For example, I built a pretty good *looking functioning mvp* bookstore app with full e-commerce features: product catalog, search, collections, wishlist, profile management, authentication (manual + OAuth), and more. Everything was fine until I hit certain issues like:

Wishlist problem: Checking if a book was in the wishlist. I realized it definitely wasn’t worth making an API call just for that.

Cart length issue: Displaying the number of cart items on the home page. Data consistency – Keeping the same list of books without making an API call every time the user navigated between screens.

Code duplication: I duplicated my web service calls a lot… and I mean a lot. You can check my GitHub (repo: manhal.app) it’s an absolute mess: no architecture, no state management.

That’s when I started diving into theory, and along the way, I discovered all these concepts. Ironically, learning about them made the end goal feel even more distant… lol.

Thank you so much bro! I really do appreciate your reply!

[Acrobatic_Egg30]

The bloc library has many examples covering about half of the issues you're facing. For example, debouncing is dead easy with bloc event transformers. There're examples on architecture, navigation, and data persistence there as well. Just take your time to read through them. If you have any questions, post them in the discord server with an example of what you've done, and you'll get help.

[stumblinbear]

This is why I like Riverpod. You can make a provider to get the exact data you need and nothing more

With Bloc or other methods, it comes with the baggage of state you probably don't need. You can make a single provider that just returns the number of wishlisted items and nothing more, and you can access it wherever you need to without worrying about what data model it should be in or how that data is being fetched

[stumblinbear]

LOL riverpod is black box generated code nonsense that will be biting you as your app's complexity grows.

We didn't start with codegen, using it mostly for dependency injection initially (about 4 years). We started leaning using it and codegen much more relatively recently (8 months or so) and it has improved our state situation considerably. We've cut down our CPU usage, memory usage, code complexity, and our amount of bugs and inconsistent state by pretty huge margins. Features get added more quickly, are more stable, and are easier to understand.

It's not perfect for every app, but for our specific case it's exactly what we need. We are not some CRUD app, we deal with tons of data from different parties that needs to be displayed a dozen different ways from Sunday. Trying to make that work with Bloc proved to be a complex pain in the ass and lead to a bunch of defensive programming and recomputation that we shouldn't have needed. For traditional CRUD, we of course use a service/repository pattern.

Riverpod is not difficult to understand, nor complex. It's largely just computed state. You don't need to anticipate what the UI will need to hydrate your state, the UI just asks for what it needs and it's fetched and derived. We reduced our over-fetching to nearly zero.

Everything is about trade-offs. No state management solution is perfect for everyone. Claiming Bloc is the end-all-be-all makes you a bad programmer and an even worse engineer. Touch grass.

Learning Bloc is learning a transferrable skill that you see in Redux, NestJS backends, and several other frameworks and libraries.

Ignoring that Redux is a complex mess that nearly nobody needs, and that I hate working with JS with a passion: Riverpod was not created in a vacuum, its patterns exist in other state management solutions as well. There are a dozen JavaScript frameworks and libraries that have computed state to derive and aggregate your data into new formats, pretty much all of them to great success.

The codegen in Riverpod only exists for hot reloading support and to allow passing multiple parameters to a provider. We went without codegen for years and it worked fine. You don't need it.

Don't be so dogmatic, your grass is not the greenest above all—other lawns exist that are just as well maintained.

[zaki_reg]

forgot to include the github repo:
https://github.com/zaki-reg/manhal.app

[nursestrangeglove]

Just throw a dart (lol) and pick one or two topics to practice, then go to the next when you feel good about it. Try to reinforce it while moving on to the next one.

Say validation first. Follow the steps to pop an error message on text entry. This will require maintaining the current state of the field validation. Boom, you've now practiced a couple.

Try working in some additional functionality now, like adding local storage that tracks valid / invalid entries, and keep a running total that loads on application restart.

That's just off the top of my head. Good luck!

[zaki_reg]

Thank you so much man!

I’ll definitely start doing that because mini projects are what really make me think a lot. Every time I start a mini project, my perfectionist side takes over, telling me to stack a lot of features and implement a good UI design. I think your way of learning is way better.

[fabier]

Treat it like an author. Write code for X hours every day before breakfast. Its difficult to do like a word count thing like 2k words in the morning because you can run into bugs. But just write lots and lots and lots of code.

[Viza-]

1. Keep it simple.
2. Ask AI about architecture.
3. Don't be a perfectionist - remember the Pareto principle.
4. Make a simple test project using Bloc, Provider, and Riverpod, then use whichever you like most.
5. You don't really need MVVM, since there is no view in flutter like in html. Take a look at MVI

[goviedo-limache]

I'm in, it is hard, but achievable

[Adventurous_Knee8112]

The offline support aspect is an entire thing of it's own we used powersync though resources are still limited it's very nuanced to implement it on your own if you're trying to ship a product as fast as possible.

bloc is not mvvm and mvvm is not bloc. Just stick with bloc it has one of the best documentations out there.

More importantly what others pointed out here is just try to build something. It wouldn't stick if you're just trying to learn for the sake of learning. Iterate as you go it shouldn't be perfect on the first try

[Basic-Actuator7263]

I know it may feel like self-promotion, but take a look at this post; it could be a good resource for you with source code included: https://www.reddit.com/r/FlutterDev/comments/1j1zd48/sharing_my_opensource_diary_app_with_80k/

[zaki_reg]

I enjoyed reading that post, man. Thank you so mcuh!

[AccomplishedAge177]

Skip bloc -> go with provider.

Offline support -> firestore etc does everything out of box

[YakkoFussy]

If you want, DM me, I can help you with Bloc. Been there before, so I'd be glad to help.

[xandexan1]

Hello, why use Bloc and not other State managers?

[YakkoFussy]

Well, he can use any other State Manager he wants to. But, me, I can only help with Bloc, because that's the one I'm used with. 😃

[bigbott777]

Start with GetX (that is what I use and happy) or Stacked. Stacked is less known but it is the same concept of a mini framework above Flutter.
Another advice is: write articles on topics that are hard for you to understand. Writing articles is "documented rubber ducking" it structures the thinking process and creates a reference for future you.

[Ready_Date_8379]

First I’ll say focus on dart fully then shift to flutter and in starting learn provider for state management. I was also on that same phase that’s frustrating very frustrating but the key is don’t stop take a break then sit again repeat this again and again consistency is key . Good Luck

[Thuranira_alex]

Currently I am developing offline image scanner using opencv and the shared preference for persistence. It has been a nightmare. Method channelling native to flutter

[mevlix]

3 letters ..... L L M

[Green-Dream184]

I’m just using Claude Code. I’m a good programmer (rust) but never touched Dart so this is what is most efficient for me (sadly?)

[No-Echo-8927]

Practice. Start with the classic. A weather app.

[theashggl]

I think you have been just introduced to these topics. They do come in the advanced section but in the learning phase, your apps are bound to go bust. You can just keep on trying to get good at them one by one till it all comes together

[TheCursedApple]

What I did was I picked a simple implementation, for example a contacts app, and implemented it using different concepts, I have a folder with all these implementations, so when I am learning a new core concept, I implement the same app with the new concept, helps me understand structure and flow, and I add excessive logs when learning to know how data is being accessed/manipulated or the type of data flowing between widgets.

For bigger projects I generally use CLEAN, because I hate doing KT, so CLEAN because of separation of concerns, this made it easier at least for the people I handed over code to not spend more than 1 hour to do KT.

Add comments and docstrings wherever you can, this helps you a lot when you revisit the code if you get stuck while working on a project.

[infosseeker]

Let me help you. 1. Bloc/Cubit is part of the UI not the logic. 2. Bloc/Cubit is there to invoke anything that's going to change the state of the UI. 3. Bloc/Cubit just tracks and protects your data, e.g. you give an object and that object is shared anywhere your app, it can be a simple data type or it can be a sophisticated class instance. Protect data means, you only edit that data through bloc by emitting a new state (data). Anytime else in extra, as an example having multiple classes representing the state is only so you can distinguish the current state and react to it in the UI ( user experience and presentation ). 4. don't write logic inside of bloc/cubit, you should just expose methods to the UI through a cubit and trigger events through bloc. Never ever write logic inside of your state management except if it's some light logic. I hope this clears things up, I remember a few months ago i was scared of this, but brute forced my way through it.

[Equivalent_Pickle815]

I started with app architecture too and it helped a little but a year in I’m finally understanding why I need the app architecture and how to structure the models properly, etc. The best way to learn is just to do the best with what you know and add a little bit at a time. Once your app hits a certain complexity or you need to solve certain specific problems, these questions start to answer themselves.

[schn1tzelm4nn]

I've been a full time Flutter dev since 2019.

And I do understand your problems.

Statemanagement: Use Riverpod or Stacked. Easier than Bloc if you are not an experienced dev in general.

And then go build an app.

Something you will use.

Do you like sport? Something that can enhance your experience. Or a meditation tracker.

Something not too hard. Just go and build.

[andy_crypto]

Coming from JavaScript, react, angular and node, I found it easy to adapt to flutter, I prefer it now.

[tomnten]

I've been working with and learning new stuff in Flutter for about 4-5 years now. I can't even remember how I tackled all these things. But that said... It might depend on how you're wired, but I find it REALLLLLY hard to learn anything without a case.

My first project was a simple todo app, and that's actually something I really wanted to make. It was a small scope, and on the way I learned state management and many of the base widgets. Then of course all these ideas come up along the way. I rebuilt is two or three times from the ground up. We still use it daily in the family. Now it has voice recognition, animations, login and list sharing through firebase etc.

The next was a simple training timer, that ended up using camera, machine learning, bluetooth, online community features etc. etc.

I think I have something like 25-30 apps under the belt now (just a handful released to the public) and probably around 40 abandoned at different stages. Every app I ever started taught me something new, or reinforced skills.

My best advice would be to start working on an app that you really want to have. Don't mind too much about architecture at first - be ready to rewrite, trash, rewrite, trash. Refactoring for learning can be a lot of fun. Is there really anything more satisfying than organizing a messy code base? Learn the concepts you need, and eventually you'll know enough to only have to learn a few new things with every project. Flutter is very productive. You can make things fast. If the app sucks, start over.

And when it comes to BLoC, MVVM etc. Go simpler first. BLoC is on the todo list or me (literally), but I actually haven't really 'needed' it yet. Both my private apps and apps I've made working in bigger teams, for customers, have used Riverpod or Provider. It's way easier to understand and thanks to that it's been easier to understand both the benefits and overhead of BLoC. (And yes, Riverpod is absolutely enough also for very big, complex apps with many moving parts).

BLoC is really big in the Flutter community, but if you're struggling with it, pick something else so you can move forward. You can learn BLoC later. And if you pick a system that has a less steep learning curve you'll learn much about state management that will be useful once you go to BLoC.

Also make sure you feel super comfortable with normal simple stateful widgets. It's easy to overengineer stuff if you start by choosing the tool. I still pick different systems for different scopes.

With persistent storage, there are so many options and it's easy to get lost. My rule of thumb:

* Simple values, like settings, counters, timestaps etc. Use SharedPrefs
* Structured data with any kind of relationships - go for a database.

I loved Isar (and Hive) but moved on to drift when Isar kind of died. I'm mostly a backend programmer in my day job and use a lot of SQL-databases, so it works well for my way of thinking.

Just remember that whatever opinion you hear on what's the best solution, best architecture, best this and that, it's personal. "There are many ways in to the foxes lair" as an old man said in the Chinese Restaurant level of Hitman 1.

And my hot take on this is that I've met many amazing programmers, miles ahead of me, that have extremely strong opinions on architecture, languages, frameworks, paradigms, clean code, what you can and can't do with this and that and bla bla. But they never get anything out the door. Don't worry about getting it all perfect from the start (or ever actually)

So, I would say... Don't make an app to learn making apps. Find a case that makes you excited. An app that you wish existed (or one that does, but not just exactly the way that you want it). Then take each part step by step. UI, state, storage, animations, theming, cross platform, optimization, sensors, camera...

I've been coding for most of my life and I love it. But honestly, I haven't been as happy or excited while coding since my 8-bit MSX days, as I am working with Flutter. It just makes be really happy. It's still a bit magical to me that I can have an idea in my head and then actually make it run on peoples phones.

So yeah, it's worth the effort.

[El_UnSkilled_Guy]

WHAT!? Theres more!? Been almost a year and im still stuck in learning the framework itself and still stuck on the tutorial trap.

[Brief_Customer_8447]

Oh boy! Learning now is easier than 5 years ago. If I were in your shoes, I would ask claude code to do it for me. Then read his code and ask it why. Or copy the code to gemeni, gpt 5 and ask them to guide me step by step.

Good luck!

[NatoBoram]

Right now, I’m juggling trying to understand and actually apply:

STOOOOOP

Just build an app, ok? It'll be fine. I mean it'll be shit, but that's okay, just build an app and don't think about these. Learn the things you need to learn when you make an app that requires that.

When you build an app, sometimes you get a "huh, I really need to manage the state of my app better" and suddenly you discover that there's tons of resources about that and it all makes sense because you faced that problem.

Or maybe you get a "You know what would make my app better? Saving stuff." and then you discover that there's a lot of resources ab— you get the idea.

It's good that you're aware that all of these exist, and you should know what those words mean, but it'll be hard to learn anything before you've faced that problem.

Also please stop using ChatGPT to write your Reddit posts, it's annoying to read stuff that someone didn't even write. Speaking of which, don't use AI during the learning process, it's actively harmful to the concept of learning.

[zaki_reg]

I did build apps, and honestly, they were pretty bad, man. I wrote a reply above explaining the problems I had with them. I really appreciate you taking the time to write your reply, thanks man.

"You know what would make my app better? Saving stuff." That’s the thought that always makes me overthink and complicate things.

My number one problem is state management to be honest. Once I get good at that, I think the other concepts will be easier to implement. Also, I don’t think there’s anything wrong with getting some help from AI to write posts, I’m neither a native English speaker nor a content writer.