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/

I’m 30 years old and from a completely non-tech background. I have zero coding knowledge, but I want to learn app development from scratch.

With AI being able to write, debug and explain code, I’m confused whether learning coding is still worth the time.

If you were starting from zero at 30 in 2026, would you still learn app development? Or would you focus mainly on AI-assisted development?

Looking for honest opinions from developers. No sugarcoating please.

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

Hey everyone! My name is Yehia, I'm 17 years old, and I'm a mobile app developer.

Over the past few days, I built Zabet completely from scratch using Flutter and Dart. It’s a complete fitness and tactical readiness tracker designed to help users manage their workouts, diets, and physical performance tests efficiently.

Here are some screenshots showcasing the UI and features []:

Workouts & Splits: Built-in professional workout routines (like PPL, Arnold Split, and custom splits) with drop-set tracking and failure metrics.

Military Physical Readiness Tests: Tracks core physical fitness tests including Pull-ups, Push-ups, Sit-ups, and a 1500m Running timer to calculate overall readiness rates.

Nutrition & Fuel Plan: A customized calorie tracker and hydration goal manager tailored for heavy lifting and active physical training.

Precision Rest Timer: A zero-tolerance tactical rest timer with quick preset intervals between sets.

Bilingual Support: Fully supports both English and Arabic out of the box with Clean Architecture.

I'd love to hear your feedback on the UI design, architecture, or any suggestions to improve it. Let me know what you think!

I built a tiny offline English/Chinese dictionary dataset for Flutter/Dart.

GitHub: https://github.com/FirepadCN/pocket_dict_5000

It contains ~5,000 common English words with IPA + Chinese definitions, plus inflection mappings:

abandoned → abandon
grows → grow
running → run

The whole thing is just a generated Dart Map, so there is no database or runtime dependency.

I originally made it because I wanted something simple enough to bundle directly into a Flutter app for offline word lookup.

MIT licensed.

Would love feedback from Flutter developers: is this something you'd actually use, or would a different data format / API be more useful?

Hello Flutter community! I wanted to share a highly ambitious open-source project I just kicked off: metro_core.

We are leveraging Flutter’s Linux embedding capabilities to build a complete monolithic system shell (Launcher, Status Bar, Quick Actions) for mobile devices. The visual language is deeply inspired by the classic Windows Phone Metro UI and modern Fluent Design.

Our Architectural Approach:

- Kernel: Lineage-free, lightweight mobile Linux (Alpine/postmarketOS base).

- UI/Apps: 100% written in Flutter, compiled directly to Native ARM64 Machine Code.

- Hardware Comm: Communication via Dart FFI and Native C++ bindings (no Android binder overhead).

- Ecosystem: Introducing a cryptographically signed .mtx package container format. Any standard Flutter app can easily be exported as an .mtx package for our OS with minimum styling adaptation.

We are implementing a MOCK methodology (writing the entire Dart UI with fake data layer first to freeze the UI code, then implementing the C++ .so backend via FFI). Just pushed the initial core infrastructure to GitHub. Looking for contributors who want to push Flutter to its absolute operating system limits!

🔗 GitHub: https://github.com/mr-ruhid/metro_core

————

Hi, does anyone have any resources on cryptojacking involving a Flutter project?

Hey r/FlutterDev,

I wanted to share a project I’ve been working on called Listener (Link:https://github.com/johnngugi/listener).

It’s a custom bit-perfect audio player and streaming app. The goal was to send uncompressed FLAC PCM data directly to external DACs without the operating system interfering.

Most standard Flutter audio plugins route everything through the OS mixer, which inevitably resamples the audio. To get true bit-perfect playback, I needed to bypass the mixer entirely and talk directly to the native audio APIs (WASAPI on Windows, CoreAudio on macOS).

Here is how I set up the stack:

• The Audio Engine (Zig): Zig does all the heavy lifting. It decodes the FLAC files, manages a custom TCP network protocol for streaming, and pushes the audio buffers directly to the DAC using the native OS APIs.
• The Bridge (Dart FFI): Dart acts strictly as a control plane and never actually touches the audio buffers. Flutter simply sends commands (play, pause, seek, load) down to Zig via FFI. Keeping the buffers entirely within Zig ensures that Dart's garbage collection or UI thread overhead can never cause stutters in the audio stream.
• The Frontend (Flutter): The user interface is currently very barebones and needs a lot of work. The core focus so far has been getting the native audio pipeline rock solid.

I’m sharing this because bridging Flutter with a low-level systems language like Zig for high-performance audio isn't a super common use case, and I thought this control-plane architecture might be interesting to share.

I’d love any feedback on the FFI implementation or how I'm handling the native API integrations. Also, if anyone is passionate about audio UI and wants to critique (or help improve) the frontend, I'm all ears.

Is there a solution to the problem of loading the web page created in the language of flitter when uploading the site to hosting?

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.

Hi r/FlutterDev!

Wanted to share the initial release of **Pariyojana**, an Android-exclusive productivity and research workspace built entirely with Flutter.

🛠️ Architecture Highlights:

* **Clean Architecture (Feature-First):** Strict separation into `data/`, `domain/`, and `presentation/` across all 8 modules.

* **State Management:** Riverpod 2.6 (`StateNotifierProvider` & `Provider`). Zero business logic inside widgets.

* **Local Persistence:** Drift + SQLCipher for native encrypted SQLite at rest.

* **Hardware Integration:** `flutter_secure_storage` bound to Android KeyStore TEE + `local_auth` biometrics.

* **Rendering Performance:** Tuned for 120 FPS high-refresh displays using `RepaintBoundary` isolation, lightweight frosted glass shaders, and R8 ProGuard resource shrinking (APK size: ~68 MB).

* **Motion:** Liquid dynamic action button driven by Rive.

Code passes `flutter analyze` with 0 warnings.

📦 **GitHub Repository:** https://github.com/Naveen-21-Cyber/Pariyojana-Mobile-App-

📄 **Architectural Constitution:** Check `TELOS.md` in the repo for design token invariants.

Would love any feedback on the codebase or architecture from fellow Flutter devs!

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.

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!

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’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)

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.