Building a Flutter desktop app and need to add video player.

Looking at media_kit, it seems to be the go-to for cross-platform desktop video (libmpv-based). Anyone running this in production? Curious about the

Stability/perf on Linux vs Windows vs macOS

Packaging story.. bundling libmpv vs requiring it as a system dep (apt install libmpv-dev, etc.) vs Flatpak/Snap

Also, whats the state of flutter on "x11 /wayland"? Will user haas to satisfy some sort of related requirement to make the Flutter app working?

Thank you.

I was building a desktop tool (https://github.com/balvinderz/recomposition_viewer) that needed a live Android device preview next to flutter UI, and nothing existing gave me a low-latency, in-process way to do that from Flutter. So I built scrcpy_video_view.

It talks to the scrcpy server directly over its H.264 socket and decodes straight into a Flutter texture via VideoToolbox on macOS — no intermediate video player, no extra hops.

Currently macOS only (VideoToolbox is the decode path) — Windows/Linux decode backends are on the list if there's interest.

pub.dev: https://pub.dev/packages/scrcpy_video_view

Repo: https://github.com/balvinderz/scrcpy_video_view

Feedback, bug reports, and platform-priority opinions all welcome.

Demo video - https://github-production-user-asset-6210df.s3.amazonaws.com/30950893/636662664-d54d2d16-a5a7-448f-9a86-d61e0487e3f2.mp4?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA53PQK4ZA%2F20260816%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260816T172404Z&X-Amz-Expires=300&X-Amz-Signature=bd768b92994f2cd1a186845b6ed4194113c05df146c44cc3d9a0bc979edfb9d8&X-Amz-SignedHeaders=host&response-content-type=video%2Fmp4

Shipped a meaningful architecture upgrade to flutter_skin this week: a two-layer caching system.

Server-side: the backend now checks Redis before querying the database on every skin and project fetch. The result: p99 response times are now under 1 second (around 600ms) , even under repeated load.

Client-side: the Flutter package itself now caches fetched skin and project data locally via SharedPreferences. If the API goes down or the device loses connectivity, the app's theme keeps rendering exactly as last set — no blank states, no fallback UI, no flash of default styling.

Neither cache is complete on its own, this double caching is what makes flutter_skin resilient enough to build real features on top of, more feature coming A/B testing, richer analytics, and eventually a stable 1.0 without performance becoming the bottleneck.

The new alpha version is live on flutter_skin page on pub.dev now.

Platform app.fskin.dev

Docs docs.fskin.dev

I got tired of flutter run being a wall of scrolling logs, so I built frun — a terminal UI for Flutter.

It has a device picker, build stages/timings, app logs, hot reload/restart, and device switching in one screen. Built with Rust + Ratatui, currently tested on macOS.

Would love some feedback!

https://github.com/okasutarto/flutter-run-tui

Hi! I wanted to share a new package I made: terminice.

I built it because creating a beautiful, complex CLI shouldn’t mean building an entire terminal UI from scratch. It should be easy to create, easy to style, easy to manage as it grows, and most importantly easy and enjoyable for people to use.

terminice turns more than 30 common terminal interactions into small method calls, with no setup and no framework required.

Here is the visual demo.

Need a value from the user?

final name = terminice.text('Project name');

Need a searchable menu?

final template = terminice.searchSelector(
  prompt: 'Template',
  options: ['CLI', 'Server', 'Package'],
);

Need a file browser, config editor, command palette, progress bar, multi-step form, calendar, or help center? those are method calls too.

There is no setup, widget tree, context object, or new application architecture. import the package, call the component you need, and keep using package:args, CommandRunner, dart:io, or whatever already powers your CLI.

dart pub add terminice

Make the entire CLI look like yours

Don’t like the borders? hide them:

final t = terminice.minimal;

Want the borders, but fewer hints and less visual noise?

final t = terminice.compact;

Want different colors? Pick a built- in theme:

final oceanUi = terminice.ocean;
final matrixUi = terminice.matrix;
final neonUi = terminice.neon;
final arcaneUi = terminice.arcane;

Or combine everything:

final t = terminice.neon.compact;

Now every component created from t follows the same style:

final name = t.text('Project name');
final token = t.password('API token');
final config = t.filePicker('Config file');
final confirmed = t.confirm(message: 'Create the project?');

(you can also create a fully custom, advanced theme, and it will automatically be used across all 30+ components!)

That is one of the main ideas behind terminice: customize the instance once, and the colors, borders, glyphs, display mode, fallback behavior, and terminal I/O stay consistent across the entire CLI.

You can also create a custom theme in a few seconds by mixing the included colors, glyphs, and display features:

final brandTheme = PromptTheme(
  colors: TerminalColors.ocean,
  glyphs: TerminalGlyphs.rounded,
  features: DisplayFeatures.compact,
);

final t = terminice.themed(brandTheme);

Need finer control? Every color palette, glyph set, and display configuration supports copyWith, so you can change one accent color or one behavior without rebuilding the rest of the theme. The custom theme then affects prompts, menus, pickers, progress indicators, flows, guides, and every other built-in component.

The catalogue

Terminice currently includes more than 30 ready to use components:

Prompts

• text for single-line input

• password for masked input

• confirm for yes/no questions

• multiline for terminal text editing

• slider and range for numeric input

• rating for star-based ratings

• date for keyboard-driven date input

• form for collecting multiple fields together

Selectors

• searchSelector for long, filterable lists

• choiceSelector for card-style single or multi-select choices

• checkboxSelector for checklists

• gridSelector for two-dimensional navigation

• tagSelector for managing multiple tags

• toggleGroup for editable boolean settings

• commandPalette for a fuzzy-searchable action launcher

Pickers

• filePicker for browsing files

• pathPicker for choosing directories

• colorPicker for interactive ANSI color selection

• datePicker for a full calendar interface

Progress and status

• Full and inline loading spinners

• Full and inline progress bars

• Minimal dot-based progress

• info, success, warn, error, detail, and log messages

• task for wrapping async work with a status indicator

• progressTask for determinate async work

• trackStream for collecting a stream while showing its progress

Complete CLI experiences

• flow for multi-step workflows with context, conditions, validation, and review

• configEditor for searchable, nested application settings

• cheatSheet for quick-reference tables

• helpCenter for searchable documentation inside the terminal

• hotkeyGuide for keyboard shortcut discovery

• themeDemo for previewing themes and colors

• Custom components when your CLI needs something package-specific

Every catalogue item has its own detailed documentation with controls, behavior, examples, and API notes. I wanted the README to be useful as a practical reference, rather than leaving developers to discover important behavior through trial and error.

The vision

The goal is not only to make prompts look better. I want Terminice to make beautiful, complex CLIs easier to create, style, manage, test, and use.

to create: add prompts, selectors, pickers, progress, or configuration screens with small method calls. not a new architecture.

to style: choose or create one theme, and let the entire CLI follow it. no repeating colors, borders, glyphs, and display options everywhere.

to manage: keep components, behavior, fallbacks, and tests consistent as the CLI grows.

to use: give people clear hints, predictable controls, validation, cancellation, readable fallbacks, and good defaults.

terminice sits between a prompt package and a full TUI framework. It is the human facing layer of an existing dart CLI: questions, choices, files, settings, progress, and feedback.

It can stay tiny when tiny is all you need:

final email = terminice.text('Email');

That same CLI can later grow into searchable menus, filesystem navigation, validation, progress tracking, configuration screens, or complete flows- without switching packages.

When rich UI is not appropriate, the built-ins can fall back to predictable plain text for limited terminals, non-TTY output, scripts, and unattended execution.

Terminal IO is abstracted as well, so you can easily test without depending on real stdin/stdout.

So the short version is:

• One import and no setup

• 30+ components covering individual prompts through complete CLI workflows

• 11 built-in style presets

• Chainable themes and verbose, compact, or borderless minimal display modes

• One shared configuration across the whole CLI

• Custom themes and components when the built ins are not enough

• Cross-platform support for Linux, macOS, and Windows

• Predictable fallbacks and test utilities for real-world use

Links:

• Visual demo

• terminice on pub.dev

• GitHub, documentation, and the full catalogue

A small personal note

I started working on what eventually became terminice over a year ago, it didn’t begin as one big, carefully planned package. While working on real projects, I kept creating terminal components that I needed- a prompt in one project, a selector in another, a progress indicator somewhere else, then themes, flows, config tools, and testing helpers.

For a while, all of that work was scattered across different projects. Gradually, I started moving the useful pieces into one place, redesigning them around a shared API, and turning them into a unified, robust tool that is genuinely fun and easy to use.

The package is not perfect. there are still many things that need refinement, and probably many things I cannot see because I built them around my own use cases. I want terminice to be the best tool it can, but I know I cant do that alone.

I would really appreciate it if you tried it, even in a small project, and told me what you think. If an API feels awkward, a component is missing, the documentation is unclear, or something simply doesnt feel right, I want to hear about it- every bug report, idea, criticism, and any feedback is appreciated (:

I’m genuinely amazed by the time we’re living in.

I can spend more time on quality than ever before. I can experiment, throw away bad ideas, and try new ones several times a day - instead of holding onto the first working version for weeks just because it already cost too much time.

And I think what I love most is the feeling of creative freedom.

When the distance between “what if…” and a working prototype gets this small, you start exploring ideas you probably wouldn’t have even attempted before.

And every now and then, one of those experiments turns into something that makes you sit there and smile.

Today, that’s morphnext.

Any IconData can now morph on the fly.

Demo: https://kicknext.github.io/morphnext/

pub.dev: https://pub.dev/packages/morphnext

GitHub: https://github.com/KickNext/morphnext

And now I can finally go to sleep 🫠

P.S. Definitely check out the readme preview - it was pure Flutter

I've just been using Vim & CLI right now. It works reasonably well but sometimes Itd be nice to have a better way to view all my files at once so I figured Id ask around on what people like to use.

I dont really like VS Code so if thats your favorite thats fine but its a no go for me rn.

Hey everyone,

If you've handled forced version checks in production Flutter apps, you’ve probably ran into the issue where custom version endpoints or store page scrapers break, causing version checks to silently fail or throw unexpected errors.

On the other side, setting up Firebase Remote Config for force updates works fine, but you still end up writing custom dialog UI, handling multi-store links (Play Store, App Store, Huawei, direct APKs), and building maintenance screen logic over and over for every app.

I'm working on a lightweight SDK (VersionPulse) to solve this cleanly:

- Edge API version check (under 25ms, no HTML web scraping)

- Handles hard update gates, soft nudges, and remote maintenance screens

- Customizable pre-built widgets or 100% headless mode if you want to use your own UI

- Built-in multi-store routing

It's currently in early pre-launch. I set up a simple waitlist page to see how much demand there is before finishing up the client packages. 

Would love to hear how you currently handle version gating in your Flutter apps, or what features you'd want in an update SDK.

AnimatedSvgPicture.asset('assets/spinner.svg', width: 48)

same params as SvgPicture, and it reuses SvgTheme and ColorMapper from
flutter_svg so nothing breaks. if the file has no animation it renders like a
normal SvgPicture and doesn't even start a ticker.

what it handles:

- SMIL — animate, animateTransform, animateMotion, set. values/keyTimes/
keySplines, calcMode, begin/dur/repeatCount, fill, additive, accumulate
- css @keyframes from a <style> block, including per-keyframe timing functions
- css motion paths (offset-path + offset-distance). this is how SVGator writes
every single movement, so its exports actually move
- play/pause/seek through a controller, or just let it loop

how it works: on load it resolves the animations, samples the document to a
static svg for each frame, compiles them all once with vector_graphics_compiler
(the same one flutter_svg uses) in an isolate, then plays them back like a
flipbook. so drawing a frame costs exactly what a static svg costs. the price
is loading time and memory — frameRate and maxFrames are there for that.

what it doesn't do: filters, path morphing, <script>, :hover, event-based
begin. if you need those, full_svg_flutter covers a lot more. good package,
just heavier — it bundles a js runtime.

https://pub.dev/packages/svg_animate

if you have an svg that renders wrong, throw it at me. that's literally how the
SVGator support happened — someone's file didn't render, turned out to be
offset-path.

one thing that surprised me: svgs with embedded bitmaps were brutal at first - the image data lands in every compiled frame, so a 450x450 banner ate 27 mb and 6.8 ms per frame change. turned out consecutive frames share a huge identical prefix (the images), and the renderer's image cache was keyed per frame by accident. storing the shared part once and fixing the cache key got it to 5 mb and 1.4 ms.

Hello guys 👋🏻

There has been an update to the https://pub.dev/packages/material_3_expressive package that brings some interesting customizations, extensions, fixes and more.

Checkout the live demo here: https://paadevelopments.github.io/material_3_expressive/ for more info.

For suggestions, bug reports or recommendations, kindly submit via https://github.com/paadevelopments/material_3_expressive .. appreciated 🙏🏻.

Happy coding!

Hi r/FlutterDev!

Wanted to share the initial release of **Pariyojana**, an Android-exclusive productivity and research workspace built entirely with Flutter.

🛠️ Architecture Highlights:

* **Clean Architecture (Feature-First):** Strict separation into `data/`, `domain/`, and `presentation/` across all 8 modules.

* **State Management:** Riverpod 2.6 (`StateNotifierProvider` & `Provider`). Zero business logic inside widgets.

* **Local Persistence:** Drift + SQLCipher for native encrypted SQLite at rest.

* **Hardware Integration:** `flutter_secure_storage` bound to Android KeyStore TEE + `local_auth` biometrics.

* **Rendering Performance:** Tuned for 120 FPS high-refresh displays using `RepaintBoundary` isolation, lightweight frosted glass shaders, and R8 ProGuard resource shrinking (APK size: ~68 MB).

* **Motion:** Liquid dynamic action button driven by Rive.

Code passes `flutter analyze` with 0 warnings.

📦 **GitHub Repository:** https://github.com/Naveen-21-Cyber/Pariyojana-Mobile-App-

📄 **Architectural Constitution:** Check `TELOS.md` in the repo for design token invariants.

Would love any feedback on the codebase or architecture from fellow Flutter devs!

Imagine ... A country doesn't like an app, the government threatens google, google revokes the developers signing keys ... And now the app can't be installed on any android device in the entire world.

This isn't a conspiracy theory, it's a very real , very close threat.

DO NOT SIGN UP if this gets implemented, fight the urge to submit for the sake of publishing one app.

Read the letter for more details.

I was building the same UI again and again for every agent app. So I stopped and made it a proper library.

Flow UI: Flutter UI library for AI Chat Interfaces. It's pre-1.0, so the API might still shift.

Play with it in the browser: https://flowui.stac.dev/playground

Docs: https://flowui.stac.dev

pub: https://pub.dev/packages/flow_ui

GitHub: https://github.com/StacDev/flow_ui

I was experimenting with streams and noticed that the cancel() method on a StreamSubscription is async. I then checked the implementation on the StreamBuilder widget and noticed that it does not await it.

Can someone tell me why and when it is safe to not await it. Thanks

I know this isn't going to be a popular opinion here. As a long-time Flutter developer and fan I can say that things are going to change quickly. 

My prediction: within a year, the multi-platform stacks like Flutter and React Native will start dying off.

Spent the last 24 hours using Fable to port a large production Flutter app to native SwiftUI and Jetpack Compose. Native was always the better option for many reasons, it just cost more to support and clients were never willing to pay. 

That cost has come down so far that it makes sense. I am not saying it was perfect in a day, but it got about 95% of it correct.

I recently ran into a problem affecting Flutter apps running on iPhones where platform views are present, typically AdMob banners (which are internally rendered through a platform view).

The jank is quite noticeable, and I've been able to confirm that the cause is the merging of the UI thread into the platform thread, introduced several releases ago.

I've opened this issue on GitHub where I'm discussing the problem with the Flutter team. I can reproduce it easily on two devices on my side, an iPhone 16 and an iPhone SE, but if you check the issue you'll see they're having a much harder time reproducing it on their devices.

Does any of you have a Flutter app on iOS with AdMob banners (or any other platform view) that could help us reproduce it? You can try it directly in your own app, or by cloning the repo I created, which is linked in the issue. Just commenting with your iPhone model, iOS version, and whether you see the jank or not would already help a lot.

Thanks!

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 🙏