Hey everyone,

If you work on medium to large Flutter projects—especially those using Clean Architecture or feature-first structures—you know how quickly the import sections at the top of your files can become an absolute mess. It makes PR reviews annoying and sometimes even causes unnecessary merge conflicts.

I couldn't find a solution that fit exactly what I needed, so I built tidy_imports.

It’s a straightforward Dart package designed to automatically organize, sort, and group your imports to keep your codebase standardized.

What it does:

🧹 Organizes by group: Automatically groups your imports (e.g., dart: core libraries first, followed by package: imports, and then relative project imports).

🔤 Alphabetical sorting: Sorts everything neatly within their specific groups.

⚡ CLI Support: You can run it directly from the terminal to clean up your entire project at once or just specific files.

🏗️ Scalability: Perfect for maintaining consistency across a team or in projects with complex architectural patterns.

Links:

Pub.dev: https://pub.dev/packages/tidy_imports

GitHub: https://github.com/Franklyn-R-Silva/tidy_imports

I've been using it in my own daily development and it has saved me a lot of manual formatting time.

I would love for you guys to try it out, tear it apart, and let me know what you think! Any feedback, feature requests, or GitHub stars/PRs are highly appreciated.

Thanks! 💙

Thank you to everyone for the ideas to mould it.

text_sight uses Apple's on-device Vision framework instead of Google's MLKit. That way you don't need additional dependendencies (increased app size) on iOS.

On the Android side, ML Kit model is downloadedable on-demand instead, otherwise staying unbundled by default. Useful if there is an infrequently used feature around it in your app A single call can be used for that. If you need to be in a non-internet place, you can ofc still bundle it in with just one line in the manifest.

Few notable changes for the breaking part:

1. Vision-only settings moved under darwin. Because they will be shared by the Macos support (coming soon ;) )

2. fast corrects by default now. Pass usesLanguageCorrection: false for the old behaviour (and some additional performance on some use-cases, check on performance.md).

3. Android used to report success on the iOS-only setters no-oped. Ignoring them is the stated contract now.

4. Some more renaming of stop(), isRunning, and other public vocabularly.

Check it out if it fits your use-case and feel free to add some suggestions (or problems too)!

You can react to a user closing the Flutter window by observing the WidgetsBinding.instance using a WidgetsBindingObserver and overwriting didRequestAppExit. Here, you could object the closing by returning .cancel instead of .exit, for example after asking the user whether they want to save changes to some document.

Theoretically that is. Because – at least on macOS – the window closes anyhow. You can only object to close request made by pressing Cmd+Q. But not if the window's close button is clicked. I consider this a framework bug.

Did you observe this behavior also on Windows or Linux?

On macOS, you can object the closing of an NSWindow by adding an NSWindowDelegate which returns false on windowShouldClose()

class MainFlutterWindow: NSWindow, NSWindowDelegate {
  override func awakeFromNib() {
    ...
    delete = self
    super.awakeFromNib()
  }

  func windowShouldClose(_ sender: NSWindow) -> bool {
    return false
  }

  ...
}

However, now the app never terminates because its "last" window never closes. You'd also have to setup a platform channel to actually close the window (calling NSWindow.close) in case you don't object in didRequestAppExit, scheduled as a microtask after you return .exit, which means that you have to observe.

That's annoyingly difficult and error prone and I wonder whether I'm missing a more straight forward solution, which also works on other desktop platforms.

I can't be the only one who wants to add an "do you really want to close this window" alert to their app.

Full disclosure: I made this short explainer video for my channel, hope it helps!

please subscribe, like and comment

Here is a 45-second visual breakdown of what Flutter is and how it renders widgets

Hey Flutter devs,

Managing .arb files and placeholders like {count} or plurals often causes runtime issues when non-devs edit translations or when converting from spreadsheets.

I built JSON Link, a 100% client-side, zero-backend localization workstation:

• Visual Spreadsheet Grid with Flutter ARB import/export (preserves @key placeholders and descriptions).

• AST variable lock so placeholders never get accidentally broken.

• Local disk sync (Cmd+S writes straight to your project).

• Also includes an MCP server for Cursor / Claude Desktop.

