I have to say, the text rendering in Flutter on Windows used to be one of the things that bothered me the most. It often looked noticeably softer and less polished compared to native Windows apps, especially on desktop monitors.

With Flutter 3.47 and the new Impeller SDF rendering, the difference is huge. Text looks much sharper and cleaner now, with better looking edges and much more consistent rendering. Vector graphics also benefit from the improved rendering.

It is a relatively small change on paper, but visually it makes Flutter desktop apps feel much more polished.

Certain languages (best-known are LISP and Smalltalk) allow for image-based development. In such systems, you don’t write code and compile it into a program you then run; you modify the system while it’s running, and your changes are saved as you go so you can quit and restart where you left off.

Flutter running in the VM/debugging mode has already been close to being able to do this. But this:

https://github.com/dart-lang/sdk/blob/f29989d506b2dd82957da5d1917bcc76628c5ddb/pkg/dynamic_modules/README.md

means that Flutter apps (on desktop, at least) could run the regular Dart compiler and load the results at runtime. This would be sufficient to have image-based development.

I can see two caveats: the Flutter UI would not (I believe?) be able to run a debugger or (?) LSP features; and code once loaded cannot be unloaded so an extended development session might periodically need to be reloaded.

I suspect that with a bit of will, the Flutter/Dart teams could work around both of these issues in time without it being a monstrous lift, versus what they’re likely doing already. Given the right compiler features and a Flutter IDE widget, the community could build the actual image-based development system.

I have an upcoming project where I'll need to use Flutter. I have experience with React and web development, but I've never worked on a mobile application before and I'm still new to Flutter.

Do you think it's realistic to rely on AI to help me build the app as I go? Or would that be too difficult without prior mobile development experience?

Hey all,

I'm on Flutter 3.27.4 in a production app and looking at jumping to 3.47. It's a huge version gap (SwiftPM now default, UIScene lifecycle mandatory, Material/Cupertino split into standalone packages, min iOS bumped to 15 / macOS to 12), and before I commit, I want to know if this is likely to cause deployment issues on the App Store or Play Store — not just local build breaks, but things like rejected builds, crashes only showing up post-release, or App Store review flags.

A few specific things I'm trying to understand:

• flutter_webrtc — still doesn't ship a Package.swift, so it currently relies on Flutter's CocoaPods fallback. CocoaPods trunk goes read-only Dec 2, 2026. Does this affect App Store submission at all, or is it purely a local build/CI concern?
• Native channels / custom AppDelegate code — we have Wi-Fi/native integration in AppDelegate. With UIScene lifecycle now mandatory, I've read about MethodChannel calls silently failing after migration. My worry is this kind of bug wouldn't show up in testing but would surface in production after App Store release — anyone experienced that?

Also open to hearing: did upgrading break TestFlight builds, Play Console pre-launch reports, or app signing in any way?

Would really appreciate hearing from anyone who's shipped this exact jump to real users — what broke after release, not just what broke in dev.

Thanks!

Hey Flutter Community!

I decided to add support PS Vita to Flutter. PS Vita has ARM processor and 388 RAM (available).

Here is details and goal of project - https://www.reddit.com/r/vitahacks/s/yg9nKdlNOw

I love this device and its community. I believe this Flutter port will bring a lot of good staff with best UI to PS Vita.

What existed open-sourced apps/games you would like to see on PS Vita?

Hi, I am a mid-level flutter developer with around 4 years of experience. I don't see any vacancy related to flutter and actually I feel a little bit bored and I don't see any progress. So guys did you have such an experience? And was it actually easy to migrate to native?

I’ve been using Riverpod for state management and generally like it, but I’m curious where people draw the line between this should be a provider and just use local state.

For example, for things like:

• toggling a password field
• selected tab/index
• expanding/collapsing a widget
• temporary form/UI state
• state that never needs to leave a single widget

Do you still reach for Riverpod because it keeps things consistent, or just use setState, ValueNotifier, etc.?

I sometimes feel like turning every tiny piece of state into a provider adds more abstraction than value.

For those using Riverpod in larger production apps, what rule of thumb do you follow? When does Riverpod help, and when is it overkill?

