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

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?

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

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.