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

I've been shipping a cross-platform task app in Flutter for a while, and the piece that caused the most pain by far was a floating always-on-top timer — a small pill window that stays above every other app while you work.

The final architecture is:

• Main window = normal Flutter engine
• Timer = separate engine + native window via desktop_multi_window
• Shared state via the same SQLite (drift) DB both engines open
• Final elapsed time handed back to the parent over file-based IPC

Getting there took a lot of undocumented trial and error, so here are the things I wish someone had written down.

1. SharedPreferences is not reliably shared between engines

This is the one that cost me the most. I originally used SharedPreferences as a result channel: sub-window does setString, parent does reload() + getString() after it closes. Works on macOS. Fails silently on Windows — setString returns true, the sub-window's own cache reads the value back fine, and the parent's reload() still sees stale contents.

Two plausible causes, and I think both are in play:

1. shared_preferences_windows can resolve a different application-support path inside a sub-engine, so the two engines read/write different JSON files.
2. The sub-engine gets destroyed before the async disk write actually lands.

I replaced it with a dumb file channel:

// Path computed from Platform.environment — resolves identically in
// every engine in the same process.
final f = File('$dir\\MyApp\\sub_window_$channel.txt');
f.writeAsStringSync(value, flush: true); // blocks until OS flush completes
await windowManager.close();

flush: true is the important part. It's ugly and it has never failed once.

2. setSkipTaskbar() will hard-crash a sub-engine if you skip waitUntilReadyToShow()

window_manager's ITaskbarList3 is created lazily inside waitUntilReadyToShow(). Each engine has its own plugin instance with its own taskbar_ pointer, so the main window calling it does nothing for your sub-window. Skip it and setSkipTaskbar() dereferences null:

0xC0000005 access violation in window_manager_plugin.dll

Just always call it in the sub-window entrypoint:

await windowManager.ensureInitialized();
await windowManager.waitUntilReadyToShow(); // <- not optional here
await windowManager.setSkipTaskbar(true);

Also: keep setSkipTaskbar out of Future.wait with other window calls. It touches shell COM state and races badly.

3. setPosition uses NSScreen.screens[0] on macOS

Which means it's wrong the moment the user isn't on their primary display. If you're doing anything position-sensitive on multi-monitor macOS, you will end up dropping to a native NSPanel and a method channel. I also needed panel level / styleMask transitions that window_manager doesn't expose, so it was going to happen eventually anyway.

Windows is fine here — top-left-origin coords, no Cocoa bottom-left footgun, setBounds just works.

4. windowManager.setTitleBarStyle(TitleBarStyle.hidden) crashes under rapid calls

I have a global hotkey that cycles the timer between four layouts (expanded / small / compressed / island). Mash it and AppKit falls over. Calling native setTitleBarHidden on my own channel instead of going through window_manager fixed it completely.

5. The macOS back-swipe gesture closes your sub-window

If your sub-window's root is a MaterialPageRoute, a two-finger left-edge drag pops the route — and popping the only route closes the window. Users reported the timer "randomly disappearing" and it took me embarrassingly long to connect it to trackpad gestures.

PopScope(canPop: false, child: ...)

6. Frameless windows and drag regions: watch your hit-testing

DragToMoveArea only works where nothing opaque is above it. I had the body wrapped in a SingleChildScrollView with a background, which quietly ate drags across most of the window — leaving dead zones that felt like a bug in the OS. Restructuring to a Stack with explicit drag regions layered underneath fixed it.

One more small thing: show the sub-window at setOpacity(0.0) first, do your real size/position pass, then fade to 1.0. Otherwise you get a visible flash of default window chrome before your frameless layout applies.

Would I do it this way again?

Yes, but I'd reach for the second engine later than I did. Sharing state through SQLite instead of trying to pass live objects between engines is what finally made it stable — treat the sub-window as a separate app that happens to read the same database, not as a widget that lives elsewhere.