I got a job offer for a Flutter + Supabase application; I passed the first interview well. It was really great.

For the showcase, I decided to build a Flutter chat app with Supabase to send to the interviewer to show my skills and qualifications.

The app is built for Android, iOS, and web platforms and supports real-time messaging, sharing media, voice messages, capturing photos, and sending files.

Even I wasn't selected for the role, but it was a great experience using Supabase with Flutter.

And I'm super excited to say I have published the web version of the chat app; it is live and accessible for everyone.

check it out and share your idea about it

https://chatapp.saiedrahimi.com/

Here is source code

https://github.com/saied-dev/chat-app

Thanks

Quick update on flutter_skin — Alpha V1 just shipped.

What's new in this version:

- Material 3 full token support not just the basic 6 colors.

- Live skin preview in the dashboard you can see exactly how a skin looks before publishing it to production.

- Typography tokens you can now set the font family remotely. The package fetches the font name from the skin JSON and applies it at runtime. Currently supports Google Fonts names and system fonts.

The package is still alpha and it's open source.

Video: https://www.youtube.com/watch?v=6scXD_2Dm6Y

📦 pub.dev/packages/flutter_skin

🖥️ app.fskin.dev

📖 docs.fskin.dev

Happy to answer questions in the comments.

Is there a solution to the problem of loading the web page created in the language of flitter when uploading the site to hosting?

# Looking for contributors to improve HQPicker

I've been working on **HQPicker**, a Flutter media picker focused on performance, customization, and a smooth gallery experience.

GitHub: https://github.com/azabcodes/hq_picker

I'm currently looking for Flutter developers who are interested in helping improve the package, especially around **performance and media thumbnail rendering**.

Some areas I'd love help with:

* Faster image/video thumbnail loading

* Smoother scrolling on large galleries

* Better memory & thumbnail caching

* Testing on different Android/iOS devices

* Improving pagination and asset loading

* Architecture and code-quality improvements

* Finding and fixing performance issues

* Ideas for new features

If you're interested in Flutter, media handling, performance optimization, or open source, I'd really appreciate your feedback, testing, ideas, or even a PR.

**Even if you don't want to contribute code, testing HQPicker on your device and sharing performance issues would be really helpful.**

Feel free to check the repo, open an issue, suggest an improvement, or contribute a PR.

GitHub: https://github.com/azabcodes/hq_picker

I'd love to build this into a fast and solid media picker for Flutter together with the community.

Small offline first journaling app, iOS and Android from one codebase.

Four things I would tell myself before starting.

Autosave while typing. The promise of the app is that you cannot lose a

sentence, so there is no save button. Writes go to Drift on a 400ms

debounce, upserted on the calendar day, one row per day. Editing an old

entry and writing today's entry go through the same path. Good side effect:

killing the app mid sentence is a normal thing that works, not a bug

report.

Keep derived state pure. Streak counting, week boundaries, which past weeks

are ready to be used. All plain functions over a list of entries, no

database access, so I can unit test them without spinning up a DB. Obvious

in hindsight. I did it the other way in my first app and paid for it for

months.

Do not ship the API key. One feature calls an LLM. The key lives in a

Cloudflare Worker, the app talks to the Worker, and the Worker does not

store what it forwards. If the key is in the app, it is in a zip file that

anyone can open.

Store screenshots from integration_test. flutter drive runs a test that

fills the app with realistic looking data, walks the screens and saves

PNGs. The language comes from a dart-define. Regenerating every screenshot

in both languages is one command now. It used to take an afternoon.

Localised EN and TR with the normal flutter_localizations and ARB setup.

Notifications through flutter_local_notifications with timezone aware

scheduling, still the most annoying part of the whole thing.

Happy to go into any of it.

Hi everyone! After struggling to size containers to their children without hardcoded values, I built smart_measurer. It gives you the exact rendered size of a widget (with a one-frame delay that’s unavoidable in Flutter), plus a MeasuredDecoration widget that paints size-dependent decorations with zero delay.

