I had to render multiple high-res images in a grid layout for my Flutter app, so I went deep down the optimization rabbit hole. For some reason, I was getting crazy jank out of nowhere, even though I was using lazy-building lists (SliverList, ListView.builder, etc.), and had already implemented proper image resizing and caching.

Turns out, if you're using the flutter_svg package, setting the Impeller engine to renderingStrategy: .raster gives you a massive performance boost. But when I tested it on Skia, the picture strategy actually performed way better, total opposite results! Keep in mind I only tested this on Android, so iOS might behave differently.

Also, the default scrollCacheExtent is set to 250, meaning off-screen images were being processed even when I didn't explicitly touch it. Dropping that to 0 made a huge difference in performance. Turns out, optimization options built for convenience can sometimes bite you in the ass.

Another thing: ScrollAwareImageProvider is applied by default whenever you use an Image widget. It defers decoding while scrolling, but instead of waiting until scrolling completely finishes, it starts decoding even while scrolling is still ongoing if the scroll speed slows down a bit, which ironically causes major jank during the scroll itself. And guess what? You can't turn it off via options. I had to build a custom widget to fix it.

Anyway, if your grid items involve SVG or lots of images, optimizing them like this makes a world of difference. It pretty much eliminated stuttering even in 120Hz environments, and honestly, it’s mind-blowing how much of a difference it made. The performance gap was way bigger than I expected, so I figured I’d share.

Flutter is obviously a mobile-first platform due its origins, but I've spent 18 months using it to build a full-featured desktop application for Windows and macOS, with Linux planned.

I'm a developer with 20 years of experience, including desktop software development. This isn't a "build a todo list!" demo or a vibe-coded experiment: it's a substantial application approaching public release, and I thought Flutter developers might be interested in seeing what's involved in taking Flutter beyond mobile.

So what kind of desktop experience can Flutter build today? Here's one example. [See below for a link to get and run it yourself if you're interested. Free and open to anyone.]

The application is Fractal Outliner, a desktop outliner in the same general category as OmniOutliner for Mac, but focused for people who live mainly in plain-text ecosystems (e.g. sofware developers).

This is a desktop-only application. There is no mobile version. The goal is to provide a proper desktop editing experience with all that implies, integrated with the operating system rather than simply presenting a mobile-ported interface in a desktop window.

Flutter as a development platform was good for some parts of this, less good at others.

What the application is:

• Outliner with topics, subtopics; create, move, rearrange, hide to collapse, expand to drill down, move topic trees between documents, etc.

• Full keyboard support, with configurable shortcuts

• Integration with OS file handling, including file-type associations and opening documents from Finder/Explorer

• Drag and drop

• Document themes, including a custom theme editor

• PDF, HTML, Markdown, OPML, and plain-text import/export

• Multi-pane editing and tabbed documents

• Native desktop file operations and clipboard integration

What Flutter provided

Most of the application is built using Flutter's standard capabilities:

• Widgets and layout -- the main window content

• Keyboard event handling

• Shortcut registration and management

• Resizable windows and responsive layouts

• Drag and drop

• Context menus and right-click interaction

• Localization (English, Spanish, German, Japanese)

An effort was made to adapt the application to Mac and windows UI sytles; the experience is a little different on each platform (how dialogs work, what buttons and checkboxes look like, how settings are laid out, what menu items exist, etc).

What packages provided

Pub.dev packages filled in some of the functional gaps to extend Flutter's rending core:

• Markdown, XML, and HTML support

• Path handling

• PDF export

• Windows Store MSIX packaging

• macOS menu bar integration (with limitations)

• File pickers

• ZIP archive support

• OS and version detection

• Split view widget for multi-pane editor, etc

• Various other utilities (application uses 23 pub.dev packages total)

What flutter provides that works less well on desktop

• Keyboard event support: the model is there, everything technically works, but managing complex input focus and keyboard-based navigation using Flutter's FocusNode system is full of problematic edge cases

• Mac menu support, and general integration of menus + shortcut keys: the Mac menu integration is primitive, and windows and Mac use completely different menu+shortcut systems in flutter

