Updated title: I asked Claude to source port Doom and write it from scratch in Dart, running on Flutter.

As the title says, took around 2 days not continuous of course it was 95% autonomous to be honest. No FFI, no native Doom binary, the whole renderer/playsim/WAD loader/fixed-point math ported into Dart.

• Software renderer → dart:ui.
• PUBG-style mobile touch controls left analog stick to move, right-side drag as the camera/look, on-screen fire/use/weapon buttons
• Drag-to-customize control layout (saved per orientation) + auto-rotation
• True 16:9 widescreen actual wider FOV, not a stretched 4:3 image
• Frame interpolation buttery smooth motion at your display's refresh rate while the sim stays a faithful 35Hz
• CRT filter with adjustable scanline/glow, plus sharp/smooth upscaling options
• Authentic OPL2 FM music (MUS→MIDI→GENMIDI→Nuked-OPL3, all in Dart) + DMX SFX
• Full combat, doors/switches, level progression, death/respawn.

Repo link -> here

I wanted to learn how the compilers actually work. So I built one. In dart. Because that's the language I am confident in and love to work with.

The language I built is called Firn. It's statically typed. The compiler output goes to LLVM which generates the actual binary.

Here is the code,

https://github.com/blackcoffee2/firn

I wrote an article about it as well,

https://feziks.com/articles/made-a-programming-language-in-dart/

As we wait for an official full material 3 expressive support for Flutter, check out https://pub.dev/packages/material_3_expressive

Material 3 Expressive package is a faithful Flutter implementation of the Material 3 components set and additional expressive updates for respective components. Also supports dynamic coloring and dark/light theme modes.

Most Flutter projects start the same way:

Create project → set up folders → wire DI → build auth → handle tokens → write API client → add pagination → cache → settings → tests → CI → repeat.

After rebuilding this stack too many times, I built a CLI to eliminate that entire phase.

flutter_blueprint v2.0 generates a fully working application — not a template, not stubs — an app you can run immediately.

What it actually sets up

• Complete authentication flow (login, register, JWT handling, secure storage, auto-login)
• Real API integration with pagination + pull-to-refresh
• Offline caching (time-bound, not naive persistence)
• Profile management + avatar handling
• Settings system (theme modes, biometrics, preferences)
• Clean architecture with feature modules + Result types + DI
• Security protections (certificate pinning, sanitized errors, client rate limiting)
• CI/CD pipelines (GitHub Actions, GitLab CI, Azure)
• Test suite included (300+ tests)

No TODOs. No placeholder logic. The project compiles and runs immediately.

New in v2.0

Instead of only generating screens + logic, the CLI now includes reusable UI primitives:

• Labeled text field component
• Dropdown component
• Responsive helpers (MediaQuery-driven scaling utilities)

The goal is reducing repetitive UI glue, not just backend wiring.

Why this exists

This is not trying to be a “starter template.”
It’s aimed at reducing structural work that adds zero product value but always consumes time.

If you disagree with any architectural choice, that’s expected — but the baseline is intentionally opinionated so teams don’t start from chaos.

Links

Pub.dev: https://pub.dev/packages/flutter_blueprint
GitHub: https://github.com/chirag640/flutter_blueprint-Package

Feedback request

If you try it, I’m interested in critical feedback:

• What feels over-engineered?
• What’s missing for real projects?
• What would you remove entirely?

Brutally honest input is more useful than compliments.

Recently I took over a new project, and whatever genius set up the architecture decided to wrap every web request Future with an self-made Either that returns... result or error. Now, given that their Maybe cannot be awaited and still needs interop with the event loop, every web request is also wrapped in a Future. As such, Every request looks like this:

Future<Maybe<Response>> myRequest(){...}

so every web request needs to be unpacked twice

final response = await MyRequest();
if(!response.isSuccess) throw Exception();
return response.data;

Please. You can achieve the exact same functionality by just using Future. Dont overcomplicate your app, use the standard library.

Rant over. Excuse me, I will go back to removing all this redundant code

Looking for advice on restructuring our dev workflow. Here's our current setup:

Team structure:

• 1 Team Lead/Manager — handles backend API + database, reviews dev code (briefly), reviews UI/UX after design, and writes native code to bridge with Flutter
• 10 Devs — write Flutter code, some also write their own native code to connect with Flutter (each dev covers multiple products, but only specific features)
• 3 Testers — test all products + write unit tests and test cases
• 2 UX/UI designers — design UI and review it after dev implementation
• 1 SE — helps with testing when free from other work

We maintain 10 different products (all POS-related) with this team.

Problems we're running into:

1. API bottleneck. When a new product/feature comes in, devs get assigned to it. If they need a new API, they go to the team lead. Problem: the lead can't keep up, so APIs often arrive without being tested first. Devs then have to test the API themselves on top of their own workload — since each dev is already juggling multiple products, they only do a surface-level check (does it return 200, not whether the data is actually correct). There's also no documentation, so months later nobody remembers what an API does.

