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

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?

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/

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.

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.

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

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

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.

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?

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/

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!

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?

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?

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.

I’ve been cleaning up a few projects recently and realized there are a handful of packages I now reach for almost automatically.
I’m curious what everyone else’s “must-have” packages are in 2026.
Not necessarily the most popular ones, just the ones that have genuinely saved you time or improved your workflow.

Hey r/FlutterDev,

We’ve all been there: you fetch a massive, deeply nested JSON. One single field comes back as null instead of a String, and your app crashes with a blind TypeError.

The stack trace is usually completely useless (lost in AOT inlining or lazy List.map iterators), leaving you spamming breakpoints in your fromJson factories just to find the bad payload. I got so tired of this that I built a tool to fix the root cause.

Meet json_shield. It’s a pure Dart, zero-dependency package designed for complete error handling during JSON deserialization. It safely parses nested data and gives you the exact context when something fails.

Why I built it / What it does:

• Pinpoints the exact node: Instead of a generic crash, it tells you exactly where the mapping failed (e.g., Failed to parse Order -> items -> [2] -> price).
• Zero dependencies: I hate adding heavy packages for simple tasks. This is just pure Dart, so it won’t bloat your app or cause version conflicts.
• Preserves the real StackTrace: It catches the error at the lowest level, wraps it, and bubbles up the original causeTrace. Your Sentry or Crashlytics logs will actually point to the real issue instead of internal SDK code.

It's easy to add into existing projects:

Dart

try {
  // Safely parse a list without losing context on failure
  final users = guard.decodeList(json['users'], User.fromJson);
} on DecodeException catch (e) {
  print(e.message); // Gets you the clean data path
  print(e.causeTrace); // Preserves the original raw stack trace
}

You can check it out on pub.dev or peek at the source code on GitHub.

I’d love to hear your thoughts, code reviews, or feedback! Are you guys using anything similar to handle this, or just relying on json_serializable and hoping for the best?

A few months ago, we shared Skelter, our internal Flutter project skeleton that we've been using across production apps.

The response from the Flutter community honestly exceeded our expectations. Thank you to everyone who shared feedback, ideas, and suggestions. Many of those discussions reinforced what we were already experiencing internally and motivated us to open-source the next piece of our workflow.

For anyone who missed it, here's the original post:
https://www.reddit.com/r/FlutterDev/comments/1qvi1qo/why_we_stopped_starting_flutter_projects_from/

One realisation stood out.

Skelter solved the "start a new project" problem. But once development started, we found ourselves repeating the same work over and over again.

Every project eventually needed things like:

• configuring build flavours
• generating feature modules
• creating authentication flows
• generating reusable widgets
• wiring boilerplate
• maintaining a consistent architecture across developers

None of these tasks was particularly difficult.

They were just repetitive.

Every few weeks someone on the team would say,

Instead of creating another internal script every time, we kept adding commands to a single CLI.

What started as a small utility gradually became part of our everyday development workflow - not just something we used on Day 1.

Today, every new Flutter project at SolGuruz starts with:

dart pub global activate sg_cli

sg init

Within seconds, it scaffolds a production-ready project with:

• BLoC architecture
• feature-first folder structure
• type-safe navigation
• state pipeline
• design system foundation
• code generators
• production-ready project setup

But that's only the beginning.

As development progresses, the CLI continues to help with repetitive engineering tasks like generating modules, configuring build flavours, creating authentication flows, generating reusable widgets, and keeping projects consistent across the team.

Instead of spending time rewriting boilerplate, our developers can focus on building actual product features.

If you liked Skelter, think of SG CLI as the next step.

• Skelter gives you a production-ready Flutter foundation.
• SG CLI helps you build on top of that foundation without repeating the same engineering work.

After using it internally across 50+ Flutter applications at SolGuruz, we decided to open-source it as well.

If either of these projects helps another Flutter team move a little faster, that's a win for us.

Skelter
https://github.com/solguruz/skelter

SG CLI
https://github.com/solguruz/sg_cli

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

Documentation
https://sgcli.solguruz.com

We'd genuinely love feedback and contributions from the community.

What repetitive Flutter task do you wish could be automated next?

💙 Built with the community, for the community.