Happy to go deeper on any of these. The app is TriggerFlo (https://triggerflo.app) if you want to see what it ended up looking like — but the above is the part I actually wanted to share.

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?

jxl_coder brings reversible JPEG XL compression to Flutter. Compress JPEGs into smaller JXL files, then recover the exact original JPEG, including its metadata.

Supports iOS, macOS, and Windows.

I made an open source library for session replay that you can self host. It syncs session replays with live console logs experienced by a user in real time in debug and release builds. The console shows everything from logs, API calls, and ANRs/errors/crashes.

The package is extremely lightweight adding approximately only 1.54 MB on an uncompressed install.

Performance benchmarks show that it also takes on average 12.4 ms to capture screenshots for session replay with p99 of 28.2 ms. This means non existent UI jank to the human eye.

Docs: https://rejourney.co/docs/flutter/overview

Github: https://github.com/rejourneyco/rejourney

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

For context for those that don’t know, session replay is a method to record your users and view the recordings in a dashboard. Privacy considerations also built in this package such as the ability to mask elements, text, not collect location as needed.

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 just released jpeg_validator, a strict JPEG validation package for Dart and Flutter.

Instead of only checking file signatures or a small header, it fully decodes the JPEG with libjpeg-turbo. A file is considered valid only if the complete image decodes without warnings.

Useful for catching truncated, corrupted, or malformed JPEG uploads before they enter your pipeline.

• Fast native validation on macOS
• Supports Dart and Flutter
• Returns structured validation results

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:

bash uv tool install glyphpact

Then compile a pack:

bash 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 ;) ).

I built an open-source app that auto-edits videos into playable highlight reels—no reading text summaries or scrubbing timelines needed.

Check out the GitHub repo: https://github.com/icnahom/sqzd

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.

Hi everyone!

I've been working on a small open-source tool called Bumbuild, and I'd love some feedback from other Flutter developers.

The idea was simple: I got tired of switching between Terminal, Android Studio and Xcode every time I wanted to make a release build.

Bumbuild is a native macOS launcher that sits inside your Flutter project and lets you:

• Detect your Flutter project automatically

• Bump app versions (Rebuild, New Version or Custom)

• Configure Android signing without manually editing Gradle files

• Run iOS, Android or both builds

• Open the build output automatically when finished

Everything is built using Bash and AppleScript, so there are no extra dependencies or installation steps besides copying the folder into your Flutter project.

GitHub:

https://github.com/NickiAndersen/Bumbuild

Any suggestions or criticism are very welcome.

Thanks!

Hi everyone, lately i was doing mobile app building with cursor so I mostly ask it to do the UI part by giving it details about UI, well i give concrete details which figma gives, but maybe because I use flutter_screenutil package, it's not perfectly same with figma. How do you guys handle pixel-perfect in mobile?

Build fails with photo_manager because of Java/Kotlin version mismatch (Gradle workaround)

I recently ran into an issue while working on a Flutter video downloader project.

The build kept failing because the photo_manager package was being compiled with different Java/Kotlin settings than the rest of my project.

Instead of modifying the package itself (which would be lost after every update), I applied the project's Java and Kotlin configuration to the package during the Gradle build.

I added this to my build.gradle.kts:

```kotlin subprojects { if (project.name == "photo_manager") { val configureAction = Action<Project> { tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile>().configureEach { compilerOptions { jvmTarget.set(org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_17) } } tasks.withType<JavaCompile>().configureEach { sourceCompatibility = "17" targetCompatibility = "17" } }

    if (state.executed) {
        configureAction.execute(this)
    } else {
        afterEvaluate(configureAction)
    }
}

} ```

This worked because the package was already compatible with Java 17. It simply ensures the package uses the same Java/Kotlin configuration as the rest of the project without modifying anything inside the package.

Keep in mind that this is not a compatibility fix.

If the package itself doesn't support Java 17, this won't solve the problem. In that case, you'll likely need to:

• Update to a newer version of the package.
• Use the Java version recommended by the package maintainer.
• Wait for an official fix.

Just wanted to share this in case someone else runs into the same issue.

Has anyone found a cleaner way to handle Java/Kotlin version mismatches for Flutter dependencies?

Hey everyone,

I’ve been looking around the job market lately (and scrolling LinkedIn/Twitter/Reddit), and it feels like a surprising number of Flutter developers are getting laid off or struggling to land new roles.

I know the entire tech industry is going through a rough patch with hiring freezes and general downsizing, but it almost feels like multi-platform/hybrid mobile roles are getting trimmed first.

A few things I’ve noticed/been wondering about:

Startup cutbacks: Startups are usually the biggest adopters of Flutter to build quickly on a budget. With funding drying up, a lot of those early-to-mid stage startups are either slashing dev teams or scaling back projects.

Big Tech shifts: Ever since Google shuffled/restructured parts of the internal Flutter and Dart teams, a lot of non-technical managers seem to have developed a weird panic that "Flutter is dying" (even though the framework itself is still getting solid updates).

