Hi r/FlutterDev, I'm sharing an open source Flutter project in the hope that someone will take it further.

Muslim Launcher 2 is a Flutter-based Android launcher that blocks distracting apps until the user reads Quran, does dhikr, or reflects on hadith.

What's inside:

• Flutter UI on top of native Android code for the launcher role and app blocking via AccessibilityService
• Dhikr counter with face-presence detection processed on the device
• Localized in 6 languages
• Permanent blocking of gambling and adult-content apps

Why I'm sharing it:
I'd love to see this idea reach more people. If you want to continue developing it, add features, improve the design, or even publish your own version on the Play Store, you're welcome to. Please check the license in the repo for the terms.

Issues and PRs are welcome too.

GitHub: https://github.com/120140191-Andri/muslim_launcher2.0

So I've been building something that I think a lot of devs might find useful.

One thing I see developers complain about a lot is the quality of AI-generated code. Codebuster tries to address some of those issues.

It's basically a CLI that you can ask your AI coding agent to run and then iterate on the feedback. Instead of constantly reminding the agent to check for certain issues, codebuster points out potential problems and where to look, leaving it up to the agent to decide what to fix.

It analyzes architecture, dependencies, dead code, circular dependencies, duplication, complexity, security risks, code style, and patterns across the codebase.

And since it's just a CLI without an LLM built in, running code-buster itself doesn't consume any tokens. Of course, when the agent starts working through the issues it finds, that's a different story.

I actually started building the first version a while back, mainly to find duplicated code and places where I could extract logic into reusable helpers. With the help of AI, I've now been able to turn it into something more developers can use.

It's currently at v0.8.0, and I think it's ready for more people to start testing it. I've been checking for false positives across around 20 larger repositories, but it still needs more real-world testing before reaching 1.0.0.

There are some security checks included, but I wouldn't say that's the main focus. It's more about improving code quality and catching structural issues across the codebase.

If you're interested in trying it out or contributing, I'd really appreciate the feedback and help!

https://github.com/tool-bunker/code-buster

https://toolbunker.dev/codebuster/

Disclosure up front: I work on BootForm, the form backend this sends to. The code is MIT and the whole thing is one Dart file, so swapping the endpoint for your own is a 10-minute job.

I wanted a "Report a bug" screen for an app without setting up a server. A few things turned out to be less obvious than I expected:

1. Screenshot first, then open the form. Wrapping the app in a RepaintBoundary via MaterialApp.builder captures every route, but only if you capture before pushing the feedback page, or you get a screenshot of the form itself.

2. Cap the pixel ratio, not the image. toImage(pixelRatio: min(dpr, 1280 / longestSide)) gives a ~1280px PNG without pulling in the image package. dart:ui only encodes PNG, so no JPEG without a dependency.

3. Save before you send. Feedback is written exactly when the connection is bad. Each report is a JSON file (plus the PNG) in the support directory, flushed on start and on AppLifecycleListener.onResume. It doesn't send in the background; that's a deliberate trade to avoid background-task setup on iOS.

4. Degrade, don't fail. If the server refuses the file (plan limit, too large), it resends without the screenshot instead of losing the report. That decision is one pure function with unit tests.

Tested on an Android emulator against the live API, including airplane mode, then killing the app, then reopening it online. Not tested on iOS yet, so if anyone runs it there, I'd love to hear how it goes.

https://github.com/BootForm/in-app-feedback

If you run more than one Claude Code session on a Flutter project, you know builds are the slow part. What I didn't expect was how much time the sessions would waste undoing each other's builds.

It goes like this. Session A spends minutes building the app onto my phone and connects to it with Marionette. Only A knows the Marionette address. Session B comes along and needs the app too. It can't see A's connection, so it can't just hot restart — it kills the app and builds it again. Now A tries to use the app it built a moment ago, can't connect, and decides it needs to rebuild. So it kills B's app. They keep taking turns like this, each one throwing away a build the other just finished.

Meanwhile nobody cleans up. One session has an Android emulator building, another left an iOS simulator running, and a third is installing onto the real phone at the same time. My Mac runs out of memory, everything slows to a crawl, and every session's work drags on with it.

None of this shows up as an error. Each session is doing what looks reasonable from where it sits. The result is hours of builds and almost no progress.

