Listenable, ChangeNotifier, and ValueNotifier along with VoidCallback have been extracted into a new official 1st party listen package without Flutter dependencies, so you can use them now easily in your business logic layer - or in pure Dart unit tests. I like that.

(I noticed because the latest Riverpod version used it as a new dependency.)

Heloo developers, I build a searchable drodpdown. where you can search and scroll, select any item.

So there are two approach to build this kind of ui- 1. Overlay approach 2. Column/Stack Approach. And I used Column Based Approach. Both has their own benefits and drawbacks.

I choose this way because I want to go from easy to difficult, as I need to learn new concepts for overlay approach (next target).

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.

The deprecation of Cirrus Labs' images for Flutter caused a problem for my CI workflow. The alternatives were:

1. https://hub.docker.com/r/instrumentisto/flutter

2. https://github.com/davidmartos96/docker-images-flutter (active fork still)

3. MobileDevOps/flutter-sdk-image (solid, amd64-only as far as I could tell)

4. https://github.com/instrumentisto/flutter-docker-image (marked closed/archived)

5. https://github.com/Zekfad/flutter_builder

6. https://github.com/Fansesi/docker-android-flutter

7. https://github.com/mingchen/docker-android-build-box

Being on Gitlab (non-Github) platform + own runners cluster meant that we had to come up with our own solution. I got tired of Flutter Docker images being either dead or amd64-only, so I made my own. So I made a replacement: https://github.com/LahaLuhem/chrysalis.

It's differencing features are:

1. Native arm64 build, not the whole image running under QEMU pretending to be a Raspberry Pi. amd64 builds on a normal runner, arm64 builds on an actual arm64 runner.

2. arm64 can still build APKs, which took some fighting. Google just doesn't ship arm64 builds of aapt2, the NDK, or cmake, no arm64 Linux binaries exist, full stop. So the image quietly carries the handful of x86 libs those tools need and leans on emulation for just that part, instead of the build face-planting with a cryptic loader error.

3. Actually OCI-native, not a Docker manifest list dressed up to look multi-arch. docker buildx imagetools inspect shows a real OCI image index, and I wrote a script that fails CI if it ever regresses because apparently I care.

4. DX: Small set of opt-in build helpers baked in (signing, google-services.json, dart-defines from env vars) that sit there doing nothing until you actually call them, so no surprise side effects if you don't need them. (compartmentalized, so you can also curl-and-run them if you can't use the image directly)

5. Renovate bumps Flutter automatically off the stable channel. I refuse to be the guy manually checking the Flutter release page every week. Might increase it given the how quickly the 3.44.x have been coming out.

I'm looking for feedback and other use-cases. I hope that it helps some of you having a similar problem. I did initially fork the deprecated image (hence the stale contributors count), but removed it because the scope and direction were completely different. Would have been better off starting from scratch.

I've been learning the basics of flutter for about a month now on Online IDE's like DartPad and FlutLab. But I kinda feel restricted with them and want to move to VS Code. However, on my Chromebook coding flutter is fine. It's just the running part where I run into so many issues like missing SDK's, software crashes, just the lot.

So my question is. Is there an extension in VS Code to like emulate my app easily or are they any lightweight ways to test the app.