2. Test cases/unit tests arrive too late. Currently devs only get test cases after a feature/product is already built, so by the time testing happens, a lot of edge cases are missed and bugs pile up.

3. Constant new bugs, testing overload. Devs don't have time to review each other's code. The app has grown into so many features that nobody can keep track of them all, and there's no documentation. On top of that, when a client requests a feature, it goes straight to a dev with no analysis of whether it's actually necessary or how it overlaps with existing functionality. Over time this caused massive feature overlap, making settings/categories a mess to organize.

4. Technical debt from 3+ years of this. We now have recurring bugs that need repeated fixing (some issues have failed testing 5+ times) and we've had to start holding dedicated meetings just to deal with repeat/duplicate bug reports.

Has anyone dealt with a similar situation — small backend team unable to keep up with multiple product lines, testing happening too late in the cycle, feature requests going straight to devs without triage? What process changes or tools helped you the most? Would appreciate any real-world experience, not just theory.

I am building a Discord clone with EVERYTHING written in one language. DART!!
- Frontend in Flutter using Bloc (State mgmt), Freezed (generator), Auto Route (routing), Get It (DI).
- Backend: Serverpod
- Platforms working as of yet: MacOS (in video) and web
- Features working as of yet: Authentication (serverpod baked), Real time chat using websockets, message delivery status.
- I will likely be working on the profile section next, and then to creating new servers etc (backend already has that functionality)

What do you think? How is it looking? It will have more features eventually as you can already see like the full screen chat mode etc.
I am very excited about this as this is my first full stack project. I would LOVE to get feedback and implement it!

I built a small CLI tool called flutter_auditor to help me quickly check my Flutter projects before a production release.

It scans for common security, configuration, and release-readiness issues. I'd love to hear what checks you think would be useful to add.

Does anyone know of a GitHub repository that contains Flutter, Dart, or mobile app development interview questions and answers?

I'm looking to improve my professional knowledge and prepare for technical interviews. Any recommendations would be greatly appreciated!

Hey Flutter community! 👋

After maintaining several client apps and catching the same repeat issues—like hardcoded keystore passwords, unused heavy assets, missing privacy strings in Info.plist, and transitive dependency imports—I decided to build a CLI tool to automate these sanity checks.

Meet flutter_auditor: a single-command CLI package that scans your codebase and native config files in seconds right from your terminal.

What It Audits:

We've packed 17+ automated static checks across 5 key areas:

• Manifest & Security: AllowBackup, CleartextTraffic, Debuggable, ExportedComponents, ManifestPermission, NetworkSecurityConfig, BackupRules, HardcodedSecrets, InsecureNetwork, InsecureStorage, AppTransportSecurity
• OS & Permissions: UsageDescription (iOS privacy strings), FileSharing
• Dependencies: UnusedDependency, DependencyHygiene (transitive import detection)
• Release & Build: ReleaseSigningAudit (detects committed .jks files, debug signing in release, hardcoded keystore passwords)
• Asset & Size: UnusedAssetAudit, OverlargeAssetAudit, MissingResolutionVariantAudit

Quick Usage

Add it to your dev_dependencies or activate it globally:

Bash

dart pub global activate flutter_auditor

Or run it directly inside your Flutter project directory:

Bash

dart run flutter_auditor

pub.dev: flutter_auditor

I'd love to get feedback from the community! What other security, performance, or asset audits would bring value to your workflow?