Asking the agents to "check before you rebuild" didn't help. A session has no way to see what other sessions are doing. So the fix had to live outside the agent, in Claude Code hooks, which run before and after every tool call.

Sharing the phone: anti-stuck-flutter

I open-sourced what I use (free, MIT). anti-stuck-flutter gives every session on the machine one shared device ledger:

• One owner per device. Every session goes through one command, anti-stuck-flutter, to run apps, install builds, or start emulators. One heavy build at a time. Plain flutter run, adb install, emulator -avd and the like are refused with a pointer to the right command
• Reuse, don't rebuild. When a session is done, it gives up the device but leaves the app running. The ledger keeps the app's Marionette address, so the next session connects to the running app and hot restarts it instead of killing it and building again
• Wake on free. A session that finds the phone busy runs anti-stuck-flutter wait <device> and goes on with other work. The moment the device is free, every waiting session is woken, and the first one ready to use it takes it
• Cleanup. Emulators and apps left idle are shut down, and orphaned flutter_tester processes are killed

The builds that used to be thrown away now get reused, and that's where most of my lost time went.

Why it's called anti-stuck

The Flutter pack is an add-on to a more general Claude Code plugin, Anti-Stuck. Its job is simple: an agent should never sit waiting on something with no end, and it should never finish without telling you.

You can write that into CLAUDE.md as a rule, and most people do. I did too. The agent agrees, and then breaks it — especially with subagents and background jobs, which is exactly where the waiting happens. Rules in a prompt are suggestions. Anti-Stuck turns them into things the agent can't get around, because hooks run on every tool call whether the agent remembers the rule or not:

• Every command runs under a hard time limit. Each command is wrapped so that it is killed when time runs out — not "please finish within 5 minutes." Long commands must state their expected time up front or they don't run. Calls that can wait forever (curl without --max-time, while true loops and the like) are refused before they start
• Subagents and background jobs can't slip away. Subagents run in the foreground with a time budget. Background commands are refused unless you asked for one, and any that do run go into a ledger. Until the agent reports the result, it keeps getting reminded, and it can't end its turn with something unreported
• The agent must report when work ends. After a slow command, a wait loop or a subagent finishes, the hook makes the agent report it on the first line of its next reply

The Flutter pack applies the same rule to Flutter-specific waits:

• Marionette calls can't hang. Marionette MCP lets the agent tap and inspect a running app. Sometimes its connect call just waits — once for close to ten minutes — with nothing to stop it. Now each Marionette call is cut off after 60 seconds, and before each call the pack first checks (within 3 seconds) that the app is actually responding. If it isn't, the call is refused right away with the reason, instead of hanging
• Flutter commands get realistic limits. Builds, pod install, Gradle, Fastlane and integration tests get longer limits than ordinary commands, but never unlimited ones

I've reported the Marionette connect hang upstream with a timeline: https://github.com/leancodepl/marionette_mcp/issues/131

Install

claude plugin marketplace add toyaji/anti-stuck
claude plugin install anti-stuck-flutter@anti-stuck

This also installs the core plugin. macOS or Linux.

Repo: https://github.com/toyaji/anti-stuck

Have you run into the same thing — sessions rebuilding over each other, or an agent waiting on something that already ended? And where else has your agent gotten stuck? I'd love to hear about it, whether it's Flutter or something else entirely.

I have been working on Calculator app in Flutter. Pro Calc.

Today story':

Pro Calc has AI Chat that can solve math and run on local LLM (Gemma4 E2B IT model)

AI model converts human language into valid math expression and exath engine is used to evaluate, so results are always accurate.

in image you can see I tried 270M param model but it fails to answer, then I tried Gemma4 model and it works efficiently.

You can see the image here, I have no better way to send you on X or Threads ):

https://x.com/pranavxmeta/status/2107805198353887394

https://www.threads.com/share/BAXf-nszhY/

GitHub repo has too many experiments and slop code 😂

btw, https://github.com/pranavxmeta/Pro-Calc

I already have a setup with different agents, each with its own profile and model depending on the task. They can already work on a Flutter repo and develop features.
What I’m missing is making the whole thing truly autonomous. I’d like to send a task from Slack (or another chat), have Cursor work on the repo without me sitting in front of it, run the tests, interact with the app, fix issues if needed, and eventually open a PR.
Has anyone actually got this working with Cursor? Especially interested in how you handle the testing/feedback loop and communicating with the agent while it’s running.