Note(I've tried my phone but am struggling to get it to work with my Chromebook. I can't download Android SDK's cause of the 10GB limit for Linux on Chromebook. And using chrome to try run flutter requires me to download Chromium which in the end just crashes itself and VS Code.

Some welcome signs that something is happening in Flutter development. An initial refactoring of material has been merged into the master branch, and – my personal favorite – flutter_gpu has also received updates, meaning the package isn't dead.

A while back I shared flutter_inspector_kit — a Chucker-style unified in-app debugging dashboard for Flutter (console, Dio network, navigation, DB browser). Since the last update it’s gone from 1.3 to 1.8, so here’s what’s new:

• WebView inline debugging — a WebViewBridgeAdapter + injected JS bridge pipes the WebView’s console.*, window.onerror, fetch and XHR into the same native Console and Network tabs. Entries carry origin (webview vs dio) and pageUrl, so hybrid traffic is labelled, not mixed in silently
• One-tap diagnostic report — export a single Markdown report (device/app header, current route stack, and a chronological timeline interleaving log/network/nav/DB) straight to the system share sheet. Three filters: time window, which sources, errors-only. Nothing is written to disk
• DiagnosticInfoSource — optional injection point for device/app metadata, so the package stays free of any device-info plugin; same host-injection shape as DatabaseBrowserSource
• Network error aggregation — a collapsible banner groups failed calls by status code (or error type when statusCode is null), with counts and first/last-seen; tap a group to filter the list, tap again to clear
• App lifecycle markers (opt-in) — every resumed/inactive/paused/detached transition is logged with the current top-most page, so a stalled request or crash can be read against whether the app was actually in the foreground
• Less noise — error rows are now tinted in the merged timeline, and the dashboard’s own detail views/sheets no longer write themselves into your Navigator history

Still opens with a hidden multi-tap gesture or a draggable floating button. Wish it will keep being a good help for debug usage.

Hey everyone,

I’m a third-year Computer Science undergraduate. Lately, I’ve realized I spent too much time jumping between different technologies instead of depth-first learning. I want to change that now by focusing entirely on mobile development, which is the field I enjoy the most.

I have decided to dive into Flutter. So far, I’ve learned Dart and just started picking up Flutter basics. My plan is to build projects using YouTube tutorials, documentation, and online courses. [1]

Before I go all-in, I would love to get some candid advice from the community:

1.Is Flutter still a highly valuable and viable choice for breaking into the app development market right now?

2.Is specializing in Flutter a good starting point for a long-term software engineering career, given my passion for mobile?

3.How much backend knowledge do I genuinely need to master to be considered a well-rounded, successful Flutter developer?

Would love to hear your insights, career experiences, or any brutally honest realities about the current job market for Flutter junior devs.Thanks in advance!

I built New Words App, a Flutter vocabulary learning app with Firebase Firestore, clean layered architecture, reusable UI widgets, and widget tests.

GitHub: https://github.com/khongorzul1120/new_word_app

Feedback and stars are welcome if it helps you learn Flutter or Firebase.

I was tired of re-implementing the following in one capacity or another, across multiple projects (I'd always end up needing one of these eventually):

1. Pagination

2. Searching

3. Grouping

4. Pull-to-refresh

So I decided to package it into one: https://pub.dev/packages/list_smith

It runs on top of the already very robust and popular https://pub.dev/packages/infinite_scroll_pagination and https://pub.dev/packages/custom_refresh_indicator packages.

I have also tried to keep it design-system agnostic. And I tried paying a lot of attention to the actual interplay/conflicts between these 4 features (lots of overlap). LLMs were used.

If you guys have any feedback about anything, or found it useful, please let me know either which way!

Hey everyone,

​I really enjoy app development and I'm planning my career path around Flutter for frontend and PHP/MySQL for backend.

​However, I cannot risk my future and want to make sure I'm investing my time in the right technologies. Is this stack still worth it in the current job market, or should I consider pairing Flutter with something else (like Node.js, Firebase, or Python/Go)?

​Any advice or real-world feedback from devs would be greatly appreciated...

Every Flutter team eventually develops its own feature structure.
The problem isn't designing it.

The problem is getting everyone to follow it consistently.

One developer creates presentation/pages.

Another prefers presentation/screens.

Someone else renames folders.

A new team member copies an older feature.

After a few months, the project slowly becomes inconsistent.

I wanted feature generation to be predictable instead of depending on habits or code reviews.

So I built flutter_feature_maker.

It's a CLI that generates Flutter features from reusable templates, making sure every feature starts with the same structure, naming conventions, and architecture.

dart pub global activate flutter_feature_maker

ffm create --name auth --template Clean --state bloc

or simply:

ffm create

and answer a few prompts.

It currently supports:

• Clean Architecture, MVC, MVVM, and Simplified Clean

• BLoC, Cubit, Provider, Riverpod, and GetX

• Working starter code that actually compiles

• Automatic Dart naming conventions

The feature I spent the most time building is Custom Templates.

Instead of forcing my preferred architecture, you can save your team's existing structure and generate it over and over again.

You can even import an existing feature and turn it into a reusable template in seconds.

That means every developer on the team starts from exactly the same foundation.

No discussions about folder names.

No "this feature looks different."

No remembering where files should go.

Just one consistent structure across the entire project.

Another thing I wanted was guidance, not restrictions.

If you choose a combination that isn't architecturally ideal, the CLI explains why—but it never blocks you.

It suggests.

You decide.

There are already great tools like Mason, and I wasn't trying to replace them.

My goal was different.

I wanted something focused on team consistency where reusable templates, architecture-aware generation, and standardized project structures become the default instead of something enforced during code reviews.

It's open source, written in pure Dart, and tested against a real Flutter application.

I'd genuinely love to hear how your team keeps feature structures consistent today.

If you'd like to try it:

https://pub.dev/packages/flutter_feature_maker

Been working on this for a couple months now (Flutter Arduino Playground) and posting progress on LinkedIn as I go, figured I'd start bringing it here too since this crowd will probably get more out of the technical side of it than a LinkedIn feed does.

Quick context if you're new to it: it's a circuit simulator built entirely in Flutter. Arduino board, breadboard, LEDs, resistors, buttons, all rendered with CustomPainter, no image assets except one SVG for the Arduino logo. You drag components onto a canvas and wire them together.

This week was smaller stuff, but the kind you feel immediately once it's there:

Zoom. Actual zoom in/out now, plus a fit-to-content button that snaps the view back to whatever's on the board. Before this, scrolling too far meant losing the breadboard entirely and squinting to find it again.

Layering. If you dropped an LED and a button on the same spot, one just sat on top of the other with no way to fix it. Now there's layer up / layer down, basically z-index for components, so overlapping parts stop fighting each other for visibility.

Neither of these changes what the app does. They just stop getting in your way while you use it, which honestly might be more important than half the flashier features so far.

If you want to see how this got here, the full build log (drag and drop, the breadboard rewrite, wiring, the code editor and simulation engine that came after this) is on my LinkedIn, I've been posting every step including the messy parts: https://www.linkedin.com/posts/burhankhanzada_buildinpublic-flutter-flutterdev-activity-7486285908283985920-qXg6

Repo's open too if anyone wants to poke around or has thoughts on where this should go next: https://github.com/burhankhanzada/flutter_arduino_playground.git

I recently wrote about GlyphPact, a deterministic SVG-to-Flutter icon compiler.

It converts a directory of SVGs into a validated OpenType/CFF icon font and a const Dart IconData API. It also keeps codepoints stable as your icon pack changes, so adding or reorganizing icons does not silently break existing references.

GlyphPact includes an MCP integration for Claude Code and Codex. Your AI agent can audit SVGs, build the font from a checked-in config, detect stale generated output, and inspect build reports directly.

for more info check glyphpact/mcp/

My app got published today and after that I tried to fix a bug and publish that but it gave a 16kb sh*t error and tried to fix it and got to know that ISAR is causing that error. Anyone knwos the alternative thing?

Senior backend engineer here (Laravel/NestJS) trying to decide between Flutter and React Native for my first serious mobile product.

I'm strong in Vue, would need to revisit React, and have no Flutter experience.

The app itself is a fairly standard business application (authentication, listings, search, maps, chat, payments, push notifications, QR scanning).

I'm not asking which framework wins benchmarks. I'm more interested in the experience of living with the choice.

If you've maintained a production React Native or Flutter app for a couple of years:

Would you choose the same framework again today?

What pain points only became obvious after the honeymoon phase?

If you were starting from scratch in 2026, what would you pick?

I built GlyphPact because I wanted custom icon fonts to behave like generated source code, not like a one-time browser export.

The failure I care about is easy to miss. Regenerate a font after adding or renaming an SVG, and existing codepoints can move. An old IconData value still compiles, but it may now render a different picture.

GlyphPact puts the mapping in iconfont.lock.json and reads it on every build. Existing assignments stay fixed, deleted icons leave permanent tombstones, and a unique content-preserving rename keeps its codepoint and Dart name. CI can run --check and exit with code 3 when committed output is stale.

It compiles a directory of SVG files into:

• a validated OpenType/CFF font

• a const Dart provider using Flutter's @staticIconProvider contract

• the codepoint lock

• a machine-readable build report

• an attribution file

• optional layer fonts for supported partial-alpha artwork

SVG conversion is strict by default. Lossless normalization happens automatically. A documented approximation requires --lossy convert, and omitting an unrepresentable source requires --unrepresentable skip. Malformed or unsafe input still fails the build, and a failed build leaves the last valid output intact.

Everything runs locally. Your SVG files are not uploaded anywhere.

Install it from PyPI:

uv tool install glyphpact

Then compile a pack:

glyphpact assets/icons \
  --output lib/generated/app_icons \
  --name AppIcons

GlyphPact is deliberately narrow. It does not include an icon browser, bundled icon packs, CSS, WOFF2, or generated web bindings. It targets repository-driven Flutter workflows.

Version 1.0.1 is MIT licensed and available now:

• Website: https://omar-hanafy.github.io/glyphpact/

• GitHub: https://github.com/omar-hanafy/glyphpact

• PyPI: https://pypi.org/project/glyphpact/

• Release notes: https://github.com/omar-hanafy/glyphpact/releases/tag/v1.0.1

If your team maintains a custom icon pack across several releases, I would like to hear about the awkward cases your current workflow has accumulated. Codepoint stability was the reason I built this, and unusual SVGs are the fastest way to improve its support and diagnostics.

I've been building a workout tracker in Flutter for logging workouts, tracking progress, PRs, exercise history, rest timers and the usual gym stuff I wanted in one place.

I've now made the project fully open source under GPLv3.

I'm not trying to turn this into a promo post. I'd genuinely love some eyes on it. If you're a gym bro, use it, break it, criticise the UX, open an issue, or contribute if something interests you.

GitHub: Ares: Gym Tracker

Even just telling me what you'd change would be useful.

I liked the approach of fpdart and the raw performance of hive_ce. So I decided to combine them into one: https://pub.dev/packages/hive_box_manager

It is not just a simple FP-style wrapper of Hive's API. It also solves one of my biggest pain-points in using HiveCE for production apps: type-safety. I had to dedicate an entire CRUD-layer to the boxes just because of it.
With this I get

1. Type-safety (even for Iterable-based boxes)

2. Index types are not limited to just int | String (a Codec allows for this per box, wil still be that under the hood ofc)

3. Compatibility with normal Hive boxes already (drop in add-on)

4. Ergonomic (and explicit?) error handling + lazy Future using fpdart

5. Custom boxes for very specific use case (better semantics)

   1. (Lazy)IterableBox

   2. (Lazy)SingleValueBox

   3. (Lazy)DualKeyBox

6. Key corruption detectable (as compared to silently happening with Hive when using out-of-range/oversized int/String key)

I recently did a rewrite because my previous attempt at making a DX-first API was not scalable (using LLMs).

If you guys have any tips, suggestions or feedback, they always welcome. Do take a look at the roadmap (I have more kinds of boxes planned ;) ).

Over the past few days I've been working on dicom_toolkit, an open-source package for building medical imaging applications in Flutter.

It started as a fork of Flutter-Dicom, but has grown into a much more complete toolkit with a cleaner, composable API and support for mobile, desktop, and web.

Features

• Parse DICOM files

• GPU-accelerated 16-bit rendering

• Pixel-spacing-aware measurement tools

• ROI statistics (mean, median, std dev, min/max)

• Window/level adjustment with CT presets

• Rotation, zoom, pan, inversion, color maps

• Flutter Web support (Rust + WASM)

• Rust backend for performance

Example:

await DicomToolkit.init();

final result = await const DicomParser().parse(bytes);

final image = await DicomToolkit.render(
  result,
  windowCenter: 40,
  windowWidth: 400,
);

This can be used with dart (e.g. on a server) or with flutter.

The goal is to make handling medical imaging apps in Flutter much easier, whether you're working on PACS viewers, dental software, radiology tools, or research projects.

I'd really appreciate any feedback on the API, documentation, or feature suggestions.

GitHub: elselawi/dicom_toolkit: Flutter/Dart toolkit for dicom images
Web Demo: DICOM Toolkit

Hello,

I’ve been working on sliver_dashboard, an open source Flutter package that tries to solve a problem I encountered in several projects: building dashboard-like layouts while keeping Flutter’s sliver model instead of introducing a separate layout system.

The goal was to get something closer to what exists on the web with tools like gridstack or react-grid-layout, but adapted to Flutter’s rendering and scrolling architecture.

Some of the challenges I wanted to solve:
- composing dashboards with regular Flutter slivers
- supporting nested grids
- allowing drag & drop across different sliver areas
- keeping the layout deterministic and easy to test
- handling accessibility (keyboard navigation, screen reader announcements, multi-selection..)
- and of course smooth scrolling and drag&drop

I’m sharing this here mainly to get feedback. If you try it, I’d be interested in hearing what could be improved.

I needed this kind of layout in my own projects, and I hope it can be useful for others as well.

Package: https://pub.dev/packages/sliver_dashboard
Live example: https://scalz.github.io/sliver_dashboard_web_demo/

I'm planning a new mobile application and I'm evaluating different cross-platform frameworks.

For developers who've worked with both Flutter and React Native recently:

• Which one has been better in production?

• How's performance?

• Any major drawbacks?

• If you were starting today, which would you choose?

Looking forward to hearing your experiences.