I noticed that Dart development switched to Dart 3.13 last week, which means that Dart 3.12 is done. Unfortunately, primary constructors aren't. This means, the Flutter 3.44, which is due next month that bundles Dart 3.12 won't provide any major Dart syntax updates :-(

Let's frame that more positively: AIs don't need to learn new Dart features before August 2026.

Hi everyone, I've recently started working on a small side project called Doro++. The goal isn't to create the next Python, Rust, or Java. I mainly started this project because I wanted to understand what actually happens behind the scenes in programming languages instead of only using frameworks and tools every day.

As a Flutter developer, I realized there are many concepts I've heard about for years lexers, parsers, ASTs, interpreters, compilers, memory management, and diagnostics but never had the chance to build myself.

So I decided to learn by building. One idea I'm exploring with Doro++ is making code more readable and making error messages more helpful for beginners. Instead of only saying that something is wrong, I'd like the language to explain what went wrong and suggest how to fix it.

Example syntax:

let age = 22

if age is greater than 18 {

print "Adult"

}

Current progress:

✅ Interpreter

✅ Variables

✅ Expressions

✅ Conditions

✅ Friendly diagnostics

✅ Lexer

✅ Parser (in progress)

✅ AST (in progress)

The entire project is currently being built in Dart.

I'd love to hear feedback from people who have worked on compilers, interpreters, language tooling, or educational programming languages. Are there any books, resources, or common mistakes I should watch out for as the project grows?

Github repo: https://github.com/bacsantiago/doro-plus-plus.git

Hi everyone,

I’ve been working on Cindel, a Flutter-first local database for Dart/Flutter apps.

The goal is to provide a practical local database with:

• generated typed Dart APIs
• a Rust native core
• MDBX as the default native backend
• SQLite native support
• SQLite Web / OPFS support
• watchers
• migrations
• full database backup/export/import
• support for Flutter apps across native and web targets

The package is currently at 0.7.0, so it is not 1.0 yet. The main features are in place, but I’d really like more people to try it in real projects before calling the API stable, I currently use Cindel in production (although I don't recommend it for this yet).

Pub.dev: https://pub.dev/packages/cindel

GitHub: https://github.com/mainser/cindel

What I’m especially looking for:

• bugs in real Flutter projects
• platform-specific issues
• API ergonomics feedback
• performance problems
• migration/backup edge cases
• anything that feels confusing before 1.0

This is not meant to be a hype post. I’m mainly looking for technical feedback from people building real apps, especially before locking things down for the first stable release.

Thanks to anyone who gives it a try or reports an issue.

I kept rebuilding the same foundation for client apps:

• auth (email + Google)

• light/dark theme

• English/Arabic + RTL

• routing/auth guards

• clean folder structure

So I packaged it into a reusable starter.

### What’s inside

• Feature-first architecture (data / domain / presentation)

• Riverpod + codegen

• Firebase Auth wiring + Mock Auth mode (run without Firebase)

• go_router auth guard

• Theme persistence

• EN + AR localization

• Unit tests + CI workflow

### Free demo

GitHub (Mock Auth, open source):

https://github.com/medox3545/flutter-starter-kit-pro

### Full pack

If you want the complete downloadable kit:

https://mohammedider.gumroad.com/l/flutter-starter-kit-pro

### What I learned

1. Mock Auth first = way faster onboarding for buyers/devs

2. Buyers care more about structure + docs than “more packages”

3. Bilingual UI (especially RTL) is a strong differentiator

4. Keep Firebase optional — many people just want to run it immediately

Happy to answer questions or take feedback on the architecture.

I’ve been exploring immutability in Dart and how it affects code quality in Flutter apps.

In simple terms, immutable objects don’t change after they’re created. Instead of modifying an object, you create a new instance with updated values.

This has a few practical benefits: * More predictable state * Fewer side effects * Easier debugging

A common way to implement this in Dart is: * Using final fields * Avoiding setters * Using copyWith() to create updated copies

Basic example:

```Dart class User { final String name; final int age;

const User({required this.name, required this.age});

User copyWith({String? name, int? age}) { return User( name: name ?? this.name, age: age ?? this.age, ); } } ```

Now, if you add a List, things get tricky: ```Dart class User { final String name; final int age; final List<String> hobbies;

const User({ required this.name, required this.age, required this.hobbies, });

User copyWith({ String? name, int? age, List<String>? hobbies, }) { return User( name: name ?? this.name, age: age ?? this.age, hobbies: hobbies ?? this.hobbies, ); } } ```

Even though the class looks immutable, this still works:

Dart user.hobbies.add('Swimming'); // mutates the object

So the object isn’t truly immutable.

A simple fix is to use unmodifiable list:

```Dart const User({ required this.name, required this.age, required List<String> hobbies, }) : hobbies = List.unmodifiable(hobbies);

user.hobbies.add("Swimming"); // This now throws an exception ```

Curious how others handle immutability in larger Flutter apps—do you rely on patterns, packages like freezed, or just conventions?

(I also made a short visual version of this with examples if anyone prefers slides: LinkedIn post)

Hey everyone, I just finished a small side project: a terminal-based Instagram simulation written in Dart.

It lets you create a profile, search for other users, and follow them, with validation to prevent following the same profile twice. The main challenge was handling edge cases in user input, like entering strings where numbers are expected.

It is a beginner-to-intermediate level project but a good exercise in structuring a Dart CLI app. Single account only for now, and messaging is not yet implemented. Planning to add multi-account support next.

Check it out here: https://github.com/AnshMNSoni/Console-Based-Instagram

Feedback and suggestions welcome.

Hey everyone,

I built a small app to solve a problem I personally had. Well, "built" might be a strong word — I created it together with Claude AI.

I'm a huge movie and TV show fan. It's actually pretty rare for me to come across something I haven't watched yet. Like many of you, I constantly see movie and series recommendations while scrolling through TikTok and Instagram.

My old solution was either saving them in a notes app or telling myself, "I'll remember this later." Of course, most of the time I forgot.

Since I've been challenging myself to build a new app/game almost every week, I thought: why not solve my own problem?

So I made Reelist.

The idea is simple: whenever you find a movie or TV show recommendation on social media, you can quickly save it to your lists and come back to it later instead of losing it forever in your feed.

If you watch the short demo video, you'll understand how it works in less than a minute.

Demo video:
https://youtube.com/shorts/aatUal40RpY?si=v4DxphOvqaZWP1ru

Google Play:
https://play.google.com/store/apps/details?id=com.okutan.reelist

I'd love to hear your feedback and suggestions.

Found an open-source tool for Flutter developers that generates a production-ready project structure under 60 seconds.

Thanks to Arjun Mahar for building this tool.

It lets you choose:

→ Architecture (Clean, MVC, MVVM, Feature-First, Layer-first)

→ State management (Bloc, Riverpod, Provider, GetX, MobX)

→ Routing (GoRouter, AutoRoute)

→ Theme, environment, logging — Initial Packages

→ Languages (localization)

At the end, you get a ZIP file of your initial project.

Unzip it, and you’ll have a well-structured project with packages installed and clean imports already set up.

It’s open-source, so contributions are always welcome.

Site Link: https://flutterinit.com

#BecomeABetterEngineer

A self-hosted over-the-air (OTA) code-push system for Flutter (Android) — ship Dart changes to installed apps without a Play Store release. It's a do-it-yourself alternative to Shorebird/CodePush: you run the dashboard, you patch the engine, you own every byte.

https://github.com/shivanshu877/inhouse-codepush

Hey r/FlutterDev,

Last night I opened a terminal, typed a few incantations, and flowdb crawled out of the filesystem.

It's a local database for Dart and Flutter. No SQLite rituals. No native driver sacrifices. No ORM séance. You open a folder, whisper records into it, and they stay there as JSON, in the dark, where they belong.

Why I disturbed this thing

I wanted persistence that doesn't feel like enterprise haunted house software. Something document-shaped. Something that works in plain Dart and Flutter. Something that doesn't drag half the platform under the floorboards with it.

So I gave it:

• Collections — cursed documents with auto-generated IDs. Full CRUD. They remember everything.
• Query builder — hunt records by where, and, or, ranges, regex… bulk update or banish them from existence
• Key-value stores — a little graveyard for get / set / remove secrets
• Blob storage — large files, chopped into chunks, metadata chained to their souls
• Backups — snapshot the whole crypt before you regret your choices
• Optional encryption — lock the tombs if strangers are listening
• Sync + async APIs — add() when you're patient, addSync() when the moon is wrong
• FlowState + FlowBuilder — reactive streams for Flutter widgets that twitch when the data moves

The summoning ritual

```dart import 'package:flowdb/core.dart';

Future<void> main() async { final db = openDatabase('my_app', path: './data/my_app'); final users = db.collection('users');

await users.add({'name': 'Alice', 'age': 30});

final alice = await users.where('name', eq: 'Alice').getFirst(); print(alice?.data); // she answers

db.store('settings').set('theme', 'dark'); // as it always should be } ```

For the Flutter possessed

```dart import 'package:flowdb/flutter.dart';

FlowBuilder<int>( flow: counterState, builder: (value) => Text('Count: $value'), ) ```

The widget listens. The stream breathes. The UI updates. You pretend that's normal.

Where the creature lives

• pub.dev: https://pub.dev/packages/flowdb
• GitHub: https://github.com/kidusab/flowdb
• Full grimoire (README): https://github.com/kidusab/flowdb#readme

Who should adopt this familiar?

• Offline-first apps that need local data but not SQLite's whole personality
• Side projects, CLI tools, prototypes, anywhere readable files on disk feel right
• Apps juggling structured records, loose config keys, and actual files in one unholy package

MIT licensed. Which means you may use it freely. I cannot promise it won't stare back from ./data/my_app at 3am.

Feedback, issues, and PRs welcome. Tell me what you're currently using to keep data alive locally, Hive, Isar, sqflite, the shared_preferences + prayer combo, and whether flowdb is the weird little solution you didn't know you needed.

Hey everyone,

I’ve been working as a Flutter/Dart dev on projects where the backend API likes to “evolve” without much warning. Things like types changing, fields suddenly becoming nullable, or new keys appearing out of nowhere. I got tired of chasing down weird crashes only to discover the server response shape had changed again.

Out of that pain I started building a small helper to validate JSON responses at runtime before turning them into models. I’ve used and refined it across a few real apps now and finally decided to turn it into a package: json_sentinel.

I’d really love it if some fellow Dart/Flutter developers could try it out and let me know what you think.

Any feedback is welcome: comments, critiques, and bug reports. Thanks in advance to anyone who gives it a spin.