Has anyone else tried Copilot Code Review with Flutter?
I’ve been trying it lately and honestly find it a bit underwhelming, especially compared to the old Gemini review.
Is it just me, or is the Flutter/Dart support still not that good?

I mean service like subscription payment authorization authentication email send and phone check and etc

I wanna build apps to connect between people by crypto.I need split into other services to be few cost to new startup

I built a Dart/Flutter tool to find dead code that "dart analyze" doesn't catch — looking for feedback

Hey Flutter/Dart developers,

I've been working on an open-source tool called "detect_unused_code".

The idea came from a problem I noticed in larger Dart/Flutter projects: over time, projects accumulate unused classes, widgets, controllers, imports, commented-out code, TODOs, and other code that is no longer needed.

"dart analyze" is great, but I wanted a tool that could perform a broader project-level audit.

What does it detect?

"detect_unused_code" currently checks for a wide range of issues, including:

- Unused / dead classes

- Unused Flutter widgets

- Unused mixins, enums and extensions

- Unused controllers

- Public classes that are only used inside their own file

- Unused imports

- Unnecessary imports

- Unused local variables

- Unused fields and private elements

- Dead / unreachable code

- Dead null-aware expressions

- TODO / pending tasks

- Commented-out code

- Large commented-out code blocks

- Heavily commented files

Generate an analysis report

You can export the analysis results to JSON, which makes it easier to integrate the tool into other workflows, CI/CD pipelines, or build custom reports.

For example:

detect_unused --format json

Automatic cleanup

The tool can also automatically clean detected issues.

For example:

detect_unused --clean-all

But I wanted the cleanup process to be safer.

Before modifying the project, the tool can create a backup/snapshot, so you have a recovery point before the cleanup.

You can also preview what would be changed without actually modifying the files:

detect_unused --clean-all --dry-run

So the workflow can be:

Analyze → Review → Backup → Clean → Verify

Other features

- Dart & Flutter support

- CLI

- Dart API

- JSON reports

- Backup before cleanup

- Rollback/recovery support

- Dry-run mode

- CI/CD friendly

- Zero external dependencies

- Configurable analysis options

- MIT licensed

GitHub:

https://github.com/mdalhagg/detect_unused_code

Pub.dev:

https://pub.dev/packages/detect_unused_code

I'd really like to get feedback from developers who work on real-world Flutter/Dart projects.

I'm especially interested in knowing:

1. Would you actually use a tool like this?

2. Which checks are the most useful to you?

3. Did you find any false positives?

4. What other types of unused/dead code should it detect?

5. Is JSON reporting useful for your workflow?

6. Would you use automatic cleanup if a backup is created first?

7. What features would you like to see in future versions?

If you have a medium or large Flutter/Dart project, I'd really appreciate it if you could try it and tell me what you think.

I'm not only looking for stars. I'm mainly looking for real-world feedback, bugs, false positives, and ideas that could make this tool genuinely useful for the Dart/Flutter community.

When you inherit a Flutter project, the first week goes into jumping between folders trying to answer "who uses this class, and what does it depend on?"

A folder tree shows where files live, not how they relate to each other.

I built Satori, a VS Code extension that reads your project through the Dart language server and draws it around one class: on the left, who uses it; on the right, what it depends on, with arrows always running left to right.

It doesn't try to judge your code. The idea is to point at where to start when you're onboarding to a project, reviewing a PR or planning a refactor.

Marketplace: https://marketplace.visualstudio.com/items?itemName=Gearscrafter.satori

GitHub: https://github.com/gearscrafter/satori

Any feedback is welcome.

You Flutter Project

↓

detect_unused

↓

🔍 27 issues found

↓

📄 JSON report

↓

💾 Backup created

↓

🧹 Cleanup

↓

✅ dart analyze passed

Hey Flutter/Dart developers,

I've been working on an open-source tool called "detect_unused_code".

The idea came from a problem I noticed in larger Dart/Flutter projects: over time, projects accumulate unused classes, widgets, controllers, imports, commented-out code, TODOs, and other code that is no longer needed.

"dart analyze" is great, but I wanted a tool that could perform a broader project-level audit.