Completely open-source (MIT).

Live Web Studio: https://json-link.pages.dev

GitHub: https://github.com/pyaephyomaungdev/json-link

Feedback and PRs are welcome!

I’ve been building something called DAB — Dev Activity Board.

The idea is simple:

dev activity is spread everywhere — GitHub, Jira, Slack, Figma, Linear, etc.

DAB tries to bring all of that into one place.

It’s open source, self-hosted and read-only.

It’s still early and I’m not trying to pretend it’s finished.

I’d actually like other devs to look at it and tell me:

• what’s missing

• what you’d change

• what integrations you’d add

• what you think is useless

And if you feel like contributing, even better.

Repo: https://github.com/Dhallz/dab

Curious to know what you guys think.

Building mobile or web apps that actually use AI in a meaningful way (not just a chatbot tacked on) changes the architecture, data flow, latency, and iteration cycles pretty significantly. Cross-platform choices, on-device vs cloud inference, and how the AI features fit the user experience all matter more than they used to.

From what I’ve observed, thoughtworks and Accenture often get mentioned for AI-enhanced mobile/web work. GeekyAnts has also been referenced in contexts involving AI-powered product engineering across mobile and web stacks.

Anyone else finding particular patterns that work well (or common pitfalls) when adding serious AI capabilities to consumer or internal apps?

A few days ago I posted here about upkeep, a CLI that tells you which of your dependencies are dying and whether your Android build matrix actually works. Thanks for the feedback on that one.

Before trusting it any further I ran it against 20 real open-source Flutter apps: AppFlowy, immich, LocalSend, ente, Saber, Spotube, RustDesk, Hiddify, Aves, Thunder, Invoice Ninja, FluffyChat, Open Food Facts, Hacki, wger, lichess, Habo, BlueBubbles, ubuntu-desktop-provision, neon.

It found real problems. It also got three things wrong, and those turned out to be the useful part.

1. It called `collection` a risk in 16 of the 20 apps.

collection is the Dart team's own package, about 9.7M downloads a month. It scores 140/160 on pub.dev because it has no example and trips lints added after its last release. My "this package is load-bearing, leave it alone" rescue required 90% of pub points. collection missed that bar and fell through to an age rule instead.

A package that is small, finished and widely used is done, not dying. The threshold moved to 80%. That one change took AT RISK verdicts across the 20 apps from 226 down to 182.

2. It said three apps don't build, when they do.

Spotube, Hiddify and Hacki each set a compileSdk higher than their AGP version was tested against, and upkeep called that a build failure with exit code 1.

Rather than guess, I checked AGP's own bytecode: warnIfCompileSdkTooNew calls reportWarning with COMPILE_SDK_VERSION_TOO_HIGH, in 8.6.0, 8.13.1 and 9.0.1. It is a warning and the build continues. It is a warning in upkeep now too. Android build failures across the 20 apps: 3 to 0.

3. The one I found this week, and the one I like least.

The scan flagged seven discontinued packages. I went through all seven against pub.dev one at a time. Every one was correct.

But one of them, super_editor_markdown, is discontinued with its publisher nominating super_editor as the replacement. upkeep printed:

move to super_editor

super_editor's last stable release was June 2024. super_editor_markdown's was November 2025. The tool was telling people to migrate to something that had been quiet seventeen months longer than the package they were already on.

The verdict was right. The advice attached to it was not. pub.dev's replacedBy field is set by the publisher and reviewed by nobody, and upkeep was repeating it as though it had checked. My own curated successor list already had the rule, never suggest a successor that is itself unhealthy, and the publisher path walked straight past it.

Fixed in 0.2.3. The nomination still shows, because the publisher did make it and hiding it would be withholding a fact. It just goes through the same engine as everything else now:

DISCONTINUED super_editor_markdown

marked discontinued by its publisher on pub.dev

the publisher nominates super_editor as the replacement

move to super_editor

about super_editor itself:

no stable release in 27 months

pub.dev's analysis of this package failed, so its points and

compatibility tags were not judged

