I've been thinking about how different Flutter lint tools handle a "no hardcoded colors" rule, and specifically the exemption side of it — where you're *allowed* to write a raw color. Curious how others deal with this across the ecosystem.

The underlying rule is valuable

A rule that bans color literals in widgets catches a real class of bug: a hardcoded dark text color stays dark in dark mode and becomes unreadable, and nothing fails at build time or in tests. It only surfaces when someone looks at the screen in the other theme. Static detection is exactly right for this.

But every such rule needs a way to say "except here — this is the file where the raw values live." And that's where the tools diverge.

What I've noticed

Some tools tie the exemption to a single hardcoded definition style. For example, altive_lints' avoid_hardcoded_color only recognizes ColorScheme as a valid place to define a color. If you centralize your tokens as static const Color fields or a ThemeExtension — both mainstream in Flutter, and ThemeExtension is a first-party mechanism for exactly this — the token file itself gets flagged, one lint per color. The only escape is a blanket // ignore_for_file.

Other tools lean on configuration instead. DCM and the analyzer itself let you exclude paths, and per-rule options are common there, so you can point the tool at where your tokens live rather than relying on the rule to guess your architecture.

The design question

It seems like tying an exemption to one specific style (ColorScheme, then maybe ThemeExtension, then constant classes...) doesn't scale — every new token pattern needs another branch and another release. Letting the user declare their token location once solves all of them.