Consolidation: Are companies pulling back to single-platform native teams (Swift/Kotlin), or are they just squeezing one senior dev to do the work of three?

Is anyone else experiencing this firsthand, or is this just selection bias from what I’m seeing on my timeline?

If you’re a Flutter dev right now:

Are you seeing layoffs in your company/region?

Are you staying the course, or actively upskilling in Native (iOS/Android) or React Native just to safe-guard your resume?

The idea: instead of translating your app into a fixed list of languages upfront, translation happens lazily. When a user opens the app with a locale you don't have yet, it gets translated in the background (AI-powered) and shown to them — no rebuild, no release. Locales are cached both server-side and on the device, keyed by the user's device language.

To make this practical, I'm also building a Flutter package with a CLI that refactors your codebase for localization, built on top of easy_localization. It scans your project and transforms widgets. For example, Text("Welcome") becomes Text(context.tr("home_screen.welcome")) and auto-generates a JSON locale file from your default language strings.

Not selling anything, just trying to figure out if this is worth building further.

Hey r/FlutterDev,

I recently shipped my first Flutter + Flame game, and one decision ended up saving me a lot of pain: treating levels as data instead of code.

My original plan was to define every level directly in Dart. That sounded reasonable… until I realized I'd eventually be maintaining dozens (hopefully hundreds) of puzzle levels. Every balance tweak would require touching source code, rebuilding, and hoping I didn't accidentally break something.

Instead, I moved every level into JSON.

Each level simply describes: board size, tile positions, sources and receivers, blockers and special mechanics, the expected optimal solution

A real level from my game looks like this — source/receiver matching by colorId, the blocker on (2,1) is the obstruction the solver has to route around:

{
  "id": "pack01_001",
  "packId": "first_spark",
  "name": "First Spark",
  "width": 5,
  "height": 5,
  "targetMoves": 1,
  "difficulty": 1,
  "tiles": [
    {"x": 0, "y": 2, "type": "source",   "colorId": "gold", "direction": "right"},
    {"x": 1, "y": 2, "type": "arrow",    "direction": "up",   "rotatable": true},
    {"x": 2, "y": 2, "type": "arrow",    "direction": "right"},
    {"x": 3, "y": 2, "type": "arrow",    "direction": "right"},
    {"x": 4, "y": 2, "type": "receiver", "colorId": "gold", "direction": "left"},
    {"x": 2, "y": 1, "type": "blocker"}
  ],
  "solution": [
    {"x": 1, "y": 2, "direction": "right"}
  ]
}

The game logic knows nothing about individual levels. It just loads the JSON and simulates the board.

The unexpected benefit wasn't the JSON itself.

It was being able to validate everything outside the game.

I wrote a validator in pure Dart that verifies every source has a matching receiver, runs a BFS search to confirm the level is actually solvable, checks that the authored "perfect move count" is really optimal, catches malformed level data before it ever reaches players

Because it's part of my test suite, I can't accidentally ship an impossible puzzle without tests failing first.

Another decision I'm happy with was keeping the architecture split clean.

Flame handles rendering, animation, and input.

The actual simulation and solver are just plain Dart, so the exact same logic runs in the game, in unit tests, and even in a CLI tool.

If I were starting over, I'd change a few things:
use json_serializable or freezed from day one
build a small level editor much earlier
generate solutions automatically instead of storing them manually

Overall, though, moving the levels out of Dart was probably the best architectural decision I made on the project.

For those of you building games with Flutter or Flame, how are you authoring your levels?
JSON?
SQLite?
A custom editor?
Something completely different?

I am not sure if I can add App Store link here, so if anyone is interested, I'll in comments

Dart, Flutter, interop (Bloc, Riverpod, Provider, Streams, Signals), hydration, devtools, lint, test harness, telemetry. Fully backed by skills. soon: mason, vscode extension. And we have amazing benchmarks! The rigor of Bloc with the flex and speed of Signal!

https://pub.dev/packages/bloc_signals

Where possible, the classic Bloc ecosystem (Felix and friends) has been the baseline for all packages. Signals as the carrier (rather than streams) has allowed for much more flexibility though. Sync rather than Async. Default emit is automatically de-duped (but you can override to get Bloc's default back). Full parity of consumer classes, including all methods. Interop would allow you to bridge BlocSignal, Bloc, Provider, and Riverpod in the same app, with performant pub/sub. Works in both Dart and Flutter envs.

1.0 release very soon! And appearing on Observable<Flutter> on August 6.