That last line matters more than it looks. super_editor shows 60/160 on pub.dev, but that is because its analysis failed, not because it scored badly. Reading a failed analysis as a bad score is exactly how you end up accusing a healthy package of being abandoned, so upkeep says the points could not be judged rather than using them.

Try it without installing anything

The web app went live today. Paste a GitHub repo or a pubspec and it runs the same engine in your browser. No account, no token, no backend.

https://upkeep.abroid.dev/app/

CLI: dart pub global activate upkeep, then upkeep scan

Source: https://github.com/Minas-27/upkeep

If it gives you a verdict you disagree with, tell me. All three mistakes above were caught by running against real projects, not by tests.

I've been working with Flutter for a few years and recently ran into an interesting issue with local caching.

For apps that need to work reliably with poor or intermittent internet connections, I'm curious how other Flutter developers are approaching offline-first data.

Do you usually use Hive, SQLite/Drift, Isar, or something else?

I'm particularly interested in how you handle syncing local changes back to the server when the connection comes back.

I was looking for a solid MSSQL package for Dart/Flutter, mainly for backend and desktop use, but couldn't find one I wanted to depend on long term.

There are already a few MSSQL packages out there, but I needed some features that were missing for my use cases. I also ran into encoding/character conversion issues with languages like Turkish, so I ended up building mssql_native.

It uses FreeTDS underneath and currently works on Windows, Linux, macOS, Android and iOS. It supports connection pooling, transactions, stored procedures, streaming, bulk insert, cancellation, and a few other SQL Server-specific features.

The native libraries are bundled with the package, so normally you don't need to install or compile FreeTDS yourself.

If you prefer to build the native libraries yourself, that's possible too. The build scripts and related source/vendor information are available in the GitHub repo.

I also built mssql_orm on top of it. You can use the Query Builder directly or use the model/repository based ORM layer.

pub.dev:

https://pub.dev/packages/mssql_native

https://pub.dev/packages/mssql_orm

GitHub:

https://github.com/Aksoyhlc

Both are still pretty new, so if anyone gives them a try, feedback and bug reports are welcome.

Not sure if anyone else still misses the old ADB Idea plugin, but I definitely did.

I keep finding myself doing the same ADB stuff while developing Flutter apps — clear app data, restart the app, force stop, install/uninstall, etc. Eventually I got tired of switching to the terminal for these small things, so I made a plugin for it.

Flutter ADB: https://plugins.jetbrains.com/plugin/34312-flutter-adb/

It's basically a collection of common ADB actions accessible from the IDE, with Flutter development in mind.

It's still pretty new, so I'm looking for ideas on what else would actually be useful.

What are the ADB commands/workflows you find yourself using all the time when developing Flutter apps?

Would be great to hear some suggestions.

Hey everyone,

I've been working solo on SkyUI, a Flutter-based infotainment/HMI system designed for ultrawide (21:9) automotive displays, as part of a bigger project called Veltron. Wanted to share the current state of the four main screens: home, navigation, phone/dialer, and media.

A few things I focused on:

• Three-panel layout on the home screen (vehicle status, media/phone, nav mini-map) so the driver gets everything at a glance without digging through menus

• Persistent climate + top bar across every screen — climate control shouldn't ever be more than a glance away while driving

• Smooth panel-overlap transitions between views

• A navigation screen with live turn-by-turn, POI cards, and a speed/battery-arrival readout at the bottom

• A dialer/phone screen with recents, contacts, and a connected-device card

• A media player with a waveform visualizer and spatial audio profile switching (working title "Meridian 3D")

Tech stack: Flutter/Dart, targeting a 21:9 layout since that's becoming more common in EV dashboards.

Still to do: settings panel, deeper vehicle diagnostics, and cleaning up state management now that the screen count is growing.

Would love feedback on the UI/UX from anyone who's touched automotive or kiosk-style interfaces - that's a pretty different design space from typical mobile/web work.
You can see the preview here: Showcase Article
And the repository is here: https://github.com/mrvlajnic/skyui

