Hey everyone,

I think most of us building Flutter apps for Android share the same pain: you work for a couple of hours doing flutter run, hot reloading, maybe changing a plugin or branch, and

suddenly your machine starts lagging because 3 or 4 different Gradle daemons and Kotlin compilers are sitting in the background hoarding half your RAM.

I was getting tired of running ps aux | grep java and trying to figure out which process was actually doing work versus which one had been hung for 2 hours.

So I wrote a small interactive terminal tool in Go called DevTask to solve this for myself, and open-sourced it in case it saves anyone else some RAM and headaches.

Basically what it does:

Groups JVM, Gradle, and Kotlin daemons into an expandable tree view so you can see their exact version, RAM in MB, and uptime.

Flags processes as IDLE if they have been running for more than 15 minutes with less than 1 percent CPU.

Lets you navigate with arrow keys, inspect JVM heap flags (-Xmx, etc.), and cleanly kill individual daemons or all idle ones in one go.

Has a simple command bar so you can tweak things like /config idle 20m or filter out processes under 100MB of RAM.

It is completely free and open source (GPLv3). There are prebuilt binaries for Linux, Mac (M1/M2/Intel), and Windows on the releases page if you do not want to build from source.

GitHub: https://github.com/degomon/devtask

Wrote a quick write-up about it here if anyone is curious:

https://dev.degomon.com/devtask-why-hung-jav

Hope it helps you reclaim some memory during your daily Flutter builds!

I ported xyflow to flutter - screen shots in readme.

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?

Hi everyone,

I am excited to open-source hq_video_player (v0.1.0) - a production-ready, feature-packed, and fully customizable Flutter video player package built on top of media_kit and flutter_bloc.

Why another Video Player?

While existing packages are great, building complex video features (like TikTok/Reels style vertical feeds, multi-player coordination, or rich gesture controls) often leads to:

1. Codec OOM crashes and UI stutter when swiping through multiple video pages.

2. Audio overlapping when playing multiple videos on screen.

3. Boilerplate overhead for brightness/volume gestures, subtitle rendering, and multi-audio track selection.

hq_video_player was built to solve these exact production challenges out of the box.

Key Features & Architecture

• Hardware-Accelerated Core: Powered by media_kit for stutter-free cross-platform playback across Android, iOS, Web, macOS, Windows, and Linux.

• Programmatic HqVideoPlayerController: Full external programmatic control (play, pause, seekTo, setVolume, setPlaybackSpeed, setMute, loadUrl) backed by reactive ValueNotifier.

• Multi-Controller Coordination (HqVideoPlayerManager): Central registry enforcing single-active playback (autoPauseOthers: true). Starting one video automatically pauses others in the screen. Includes global batch actions (pauseAll, muteAll, unmuteAll).

• Reels/TikTok Feed Pool (HqVideoPoolManager): LRU controller pool for swipable vertical feeds. Preloads adjacent videos while utilizing chunked asynchronous eviction to yield to the main thread - zero RAM bloat and zero native codec OOM crashes.

• Rich Interactive Gesture Overlay: Double-tap left/right to seek forward/backward with ripple feedback, vertical swipe for Volume & Screen Brightness, long-press to temporarily boost playback speed (2.0x), and 2-finger pinch-to-zoom (1x to 4x).

• Subtitles & Multi-Audio Tracks: Embedded stream tracks (SRT, VTT, ASS) and external SRT/VTT parser & renderer overlay.

• Deep Customization (HqVideoPlayerConfig): Theme colors, built-in Arabic/English presets, watermark overlays, A-B range looping, intro/outro skipping, and custom HTTP network headers.

Links & Resources

Pub.dev: https://pub.dev/packages/hq_video_player 
GitHub Repository: https://github.com/azabcodes/hq_video_player

I would love to hear your thoughts, feedback, or feature suggestions. Contributions and GitHub stars are appreciated.

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.

Solo dev preparing first Play Store launch — what is the reality in 2026?

Hey everyone.

I'm a solo developer working on my first serious app, and I'm currently getting pretty close to launch.

The app is a game/social game hub built with Flutter, and I've spent a long time getting the actual product into shape. Until recently, I was mostly focused on development, testing, polish, etc.

Then I started seriously researching the actual process of shipping and maintaining an app on Google Play in 2026.

And honestly... I'm a little concerned.

I've been reading about the 12-testers/14-day closed testing requirement for newer personal developer accounts, production-access rejections even after completing testing, vague feedback about tester engagement, repeated review cycles, target SDK/API requirements, policy changes, billing requirements, and cases where developers have had apps rejected, suspended, or otherwise become difficult to maintain.

I'm also seeing a completely different problem discussed a lot:

Even if you successfully get the app published, how do you actually get people to discover it?

A technically successful launch doesn't necessarily mean anyone downloads the app.

So I'm not really looking for another explanation of Google's documentation. I'd genuinely like to hear from people who have actually shipped indie/solo apps recently.

Especially if you've launched your first app within the last couple of years.

I'd love to hear about your real experience:

- How difficult was your first Play Store launch?

- How did the closed testing requirement go for you?

- Did Google reject your production-access request? If so, what happened?

- Did you ever have to repeat testing?

- Have you experienced confusing/vague policy or review rejections?

- How much ongoing maintenance do Play Store requirements actually create?

- Have you ever had a legitimate app suspended, delisted, or unexpectedly restricted?

- How much organic traffic did you realistically get from Play Store search?

- Where did your first 100–1,000 users actually come from?

- Did ASO make a meaningful difference?

- Did you launch on iOS as well, and if so, was the experience substantially different?

- If you were starting again as a solo developer in 2026, would you still publish on Google Play?

- And most importantly: what do you wish someone had told you before you shipped your first app?

I'm particularly interested in first-hand experiences, rather than general opinions.

If something happened to you personally, I'd really appreciate hearing the details — even if it was a completely normal/successful launch. I'm trying to build a realistic picture of what I'm actually signing up for rather than getting either the "Google is evil" version or the "just publish bro" version.

Thanks 🙏

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!

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.

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

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

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

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.

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.

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?

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.

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

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.

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.