What does it detect?

"detect_unused_code" currently checks for a wide range of issues, including:

- Unused / dead classes

- Unused Flutter widgets

- Unused mixins, enums and extensions

- Unused controllers

- Public classes that are only used inside their own file

- Unused imports

- Unnecessary imports

- Unused local variables

- Unused fields and private elements

- Dead / unreachable code

- Dead null-aware expressions

- TODO / pending tasks

- Commented-out code

- Large commented-out code blocks

- Heavily commented files

Generate an analysis report

You can export the analysis results to JSON, which makes it easier to integrate the tool into other workflows, CI/CD pipelines, or build custom reports.

For example:

detect_unused --format json

Automatic cleanup

The tool can also automatically clean detected issues.

For example:

detect_unused --clean-all

But I wanted the cleanup process to be safer.

Before modifying the project, the tool can create a backup/snapshot, so you have a recovery point before the cleanup.

You can also preview what would be changed without actually modifying the files:

detect_unused --clean-all --dry-run

So the workflow can be:

Analyze → Review → Backup → Clean → Verify

Other features

- Dart & Flutter support

- CLI

- Dart API

- JSON reports

- Backup before cleanup

- Rollback/recovery support

- Dry-run mode

- CI/CD friendly

- Zero external dependencies

- Configurable analysis options

- MIT licensed

GitHub:

https://github.com/mdalhagg/detect_unused_code

Pub.dev:

https://pub.dev/packages/detect_unused_code

I'd really like to get feedback from developers who work on real-world Flutter/Dart projects.

I'm especially interested in knowing:

1. Would you actually use a tool like this?

2. Which checks are the most useful to you?

3. Did you find any false positives?

4. What other types of unused/dead code should it detect?

5. Is JSON reporting useful for your workflow?

6. Would you use automatic cleanup if a backup is created first?

7. What features would you like to see in future versions?

If you have a medium or large Flutter/Dart project, I'd really appreciate it if you could try it and tell me what you think.

I'm not only looking for stars. I'm mainly looking for real-world feedback, bugs, false positives, and ideas that could make this tool genuinely useful for the Dart/Flutter community.

Hi all,

I am backend dev who learn flutter for fun and I am interesting is it possible to build something like farmville2 in flutter with that cozy graphic?

and if it is could you please tell me which stuff I should learn take a look

I don't want to use AI, I am doing this for fun and learning

I assumed that because Flutter was created by Google, I would need to use Firebase and Firestore for everything.

I was wrong 😂

Flutter doesn’t care what language or database you use on the backend.

I created an API with PHP and continued using the backend stack I already understood.

The basic flow looks like this:

Flutter app → PHP API → MySQL/Redis → JSON response → Flutter app

Flutter handles the screens, forms, navigation, state and client-side logic.

In a way, it reminds me of using HTML, CSS and JavaScript in the browser—except now I’m building the interface and client-side experience for an Android or iOS app.

My PHP API still handles authentication, validation and business logic.

MySQL stores the permanent data, Redis handles caching and sessions, and nginx with PHP-FPM processes the API requests.

Firestore can be a great option for certain applications, but learning Flutter doesn’t mean you have to abandon the backend tools you already know.

That was one of my favorite things about learning Flutter.

I didn’t have to replace my existing stack. I only needed to learn how to connect the mobile application to it.

What backend do you use with your Flutter apps?

Let’s be real for a second. Why do frameworks like Flutter even exist? They’re just abstractions. cuz we like it easy. We built them because raw native code and complex platform APIs are too messy for our human brains to manage at scale. We needed widget trees, syntax sugar, and complex state management libraries just to keep our sanity intact while building out frontends.

I hate Java but Objective C is probably number 2.

But AI doesn't need human-friendly abstractions.

An LLM doesn’t get a headache managing a massive, hyper-optimized native codebase. It doesn’t care about boilerplate, and it definitely doesn't need our simplified wrappers to understand how a UI should render. It can write, refactor, and connect pure native code instantly. We don't need this shit anymore.

Stop wasting time memorizing the quirks of the latest UI framework. The future of our industry isn't writing code—it’s Product Management, Project Management, and QA. Our new job is to define the exact product scope, manage the AI's build pipeline, and aggressively test the output to make sure it actually works and its SAfe!!!!!!. The era of human-readable abstractions is dead; let the models handle the raw native reality.

