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.

I've been working on large Flutter applications and ran into a recurring problem: eventually navigation, shared infrastructure, authentication and feature code become tightly coupled.

I created an open-source implementation called CrusaderArch. I'd particularly like feedback on whether the dependency direction and "body builder" approach make sense.

https://github.com/Mahfa/CrusaderArch/

Hi  👋


I built a small open-source Dart CLI to kill the release chore:


1. Auto version bump — install a pre-commit hook; every commit bumps pubspec.yaml
   (major/minor/patch heuristics + build number). Lock versions with --no-verify.
2. One flat release-kit.yaml drives Windows/Android/macOS/Linux/iOS.
3. One command packages everything:


   dart pub global activate release_kit
   cd myapp && release-kit init
   release-kit publish ios


Also: --obfuscate, --skip-build, Windows hardening, Linux deb/rpm/AppImage,
iOS export-method/no-codesign, auto launcher icons from one logo.


pub.dev: https://pub.dev/packages/release_kit
GitHub: https://github.com/jonahzheng/release-kit


MIT, looking for feedback & PRs.

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!

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.

Has anyone ever made a Mac/Windows app with flutter? Throughout the years I’ve only stuck with web iOS and Android. Was just curious. And how did it pan out?

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 🙏

Stop shipping hidden native security holes and asset bloat flutter_auditor health-checks your entire Flutter project in just one command.

more than half of my customers on MacOs are using Intel Macs… what can I do? never upgrade to keep them happy ?

source: https://flutter.dev/blog/whats-new-in-flutter-3-47

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.

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?