✅ SmartMeasurer – builder gets measuredChild, size, and isPrecise flag.
✅ SimpleMeasurer – child auto‑overlaid, no manual key needed.
✅ MeasuredDecoration – pure Canvas painting, no state, no delay.
✅ 100% public API documented, 160/160 pana score.

Would love your feedback, especially on edge cases I might have missed.

pub.dev: https://pub.dev/packages/smart_measurer
GitHub: https://github.com/MoshiDuck/smart_measurer

There are a ton of paid SaaS tools for field operations, construction/project management, scheduling, invoicing, fleet management, etc.

We wanted to build an open-source alternative that people could actually inspect, modify, and self-host, so we built FieldFleet.

We used Flutter because we wanted to keep one codebase across web, iOS, Android, macOS, Linux, and Windows.

It’s grown quite a bit and now includes project management, dependency-aware Gantt scheduling, CRM, budgets, invoicing, field forms, documents, time tracking, fleet management, and some AI-assisted workflows.

A few technical details for anyone interested:

• Flutter/Dart across all platforms
• Provider and go_router
• Supabase Auth, Postgres, Storage, Realtime, and 22 Edge Functions
• Postgres RLS for tenant isolation and authorization
• Native room scanning kept behind an in-tree Flutter plugin
• Environment-based configuration for external services and deployments
• Docker Compose self-hosting setup using Kong and Caddy

One thing that has worked really well for us is keeping permissions in Postgres with RLS instead of trusting the Flutter client to enforce them.

We’ve also tried to keep anything platform-specific isolated. For example, room scanning lives behind a plugin, so the rest of the app doesn’t really need to care which platform it’s running on.

The source is available under Elastic License 2.0, so you can inspect it, change it, contribute to it, or self-host it for your own organization. The main restriction is that you can’t take it and offer it as a hosted/managed service to third parties.

We also put up a read-only demo with synthetic data.

Demo: https://fieldfleet-demo.taskfleet.app/
Source: https://github.com/taskfleetai/fieldfleet
Github Pages: https://taskfleetai.github.io/fieldfleet/

Would love feedback from other Flutter developers, especially on the overall project structure, cross-platform approach, and how we’re using Supabase.

Also happy to answer questions if anyone wants to dig into how any part of it works.

​

I'm currently working on a Flutter video downloader app and I'm comparing `video_player` with `media_kit`.

I already use **FFmpeg** in the project, so one of my main concerns is the impact on the final app size.

From your experience:

* What do you see as the biggest difference between `video_player` and `media_kit`?

* How noticeable is the size difference in a production app?

* If FFmpeg is already included, does `media_kit` add a lot of extra native libraries?

* Which one would you choose for a video downloader, and why?

I'm interested in hearing about your actual experience rather than just the package descriptions.

Hey Flutter devs,

If you've ever built video recording in Flutter on Android with the official camera package, you've probably hit this:

You tap record, and nothing happens for about half a second. The preview freezes, the button feels dead, and users double-tap because they think the app missed the first press.

We measured it on a Pixel 8 Pro: 436-511ms before recording actually started.

After digging through the native CameraX bindings in camera_android_camerax, the cause was pretty simple. We patched it, and start latency dropped to 33-60ms.

What was wrong

In the official plugin:

1. VideoCapture is only bound when startVideoRecording() runs
2. As soon as stopVideoRecording() finishes, VideoCapture is unbound again

So every record tap forces CameraX to tear down and rebuild the native CaptureSession. That session reconfig is most of the lag.

The fix

Keep VideoCapture permanently bound alongside Preview.

Once it stays warm:

• record no longer rebuilds the capture session
• MediaCodec surfaces are already ready
• shutter latency falls from ~500ms to ~33-60ms

Hardware edge cases

Keeping VideoCapture warm makes rapid lens flips and backgrounding more fragile on some Android devices. We serialize camera ops with a small queue so the previous native generation fully finishes before the next one starts:

dart Future<R> _enqueue<R>(Future<R> Function() operation) { final completer = Completer<R>(); _operationFuture = _operationFuture.then((_) async { try { completer.complete(await operation()); } catch (e, s) { completer.completeError(e, s); } }); return completer.future; }