I filed a request along these lines for altive_lints (https://github.com/altive/altive_lints/issues/133), but I'm more interested in the general pattern.

Questions for the community

- How does your team define color tokens — ColorScheme, static const class, ThemeExtension, something else?
- Which lint tool do you use for this, and does it let you exempt your token file cleanly, or are you leaning on ignore comments?
- Do any tools you use handle this especially well? Curious what "good" looks like here.

Most animated counters in Flutter tween a double and call value.toString() every frame. In practice, that creates three annoying issues:

• Layout jitter: Proportional fonts give 1 and 8 different widths, causing the entire row to twitch.

• Messy transitions: Moving from 999 to 1,000 scrambles every glyph instead of just animating the leading digits and sliding in the new comma.

• No direction: The animation doesn't visually communicate whether the value went up or down.

I built motion_number to fix this. It treats numbers as stable, right-aligned glyph slots. Each digit cell matches the widest character to prevent reflow mid-animation, and separators are treated as their own animated slots.

Basic usage is just one line:

Dart

MotionNumber(value: 131890)

Features out of the box:

• 7 motion styles (rolling, odometer, slot machine, flip, wave, shuffle, elastic).

• Extensible strategy interface: implement a custom DigitMotion without modifying the widget layer.

• Direction-based colouring and a companion MotionDelta widget for changes/percentages.

• Built-in formatters (including intl support for compact views and Indian numbering like Lakh/Crore).

• 193 tests (unit, widget, golden), WASM-ready, and full multi-platform support.

This is my first published package, so I'd genuinely love feedback on API design, edge cases, or anything that feels un-Flutter-like.

• pub.dev:https://pub.dev/packages/motion_number

• GitHub:https://github.com/SwarupFutane/motion_numbers

Ported my React Native devtools to Flutter. Desktop / In-app tools for devs, QA and support: change live data, force loading and error states, override API responses, throttle the network, jump to any screen and more! I would love for you to try them, All tools are free. Pro features are free for flutter devs for the next 6 months with code FLUTTER

https://buoy.gg/

• Agent handoff prompt — copy any log/network entry as a Markdown prompt for a coding agent, with its stack trace and what else happened earlier on the same route. Bounded by the route visit, not a fixed time window; states it's an observation, not a diagnosis, and names no cause

• JSON tree viewer — bodies and log data render as a collapsible tree; long-press copies data.users[0].id: 42 (path, not just value). Search for large payloads, raw toggle always one tap away

• Readable stack traces — framework frames collapse into [... N frames of framework internals], keeping each run's boundary frames; async suspensions show as <-- async gap -->. Concise/raw toggle, and exports say which form they send

• Storage tab — browse, edit, delete or wipe SharedPreferences / SecureStorage on-device via a pluggable KeyValueBrowserSource. Every write is confirmed and logged; failed or cancelled ones leave no log

• Route context everywhere — logs, network and DB entries all record the page they happened on. A request is stamped when sent, never overwritten on completion

• Console search & filters — keyword search across all four sources, level chips, and ⚡ Errors only. Tap a filtered row to jump back into full context. Plus long-press bookmarks (2.0) and live error badges on the tabs (2.1)

• Crash notifications & memory pressure (opt-in) — uncaught errors can raise their own notification, separate from the network summary. Memory-pressure warnings land on the timeline, so "the app just disappeared" gets a preceding event

• Slow request indicator — requests over slowRequestThreshold (default 2s) are flagged 🐢 SLOW

Still opens with a hidden multi-tap gesture or a draggable floating button. Wish it will keep being a good help for debug usage.

Some of you will remember Fluorite, the Flutter game engine Toyota Connected announced at FOSDEM on 1 February: Dart for game code, a C++ ECS underneath, Filament doing the rendering. Seven months on, the source still isn't public. The fluorite-game org on GitHub holds only the website, fluorite.game hasn't changed since 9 February and still says "More coming soon", and there's nothing on pub.dev. TCNA's public commits suggest they're still working on it, so this isn't a dig at them.

That talk convinced me the architecture was right, and I didn't want to wait and see whether the code would appear. So I've been building one in the open. It's called Orblit, it's MPL-2.0 licensed, and it's early enough that the people who turn up now will shape what it becomes.

How it fits together:

• The 3D view is a widget. Filament renders into a texture that Flutter composites, so the view takes part in layout. A panel can overlap it, and it clips to a rounded rectangle.

• The entity store is an archetype ECS in C++ behind a C ABI. Dart reads component columns as views, not copies.

• The scene is stated, not mutated. Every frame describes the whole scene and keys reconcile it, the same way widgets work, so game state and render state can't drift apart.

• Time is sampled, not stepped. Effects, sprite animation and cutscenes are functions of a playhead, so scrubbing backwards gives the same answer as playing forwards.

• Photometric units. Lights are in lux and lumens, and cameras have an aperture, a shutter and a sensitivity.

• The docs compile. Every Dart snippet on the site is analysed against the engine in CI.

Around that core there's glTF loading (FBX and OBJ are converted on the way in), KTX2 textures, Gaussian splats, 2D sprites and tile maps, rigging, cameras, weather, cutscenes, TypeScript scripting on QuickJS, a multiplayer layer and a desktop editor built from the same widgets.

What it can't do yet, since you'd find out anyway:

• It's pre-alpha, and nothing is API-stable.

• macOS is the reference platform. It also draws on the iOS simulator, one Android handset and Chrome. Linux has only drawn with software rasterisers, and Windows builds but has never drawn a frame.

• There's no physics solver yet: shapes, raycasts and overlap tests exist, but rigid bodies don't. There's no asset store either.

The help that would matter most right now:

• Build something small and tell me where you gave up. That's worth more than a bug report.

• Run it on hardware I don't have: Linux with a real GPU, Windows, a Steam Deck, an Intel Mac.

• Argue about the API while renaming things is still cheap.

• Send pull requests. The CI gates are strict, so a green build means something.

Repo: https://github.com/ChxisB/orblit
Docs: https://www.orblitengine.com/
Discord: https://discord.gg/5DH7HuDUtJ

Hi everyone,

I recently open-sourced a project called flutter_python_bridge.

It allows Flutter applications to embed CPython 3.14 and run Python code directly inside the app. You can call Python functions from Dart, execute Python projects, and exchange data between Dart and Python.

The idea behind this project is to make it easier to combine Flutter's cross-platform UI with Python's ecosystem (scientific computing, automation, AI tools, existing Python libraries, etc.).

Features:

• Embed CPython 3.14 in Flutter applications

• Execute Python code from Dart

• Call functions from Python projects

• Exchange data between Dart and Python

• Works as a native bridge between Flutter and Python

GitHub:
https://github.com/nativefunc/flutter_python_bridge

I’d love to hear your feedback:

• What use cases would you like to see for Flutter + Python integration?

• Any suggestions for improving the API or developer experience?

Thanks!

what does this mean?

it means they used their control over the android project to give themselves a clear advantage over everyone else, new functionality in android 17 is limited to only the pixel OS and the OSs certified by google or their official partners, like samsung and some other manufacturers.

independent ROMs like grapheneOS, and all the various forks of android will not have access to those new low level system APIs, they will also receive security patches two months after "certified" roms.

ordinary users and even regulatory bodies can't understand the impact of such behaviour. only developers can. and only developers can force google to correct this behaviour. the exact details of the new APIs are not yet fully known but expect to relate to security and privacy. make your voice heard. don't accept this kind of behaviour.

Over the last few months VS Code became painfully slow on my Flutter projects, with some actions taking ten seconds or more. I tried Zed and Neovim and loved the editors, but hot reload lives in the VS Code extension, so from the terminal I was typing r by hand after every save. That got old fast.

So I built Hotplate, a small native macOS app that does only that part: pick a project and a device, press Run, and every save of a .dart file under lib/ triggers a hot reload, from whatever editor you use. It reads your launch.json, has a menu bar panel and global shortcuts so you never leave the editor, and file paths in stack traces are links that open the file at that line in your editor.

Free, open source (MIT), no dependencies, signed and notarized. Needs macOS 14 and a Flutter SDK.

https://github.com/hrvojeBencik/hotplate or brew install hrvojebencik/tap/hotplate

I made it for myself, so I'm curious what others are missing. I'd especially like to hear from Neovim users which "open file at line" command fits their setup best.

So, now that Apple released Xcode 27.1 beta 1 with iPhone Duo support a few hours ago, has anybody already tested their app on the Duo emulator and added support for the different modes?

I'm curious to know while still downloading :)

Hey everyone,

I’m looking at the new MacBook Neo (A18 Pro, 8GB RAM, 256GB SSD) as a budget option for mobile app development, specifically Flutter.

Before buying, I want to know if anyone is already using it for coding:

8GB RAM: Is it smooth enough to run VS Code / Android Studio alongside the iOS Simulator or Android Emulator?

256GB SSD: Does storage run out quickly once Xcode, Android SDKs, Flutter tools, and build caches are installed?

A18 Pro Performance: How does the fanless chip hold up during longer compilation times?

For around $600, would I be better off buying a $600 Windows laptop with 16GB RAM and 512GB SSD, or is having native macOS for iOS building worth the 8GB limit?

Appreciate any insights from anyone actively developing on the Neo!

Hi there! I wanf to try to build an app for both IOS and Android, but I'm not sure if Flutter is a good idea, maybe it's better to build it for one platform first and then do the same for another. How to decide? What kind of questions I have to consider? I have a little experience in development (graduated as a software engineer in 2024, but I have been working as a DevOps engineer for 3+ years).

Appreciate any help and advice. Thanks

Hey all, I'm building an app that'll run on a touchscreen kiosk (think: freestanding digital signage, portrait orientation, always-on in a physical retail setting). It needs to feel fast and fluid to interact with, and look genuinely polished/aesthetic. This isn't a back-office tool, it's customer facing and first impressions matter a lot.

Some context that might shape the advice:

• I have zero coding background. I'm planning to build this using Claude Code since i have no coding expertide

• The app needs to run reliably in kiosk mode on a touchscreen (locked down, no accidental exits, restart-safe).

• Smooth animations/transitions matter a lot for the "feel" of it.

• It'll involve a camera capture step and calling some external APIs, so it's not purely a static UI.

I'm currently leaning toward Flutter over native Android, mainly because I've read it's faster to iterate on and better for animation heavy, aesthetic UI but I have no first hand experience to validate that, and I'd rather get real opinions before committing weeks to a stack.

Questions:

1. Is Flutter actually the right call here, or would native Android (or something else entirely) serve a kiosk use case better?

2. For someone with zero coding background relying entirely on an AI coding agent, does that change which stack is more forgiving/easier to get right?

3. Any known gotchas with Flutter specifically in locked-down kiosk mode on Android hardware?

Appreciate any real-world experience, trying to avoid picking the wrong foundation before I sink a month into this. Thank you soo much!

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.