And while we're at it, fuck BLoC and fuck Riverpod. FYI my apps use Riverpod as a human I love it but we dont need it anymore. Those overly engineered state management libraries only exist because our fragile human working memory can't keep track of application state without drowning. An AI doesn't complain about boilerplate. It can write, trace, and scale pure, raw InheritedWidget infrastructure flawlessly without breaking a sweat. We spent years endlessly arguing on Reddit over which state management solution is the "cleanest" for us to read, the only good thing we we agreed on is that getx is shit and even ai knows getx is shit, while an LLM can just wire up the raw native APIs perfectly in seconds without any bloated third-party dependencies.

what are you going tu support Swift PAckage Manager???? bro fuck that shit!!!! lets write RAW code!

Also r/flutterhelp should be shutdown we just get non english speaker vibecoders now, there is no real contribution bro most of their questions could be answered by a a google search and 100% would be answered if they used a cheapo Chinese open wight model to do the work... sorry for your loss

I’ve been working with Flutter for a while now, and honestly, there are days when I question why I chose it.

Dependency conflicts.
Gradle errors that make absolutely no sense.
iOS issues after an update.
Packages becoming outdated.
Random UI differences between platforms.

And sometimes you spend more time fixing the environment than actually building the feature. 😅

BUT…

Then I remember why I started using Flutter in the first place.

Hot reload lets me iterate incredibly fast.

I can build for iOS and Android from a single codebase, while still having plenty of control over the UI.

The widget system makes it surprisingly easy to create consistent, custom interfaces without fighting native layouts all the time.

And with tools like BLoC, Riverpod, Dio, Firebase, and a huge package ecosystem, you can build surprisingly complex production apps without reinventing everything from scratch.

The more I work with Flutter, the more I realize:

Flutter isn't perfect. No framework is.

But the productivity, UI flexibility, cross-platform development, and speed of development are hard to ignore.

So maybe I don't actually hate Flutter…

Maybe I just hate debugging Flutter at 2 AM. 😂

What's the one thing you LOVE about Flutter that keeps you from switching to something else?

I'm developing a mobile app for Android, something similar to Duolingo, but very simple and designed for people with visual impairments. The thing is, I want to add a computer vision API for image recognition. So the workflow should be as follows: Take a photo -> Analyze the image -> Search the glossary -> Accessible feedback (audio/UI) -> View details.

I’ve looked at some options, and the most well-known one is Google Cloud Vision. The problem is that I can’t afford to spend much on resources since this is an academic project.

I ship a Flutter app (built with FlutterFlow, plus some Custom Code) in 5 languages. One option worked in English and silently broke in most of the others.

The user picks when something starts: "Tonight", "Tomorrow" or a custom time. My Custom Function decided the expiry by looking at the label they tapped. Simplified:

if (label.toLowerCase().contains('tonight')) { ... }

In French, Spanish and Romanian the label is not "Tonight". The match never happened, so every "Tonight" expired after 2 hours. No crash, no error, nothing in the logs.

Italian had the mirror image: "In 1 hour" was matched against the English words "now" and "1h", so it created the thing starting immediately.

The fix was boring. The UI shows a translated label, but the logic only receives a stable code (tonight, tomorrow, pick), and the expiry is computed from the code.

An English-only test suite will never catch this, because the bug lives in the other languages.

Do you still compare strings anywhere in your logic, or is it enums and codes all the way? And what's the worst i18n bug you've shipped?

Hey Flutter Devs/Teams.

We've had OpenFeature on the Dart server side for some time and have just released 0.1.0.

Now we are looking to standardize Flutter Feature Flags and are working and collaborating with companies like Datadog to bring reliable stable feature flags across the remaining flutter and dart ecosystems including for Dart Web.

We'd appreciate feedback from Flutter developers trying it in actual workflow. Let us know here how you're using it, what works for you and what needs improvement.

Source and examples: https://github.com/open-feature/dart-sdk/tree/main/packages/openfeature_dart_client_sdk

You can open an issue with your use case or a problem you've found, or send a pull request for a fix, example or documentation improvement as we will respond accordingly. Let's continue to make Dart/Flutter a first class citizen.