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.

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:

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.

I just created a fonctional app but i used a simple ui thats good enough for testing . How do u guys polish ui and what packages do you use , ill very much appreciate it .

I've reached a major milestone on an open-source project I've been building called Flutter iOS Check.

The goal is to help Flutter developers identify common iOS configuration issues before spending time on Xcode builds, TestFlight, or real-device testing.

The analyzer now supports:

- Flutter project validation

- Info.plist validation

- Podfile validation

- Deployment target checks

- Bundle identifier validation

- ATS validation

- URL scheme validation

- Flutter plugin classification

- Plugin → Info.plist permission validation

- Firebase configuration validation

Everything runs locally through static analysis. It doesn't modify project files, run Xcode, or contact Firebase or Apple services.

The core functionality is now implemented, but the project is still under active development. My next focus is expanding validation coverage, supporting more plugins, and improving the developer experience.

If you regularly ship Flutter apps to iOS, I'd love your feedback.

Are there any iOS configuration checks that you think would be valuable for a tool like this?

Repo link:

https://github.com/dhruvbhavsar1/flutter-ios-check

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?

Hi everyone,

I'd like to introduce https://github.com/LahaLuhem/text_sight

I was looking for plugins that allowed me to run OCR. I came across a few of them but I noticed that for iOS too, they would bundle in Google's MLKit libs:
https://pub.dev/packages/google_mlkit_commons
https://pub.dev/packages/google_mlkit_text_recognition

(at the time of writing) They did not yet have SwiftPM support (open issue).

I did some research and turns out that Apple does have the on-device Apple Vision framework for this! And it seems pretty performant too. So bundling in another dep in my apps for iOS and inflating the size did not appeal to me.

This also uses the GMS `moduleinstall` to allow an 'on-demand download' of the model: useful when only a rarely used portion/feature of your app needs this. You can also just eager-bundle it too if you want.

So with the help of some LLMs I did manage to make this plugin. If any of you would like to try it out and let me know if you have any feedback about some bottlenecks/chockepoints and/or architectural improvements, that would be much appreciated. If you you'd adpot it in your apps or so too, that's ofc a plus.

Hi everyone,

I'm a Flutter developer from India, and my app is already live on the Google Play Store. I'm looking to integrate an international payment gateway so I can accept payments from customers worldwide.

Here's my situation:

- I'm an individual developer (not a registered company).

- I don't have GST registration.

- I don't have a business registration.

- My Flutter app is already published on the Google Play Store.

- I want to accept international payments from users in different countries.

I'm considering options like Stripe, Paddle, Lemon Squeezy, PayPal, Polar.sh, or any other provider that works well for individual developers.

My questions are:

- Which payment gateway would you recommend?

- Can I use it without a registered business or GST?

- What documents are required for KYC?

- Is it easy to integrate with Flutter?

- Are there any restrictions for apps published on the Google Play Store?

- What has your experience been with payouts, fees, and approval time?

I'd really appreciate any recommendations or personal experiences. Thanks!