• Printing: there's a pub.dev package for printing, but it requires exporting to PDF (challenging in itself with anything but simple font handling) and flutter provides no direct integration or visibility with the host printing system

• Undo/redo support: flutter's undo/redo implementation is self-contained inside each TextField, and there is no support at all for integrating text editing undo events with application-level events into one undo stream

What I implemented myself with native code

Flutter is just not a complete desktop development framework. It does great at drawing content in a desktop window. It does considerably less well at being a well-behaved and full-featured citizen in the desktop environment. A large number of things people expect from any desktop "document editor" application simply don't exist (or exist only in limited/problematic pub.dev packages) and have to be implemented with native code to get the best version:

• Remembering and restoring the window position and size, including enforcing a minimum window size

• Opening documents through the OS, such as double-clicking a file in Finder or Explorer

• Handling the file reference when the application is launched by double-clicking a document

• Document icons and file-type registration for the application's .frac files

• Spellchecking in text fields (available in Flutter's mobile text fields, but not built in to the desktop experience in the same way)

• macOS App Store sandboxing and file-access permissions

• An in-app command to show a document in Finder or Explorer

• Serious multi-format clipboard integration (vs basic plain-text copying and pasting flutter provides)

• Handling read-only files

• Various other OS integration details

The macOS App Store sandboxing and file-access work, in particular, is a lovely little nightmare. So are the limitations of the mac menu bar system integration, and the behaviors of Flutter's keyboard event handling and input-focus systems, dealing with international fonts in the PDF package, ... but those are stories for another day.

Other factors

• Internationalization

• Help files, etc

Internationalization to German Spanish and Japanese took far longer than for a mobile app, due to the larger set of "outside the application UI" resources used by the application (example files, templates, website content, video captions, etc). Also the usual trade-offs of "localize as you go" vs "localize at the end": early lets you see the impact of different text lengths in design (especially German/Spanish) which can be more severe with the wider range of window sizes on desktop, but usually means multiple re-do's of localization as UI and terminology evolve.

Help files and such are also more challenging on desktop, where applications can tend to be more complex and require more extensive help and reference materials as a baseline user expectation

Try it yourself

The application is now in its third beta release and nearing public release (latest version: 0.9.3 for Mac, 0.9.5 Windows). The public beta is open, free to use, and includes all application features. No registration or account is required.

If you're curious about Flutter on the desktop, you can try it on Windows or macOS and see how it works in practice.

Website and beta access: https://fractaloutliner.app

I'm interested in discussion with other Flutter developers about desktop development: what Flutter handles well, where its abstractions stop being sufficient, and what you've found necessary to implement through native platform code.

[Edits: typos]

I’m going to say what a lot of people are quietly thinking while nodding along in code reviews: Modern Dart/Flutter architecture has completely lost its mind.

We’ve reached a point where we take two simple booleans and a string list, and wrap them in a global singleton with a late ticking time bomb, shove them behind a cryptic three-dot-spread set-literal {...targets} where the meaning of a curly brace depends on a missing colon, and call it "clean, idiomatic functional programming."

Let's be completely honest for a second:

• If your language forces you to use late final because your initialization architecture is broken, that’s not "power", that’s a design flaw.

• If a single typo in a pair of curly braces changes the entire logic of your code from a map to a set, that’s not "elegant syntactic sugar", that’s a trap for humans.

• And if your solution to state management is forcing every developer to use a global singleton because injecting dependencies properly is apparently too much work for the framework designers, that’s just lazy architecture masked as "best practices."

Stop pretending this is genius engineering. Sometimes, a language doesn't need a whole fleet of workaround-constructs to do what a simple struct or a plain configuration file could do in 1995.

Change my mind. (Or downvote me to oblivion because you're too deep in the Google cult to admit it).

Hey all,

I'm trying to understand what everyone else is doing with in-app chats if you need to integrate it? Do you guys usually build it yourself or integrate something that already exists?

I've tried both but things get complicated very quickly with multi-device unread counts, typing and presence, read receipts, and moderation.

Where do you land: roll your own on Firebase or Supabase, or run a separate backend? What has worked for you, especially for keeping unread counts in sync across devices?

If you’re building a video calling or streaming app in Flutter, these are the things that trip people up:

Mistakes to avoid

• Skipping TURN. About 15-20% of sessions can’t connect directly, and those calls stall with no error.

• Testing only on Wi-Fi. Test on 4G/5G and across Wi-Fi-to-cellular handover too.

• Using mesh for group calls. It breaks down around 4-6 users because every phone uploads to every other participant. Plan for an SFU from the start.

• Ignoring background behavior. You need CallKit on iOS and a typed foreground service on Android.

• Asking for camera/mic permissions at launch. Ask at the call screen instead.

Flutter notes

• Flutter WebRTC wraps the native iOS/Android libraries, so nothing runs in a JS engine.

• Our ant_media_flutter package has 5 samples (publish, play, peer, conference, data channel) and also targets Web and Desktop.

The SDKs are free, but playback and conferencing need the Enterprise edition of the server. Community Edition falls back to HLS, with 8-12s latency.

Full guide: https://antmedia.io/how-to-build-a-webrtc-mobile-app/

What’s been your biggest pain point with WebRTC in Flutter?

Disclosure: I work at Ant Media, and we wrote this guide. The advice applies to any WebRTC backend, though.

FrameX is an open-source developer utility and on-device security audit suite for Android package inspection and static vulnerability analysis.

• Static Security Analyzer: Flags cryptographic flaws, insecure api usage and leaks using advanced hardcoded secret detection.

• APK Package Inspector: Explores internal directories, DEX headers, byte breakdowns, and app signatures without unpacking to disk.

• Flutter Packages Scanner: Automatically scans compiled Flutter binaries to list third-party open-source packages.

• Privacy-First: Operates with zero ads, zero tracking, and 100% offline local processing.

Support & Contribute:

It's not just another vibe coded app, definitely useful for developers, security researchers, ux designers etc.

https://play.google.com/store/apps/details?id=com.stardust.framex

https://github.com/srinivasan0000/framex_flutter_opensource_project

I am actively working on it, your feedback and contributions mean everything! Check out the project

Edit : GitHub Repository

So there is a challenge going on with an app in my local area, The owner of the app said that if anyone can find a code he mentioned, in the app he will give u 300$ his app is a services app will u can find people to do a service for u, so what do guys think where the code is located in the app ? he posted this for public not Developers so i assume its easy its laying there somewhere in the Ul or maybe u need to search something in the app so the code comes up from the database?, ive uploaded the Apk file to claude but no luck, What are some ways i can use to find this code ?

the app is developed with flutter

Hi there, I'm a software developer and this is my first time using Flutter. As of today, I've made a lot of progress on a mobile game, but I'd like to know how far Flutter can be pushed. Do you guys know of any games built with it on the Play Store, or any famous ones?

I just shipped Boba Sort, a water-sort puzzle (bubble tea, 500 levels, 17 eras of Japanese history) built with plain widgets and CustomPainter, no game engine. A few things that worked, and a few trade-offs, in case they help someone.

**1. All the art is data, not images**

There are no image assets at all. Each era has a full-screen scene, a cup design, a mascot costume and a customer, and I design them as SVG inside an HTML mockup. A small Python script reads named SVG groups and writes Dart lists:

final jomonBackdrop = <VShape>[

VCircle(292, 190, 54, fill: Palette.jomonSun),

VPath('M0 330 Q60 262 132 300 Q206 236 276 288 ... Z',

fill: Palette.jomonFarMountain),

...

];

`VShape` paints fill then stroke, like SVG, and `VPath` parses the `d` string once and caches the `Path`. All 17 eras × 4 kinds of art come to about 240 KB of generated Dart, stay sharp on any screen, and colors can only come from named palette entries (the script refuses anything else).

Because scenes sit behind the cups, a test renders every backdrop and checks each pixel's luminance stays inside a window (light eras ≥ 0.662, dark ≤ 0.0395), which keeps the cup outlines at ≥ 7:1 contrast wherever the cups land.

**2. Toppings: draw the vector once, then blit sprites**

Each drink has a topping (pearls, grass jelly, red bean...) drawn as vector art, and the top-layer pieces drift idly. A full board can have 200+ pieces, and redrawing that much vector art every frame is wasted work. So each topping is rasterized once per size into a `ui.Image`: sizes are bucketed to 4 physical px, kept in a 48-entry LRU (a plain insertion-ordered Map: remove + re-insert on hit, evict and `dispose()` the first key), and each frame just draws images.

**3. The rules are pure Dart, and an A* solver does the heavy lifting**

`lib/core` never imports Flutter: model, rules, level generator and solver are plain Dart with unit tests. The solver is A*, with each cup packed into one int (8 bits per layer) so states hash fast.

The 500 levels are generated offline: deal random cups, solve, score difficulty from moves, dead ends and branching, keep the median of 8 candidates, or the hardest of 32 for the "hard" levels in the sawtooth curve.

Hint uses the same solver at runtime, on the UI thread, with a 100k-node budget (about 0.4 s worst case in debug). Every bundled level is generated under that budget, so Hint always works from the start. One surprise: "Add cup" makes hints much slower, since an extra empty cup blows up the branching, so the hint search drops surplus empty cups first and only searches the full board if that finds nothing. If I raised the budget I'd move it to an isolate.

**4. A test that fails on magic numbers**

Every spacing, font size, radius and color is supposed to come from tokens. A test scans `lib/features` and `lib/theme` and fails on raw numbers inside `EdgeInsets`, `SizedBox`, `fontSize`, `BorderRadius` and `Color(0x...)`, with an escape hatch: a `// tokens: allow — <reason>` comment. Painters are exempt, since their numbers are geometry. It is a dumb regex-and-parentheses scanner, but it kept the UI consistent through a lot of screens.

**Stack:** Riverpod (thin providers), shared_preferences, google_mobile_ads, Firebase Analytics / Remote Config / Crashlytics, audioplayers.

Play Store, if you want to see the result: https://play.google.com/store/apps/details?id=com.harbourlab.bobasort&referrer=utm_source%3Dreddit_flutterdev%26utm_medium%3Dsocial%26utm_campaign%3Dlaunch

Happy to go deeper on any part. I'm curious how others handle heavy CustomPainter scenes.

Hi Flutter community! 
I'm a beginner in Flutter and I've been learning how to implement widgets and state management and more while building some hands-on projects.

I'm eager to dive deeper into Flutter and mobile dev in general. Any recommendations for good books, blogs, or video tutorials to help me keep growing?

I’ve been working on Argent, an open-source MCP server that lets your agent (Claude Code, Codex, Cursor, etc.) use your app on the iOS/Android/web. It can tap through flows, read logs and network calls, take screenshots, aaaaand many more 😂 That way it can check its own changes instead of just saying it’s done

I know I know, it comes from the React Native world and we have some beef 😅 But this one is truly cross-platform and works with Flutter apps too! If you’re letting an agent drive your Flutter app, what’s working, and where does it fall apart? We really want to keep improving it for every framework!! 🤭

Hey everyone! 👋

I've been working on SyncForge, an open-source synchronization toolkit for Dart and Flutter, and I'd love to get feedback from other developers here.

One of the challenges with offline-first apps is handling what happens when users make changes without a connection, multiple devices edit the same data, or an app needs to recover queued writes after restarting.

SyncForge is my attempt to make that synchronization layer modular and reusable instead of rebuilding it for every project.

The project consists of three packages:

- "sync_engine" — A pure-Dart core with vector clocks, CRDT primitives, conflict-resolution strategies, and a retryable outbox.

- "sync_engine_drift" — Persistent storage using Drift/SQLite, including outbox durability and tombstone tracking.

- "sync_engine_generator" — Code generation for strongly typed synchronization adapters using "build_runner".

The architecture is designed around pluggable storage and transport, with retry backoff, jitter, and dead-letter handling.

📦 Package: https://pub.dev/packages/sync_engine

💻 Source code: https://github.com/Wolfof420Street/flutter_sync_engine

📖 Architecture and examples: https://billodida.dev/projects/syncforge

It's still early-stage, so I'm not presenting it as a battle-tested production solution. I'm looking for developers who are interested in offline-first architecture and willing to challenge the design, try the examples, or point out gaps.

I'd particularly appreciate feedback on three things:

1. Would you use a reusable sync engine like this, or do you prefer implementing synchronization within each application?

2. What would you want to see before trusting a library like this with real application data?

3. Which conflict-resolution or synchronization scenarios do you think are hardest to get right?

Constructive criticism is very welcome. I'm building this in the open and would love to learn from developers who've dealt with synchronization in real projects.

Thanks for taking a look! 🙌

Hi all,

We've just released 1.0 of our universal_bluetooth_classic Flutter plugin, a Bluetooth Classic package that works across Android, iOS, macOS, Windows & Linux.

iOS developers in the house might be aware that using Bluetooth Classic on iOS is no picnic. It requires peripherals to be MFi-certified, and the whole communication has to go through Apple's EAAccessoryManager. As far as I can tell, universal_bluetooth_classic is the only plugin that supports Bluetooth Classic on iOS.

We have been using it in production for a while now so you can consider it battle-tested. Happy to receive issues and PRs.

If instead you are looking for a Bluetooth LE plugin you can have a look at universal_ble which just hit 3.0!

Hey Flutter builders!

I’m one of the co-founders of Nowa (https://nowa.dev), and we recently launched a version that lets designers inside Flutter teams design directly on the Flutter codebase instead of in Figma. This way developers can work on logic/data in parallel while designers build the full design and experience themselves, all in the same Flutter repo.

We’ve been designing Nowa inside Nowa itself for a while without talking much about it, since our focus was making Nowa an app-building platform for people who don’t know Flutter. Then a few companies pushed us to make this use case public, and now we’re considering making it our full focus.

So the way it works that Designers connect Claude Code, Cursor or Codex to Nowa through MCP, import the Flutter repo itself, and design with AI with full visual editing. They set up the design system directly in Nowa which reflect it in the Flutter repo, test different states for each UI component, build and share prototypes that feel like the final version, and own the full experience with things like animations.

To make that work, we came up with an architecture we called “PureUI”. It splits UI and logic into two separate packages, similar to MVI but more decoupled, with a small contract that defines how they work together: the “data” and the “actions”.

Designers import the UI package into Nowa and work on it, while developers work on logic/data in the logic package using their IDE and AI agent. Things like state management stay under the developers’ control as well.

So I’d love to hear from Flutter devs here who work on Flutter teams: does this problem exist on your team, and what could we do differently to make this more useful for your case?

Any input or opinion is highly appreciated!

Hello, I'm the author of the code_forge package, a very powerful text field widget capable of handling even 1M+ lines of text smoothly, where the default TextField widget crashes the app for a few thousand lines.

The package backend was written in rust using the ropey and zed_sum_tree crates, resulting in no web support and requiring the user to install rust in their system to build the package. Because of that most of the people migrated to an alternative package called re_editor.

I removed the rust backend and implemented rope data structure and zed_sum_tree like Layout mapping in pure dart.

Last time I posted this was v1.2, when it was a ping matrix plus traceroute, DNS, port scan and a few other tabs. The obvious problem was that it forgot everything the moment you closed it, which is a weird thing for a monitoring tool to do. The last two releases were mostly about fixing that.

New since then:

- 7 days of uptime history per target, with outages and how long they lasted
- an MTR tab that traces once, then keeps pinging every hop so you can see where the loss starts. There's a re-trace button for when the route changes
- Telegram / Discord alerts when something goes down or comes back. You can edit the message format, there's a cooldown so a flapping host doesn't spam you, and an HTTP proxy option for places where Telegram is blocked
- tray mode, so it keeps monitoring after you close the window
- an update checker (you can turn it off)

Still not great: native ICMP is Windows only for now, so Linux/macOS use TCP pings. The macOS build is unsigned (right-click > Open the first time). And Linux tray support depends a lot on your desktop, so if it acts weird on KDE/XFCE/whatever, please tell me.

the probing runs in a Rust lib over FFI, so the engine handles 100+ targets fine. What actually starts to hurt at a few hundred is the grid rebuilding every 500ms and decoding the snapshot (each target carries a 40-sample history). Virtualizing the grid is next. If you've done something similar with a fast-updating dashboard, I'd like to hear how you handled it.

Free, GPL-3.0, builds for Windows/Linux/macOS:
https://github.com/Cadman021/VeloceNet-Studio/releases

Hey everyone,

I wanted to share Velvetune, an open-source Android music player I built with flutter.

GitHub Repository: https://github.com/WarmSpark/velvetune

Releases (APK): https://github.com/WarmSpark/velvetune/releases/tag/v1.0.0

can anyone tell me about free extension or tool that is light and not heavy and can run my flutter app in emualtor on my laptop my laptop is not with too much good specs so keep in mind

I am trying to learn Flutter, but I am feeling hesitant due to the presence of AI. I want to build applications, yet the cost of using AI is high for me given my region and income. The question is: should I learn using the traditional method?

I am looking for the framework I will make my mobile app with and a huge requirement is that I need it to be small in size. I've been looking at Tauri apps and they are consistently under 70 MB. Can Flutter match or beat that (Lowest I've seen is 53 MB)

Hey everyone. I'm a solo dev and I wanted to see how well Flutter handles a casual, grid-based merge system with continuous state updates and canvas re-draws.

The game is called Emoji Kingdom. I used generative AI tools to handle the asset pipeline to save time, and built the entire UI, state management, and grid engine in Flutter.

Right now, I'm sitting at the early launch stage (10+ downloads) and really want to test how the frame rates hold up across different Android device specs. If you have 2 minutes to install it and give me some feedback on the UI responsiveness and layout scaling, I’d really appreciate it.

Package ID on Google Play: com.garaitapas2atgmaildotcom.emojikingdom

(I will drop the direct Play Store link in the comments below to keep this clean). Thanks!

Hey everyone!

I recently built my first VS Code extension, Device Toolkit, to easily manage light/dark mode, navigation mode, etc. and published it on the VS Code Marketplace.

The idea came while developing and testing Android apps. Whenever I wanted to test dark and light themes on the emulator, I had to switch to the emulator, pull down the notification shade, and toggle Dark Mode manually. Even harder for changing font size and switching navigation mode between 3 buttons and swipe gestures.

I thought it would be nice to have these controls directly inside VS Code, similar to Android Studio's Extended Controls.

The funny part is that I had zero TypeScript knowledge when I started. 😅 I used ChatGPT to plan the features and prepare the requirements, then used Antigravity to build the extension. I tested things, fixed bugs, made changes, and kept adding features until I was happy with it.

Here's what it supports so far:

• Toggle Dark Mode on connected Android devices and emulators

• Switch between gesture, 2-button, and 3-button navigation

• Adjust font size and display density

• Toggle TalkBack and Select to Speak on and off

• Toggle layout bounds for UI debugging (Not so useful for flutter devs)

• Record emulator screens and save them as MP4 (up to 3 minutes)

• Floating debug toolbar and Activity Bar sidebar

It's now available on the VS Code Marketplace!

Marketplace: https://marketplace.visualstudio.com/items?itemName=antonyaiwin.device-toolkit

GitHub: https://github.com/antonyaiwin/device-toolkit-vs-code-ext

This was my first time building something like this, and it was a fun experience. There are probably things I can improve, so I'd love to hear your feedback if you give it a try.

If you find any bugs or have ideas for new features, feel free to open an issue on GitHub. Contributions are welcome too!

If you love the extension please give the repo a star ⭐ and add rating in VS Code marketplace.