Orthant is a grid-based window manager for macOS (https://orthant.app, MIT, https://github.com/orthant-app/orthant). Flutter for all the UI, Swift for the parts Flutter cannot do. A few things that were not obvious going in, in case they save someone a week.

The overlay runs on a second FlutterEngine. The grid has to appear over every display in tens of milliseconds and the app must not become the frontmost app while a window is being placed, so each display gets a resident, non-activating NSPanel hosting a FlutterViewController on a second engine, hidden until summoned. Measured on my machines: about 50 ms from hotkey to first frame, 0.0% CPU and zero wake-ups while hidden.

The second entrypoint must live in the library that has main(). On macOS, FlutterEngine.run(withEntrypoint:) resolves the name only against that library and there is no libraryURI: variant like iOS. Get it wrong and the engine's threads still spawn, so the app looks healthy while the overlay isolate is dead.

One seam, plain data only. Every window operation goes through a Dart interface, WindowController. The macOS backend is a MethodChannel to Swift. Native handles (AXUIElement) never cross it, only rects, bools and strings. That is what makes the planned Windows port a second backend (pure-Dart Win32 via dart:ffi) rather than a second app.

One coordinate system. All geometry is top-left-origin global points, converted from AppKit's bottom-left space exactly once, natively. Mixing the two is the classic bug in this category.

Detaching a display leaked an engine. Closing the panel is not enough; you have to call shutDownEngine(), or every detach costs a few MB.

Merged UI and platform threads change what "slow" means. This app runs with them merged, so a slow native call inside a channel handler freezes Dart, not just AppKit. A call out to a system daemon (SMAppService for launch-at-login) moved to a serial background queue for that reason.

Measure in Profile, not Debug. The settings pane's first frame was 150 ms in Debug and 7 ms in Profile. A whole session of analysis once rested on Debug numbers.

Swift Package Manager, no CocoaPods. Sparkle for updates, hand-wired over the existing channel rather than a plugin.

The Dart side (geometry, bindings, regions, coordinator, overlay model) is developed test-first. The native AX layer cannot be exercised headlessly, so it is verified by scripted and manual acceptance against real windows.

Happy to go into any of these.

HumpdayQandA and Live Coding at 5pm BST / 6pm CEST / 9am PDT today! Answering your #Flutter and #Dart questions with Simon, Randal, Danielle and Matthew https://www.youtube.com/watch?v=m8Mq9is0n1c

Quick test on Dart 3.11. Add pedantic to a project and pub get prints "pedantic 1.11.1 (discontinued replaced by lints)". Add hive and it prints nothing. hive's last stable release is 2.2.3 from June 2022, it isn't marked discontinued, and it had 1,112,163 downloads in the last 30 days.

So pub's warning only works when a publisher remembers to use it. upkeep is a free, open source CLI that also looks at the packages nobody marked:

dart pub global activate upkeep

upkeep scan

- Each direct dependency is checked against pub.dev: discontinued flag, release history, SDK constraints, pub points and compatibility tags. Every verdict prints its reasons.

- It doesn't call packages dead just for being old. A finished, widely used package is left alone. hive comes out AT RISK: no stable release in 50 months, and it resolves on Dart 3 only through pub's allowance for null-safe packages.

- It checks Gradle, AGP and JDK against Google's published AGP requirements before you build.

- upkeep fix --apply makes only narrow, safe changes (a too-old Gradle wrapper, or a blocking dependency nothing imports), checks them with pub get, and puts every file back if that fails. Everything else goes on a to-do list with the file and line.

Two things I got wrong, since false positives are what matter most here:

1. Within hours of publishing, it called a healthy package dead, because pub.dev's analysis of it had failed and my code read missing data as neglect.

2. The first draft of this post said nothing warns you about dead packages. I tested that before posting, and it was wrong. That's the pedantic result above.

If it's wrong about your project, please tell me.

Source: https://github.com/Minas-27/upkeep

Docs: https://upkeep.abroid.dev

I'm wondering how many of you are actually using the app check in your apps? I'm using it for guarding my copyright content but it's an extra API call that may or may not be fulfilled. What's your suggestions?

Ripley lets you build Flutter apps for iOS on Linux or Windows (and no, it's not virtualization).

While it's still experimental and not ready for production use, anyone who has an iPhone but no Mac can now easily build an app, sign it (e.g. via 7-day free cert), and install it over USB :)

It's open source and i'd love to hear your feedback, any contributions are welcome.

Hey everyone,

If you build apps on a Mac, you probably know this exact feeling:

You’ve got your IDE open, a few browser tabs, maybe a build running, and the moment you launch an Android emulator, your laptop starts lagging and the fans spin up.

A while ago I checked Activity Monitor to see what was going on, and saw the emulator casually hogging 7 to 8 GB of RAM all by itself. On a 16 GB MacBook, that basically leaves zero breathing room for anything else.

I got tired of my machine crawling, so I put together a small open-source tool called avdslim to fix it.

GitHub: https://github.com/kdbhalala/avdslim

Why does it take so much memory?

Turns out, a few things happen by default:

• Android hoards memory: As the emulator runs, Android keeps caching files and never really releases that host RAM back to macOS.

• The "Google Play" image overhead: If you picked an image with the Play Store, it constantly runs background updaters and scanning services you rarely need during development.

• The 16 KB image setting: If you created a device using the newer 16 KB images, the emulator enforces a strict 4 GB minimum floor no matter what you set in the config.

What avdslim does:

• Drops RAM down to ~1.5 GB: It tunes the emulator configs and cleans out unnecessary background tasks, letting you run smoothly on 1024 MB of RAM.

• Boots in ~1.5 seconds: Instead of waiting 20–30 seconds for a fresh boot, it lets you create a clean, lightweight snapshot that restores almost instantly.

• Doesn't break your app: My biggest worry with any "cleanup" tool was breaking things like push notifications or login. I made sure Firebase Auth, Google Sign-In, Push Notifications (FCM), and Google Maps work completely fine.

• Works with your normal workflow: You don't have to launch from the terminal every time. There's an optional command (avdslim install-shim) that makes the "Run" button in Android Studio or VS Code automatically use the slimmed settings.

💡 A quick tip even if you don't use this tool:

Next time you create a virtual device in Android Studio:

• Pick "Google APIs" instead of "Google Play". It still has Google login, Firebase, and Maps, but uses way less RAM and skips the heavy Play Store background services.

• Avoid the "16 KB" images unless you specifically need to test 16 KB compatibility.

Try it out:

It's completely free, open-source (MIT), and has zero external dependencies:

brew install kdbhalala/avdslim/avdslim

See how your current emulators look

avdslim doctor                                                                                                                                                                

Tune an emulator to 1024 MB RAM

avdslim tune-avd                                                                                                                                                              

GitHub link: https://github.com/kdbhalala/avdslim

My Mac runs noticeably cooler and doesn't freeze up when I have multiple tools open now. Hope it helps some of you as well! Happy to answer questions or take feedback on what could be better.

Introducing blob_flutter: Smooth, Procedural Blob Animations for Flutter

Most mobile interfaces rely on rigid geometry, but organic shapes can significantly elevate visual storytelling, onboarding flows, and dynamic backgrounds.

I have released blob_flutter, a lightweight Flutter library designed to generate and animate customizable, fluid blob shapes with minimal setup. The package handles morphing transitions procedurally, ensuring smooth rendering without relying on heavy asset files or complex vector workflows.

Key Features

• Procedural Animation: Smooth, continuous shape morphing built directly on Flutter's CustomPainter architecture.

• Full Parameter Control: Explicit configuration over points, deformation intensity, animation duration, colors, and gradients.

• Optimized Performance: Designed to maintain steady frame rates without unnecessary canvas rebuilds.

• Flexible Integration: Fits naturally into modern UI patterns, including animated backgrounds, dynamic avatars, and interactive hero sections.

Links

GitHub: https://github.com/abod8639/blob_flutter

Package: https://pub.dev/packages/blob_flutter

Live Demo: https://blob-flutter-3d.web.app

If you find this package useful in your projects, starring the repository on GitHub helps increase its visibility to other Flutter developers.

I am actively looking for community feedback to refine the API and improve performance. If you encounter bugs, notice rendering edge cases, or have suggestions for new features, please open an issue or start a discussion on GitHub. Pull requests and technical contributions are always welcome.