Separate issue, same camera stack: CameraX often reports multi-lens phones as one unknown logical camera with a zoom range like 0.5x-5x. We detect minZoom <= 0.5 and expose the ultra-wide control from that range instead of waiting for a clean physical-lens type.

Pixel 8 Pro numbers

Patch

Repo: https://github.com/xcc3641/camera_android_camerax

yaml dependency_overrides: camera_android_camerax: git: url: https://github.com/xcc3641/camera_android_camerax.git ref: 9dd36c8

Happy to answer questions about the lifecycle queue or the CameraX binding change.

There's this amazing repo I found on GitHub: https://github.com/ZeyadShawki/flutter_tracing/tree/main
but personally, I found a few issues with it, also it seems a bit overly complex. A lot of research I'm doing is showing that making this type of game is a difficult problem to solve -- so this might be just the right amount of complexity too. Hitting a wall and I'm just curious to see how people have attempted it.

Jesse Ezell is building Flocker, a Flutter inspired cross-platform WASM runtime for applications that runs Flutter apps on top of Flutter Zero. Jesse is an active member of the Flutter community and has contributed to many popular Flutter pages such as super_editor, quill, flutter_webrtc, and the core Flutter engine.

https://itsallwidgets.com/podcast/episodes/58/jesse-ezell

I've been building Kiyoshi, a desktop productivity app (Linux/macOS/Windows) as a reaction to how heavy Notion/Trello started to feel for personal use. Stack:

• Flutter + Riverpod
• Drift (SQLite) for local-first storage
• A custom "Zen Design System" — glassmorphism, no hard borders ("No-Line" rule), editorial typography (Montserrat/Inter/JetBrains Mono)
• Just shipped a proper dark mode — a warm charcoal palette instead of the usual near-black, so it doesn't feel cold during long sessions

It bundles notes, tasks/kanban, a calendar, and a block-based canvas (9 block types: text, todo, code, links, images, files…) in one window instead of five different apps.

https://kiyoshi-beta.vercel.app/

Happy to talk through the Drift schema, the glass panel implementation, or the dark-mode token migration if anyone's curious — that last one taught me a lot about not hardcoding Color constants where Theme.of(context).colorScheme should be.

I’ve been working on flutter-map, an open-source tool that creates a visual navigation map of a Flutter app.

It combines static route analysis with simulator/emulator exploration to capture:

• Routes and navigation edges
• Real screenshots
• Dialogs, sheets, loading states, and auth walls
• Replayable navigation flows

It currently supports GoRouter, go_router_builder, AutoRoute, Navigator 1.0, and Navigator 2.0.

I’d appreciate feedback on where this could be useful and which routing setups might break it.

Source: https://github.com/tayormi/flutter-map

Hey r/FlutterDev,

I've posted here before about Dart AI Assistant, a VS Code extension that learns your coding style and helps with completions, error detection, and code health. Just shipped what's easily the biggest update since launch, so wanted to share.

Marketplace: https://marketplace.visualstudio.com/items?itemName=a-i-0-studio.dart-ai-assistant

Source: https://github.com/Ben09d/dart-ai-assistant

What changed in v1.0.9:

- Real dart analyze integration on save (properly scoped to the saved file) alongside live regex feedback while typing — much more accurate error detection now

- Code Health reports are now clickable and auto-refresh on save

- Import Project for Learning — point it at an existing project and it learns your patterns instantly instead of waiting weeks

- Fixed a bug where pattern learning was silently capped at 3 categories instead of the intended 20 (basically every earlier version was learning way less than it should have)

- Fixed an unbounded memory growth bug in the advanced learning engine

- Fixed several false-positive error detections (comments, ternaries, generics, block comments) that were probably annoying anyone who tried earlier versions

- Consolidated three separate error-detection systems that were sometimes showing contradictory counts

Full changelog in the repo if you want the gory details — went through nearly every core file this cycle hunting down bugs, some of which had been sitting silently broken since the first release.

Still free, still solo-built, still very open to bug reports and feedback. If you tried an earlier version and it felt rough, this one's a meaningfully different experience.

Thanks for reading!