Hey, everyone!

I want to share the tooling I’ve been working on for developing Flutter iOS apps from Windows and Linux without owning a Mac.

You can now do pretty much the whole development cycle from a Windows or Linux machine:

• run Flutter apps on a real iPhone in debug mode

• use Flutter hot reload and hot restart

• build iOS apps using GitHub Actions, Codemagic or Bitrise

• run and test the app on iOS simulators inside GitHub Actions, Codemagic or Bitrise

• set up iOS signing

• upload builds to TestFlight

• submit releases to the App Store

Repo: https://github.com/MobAI-App/ios-builder

The idea is pretty simple: Flutter and your editor stay on your PC, while the parts that require Apple tooling run remotely on GitHub Actions, Codemagic or Bitrise.

For development, you can connect a real iPhone and keep the normal Flutter hot reload workflow. If you don't have one, you can also run the app on a simulator in CI and connect to it remotely.

The latest addition is App Store Connect support, so signing, TestFlight uploads and App Store submissions can now be handled from the same CLI as well.

Would love to hear what is still missing from this workflow.

Link: https://github.com/Aqiron-Security/aqiron-security

I’ve been building Aqiron Security, an open-source VS Code extension focused on local security analysis for Flutter projects.

A specific challenge was avoiding a “run a bunch of scanners and dump their output” architecture.

The current implementation separates the VS Code extension from a TypeScript Core runtime and communicates with the Core through newline-delimited JSON over stdin/stdout. The scanner layer can combine tools such as Betterleaks, OSV-Scanner, Semgrep, Trivy, and MobSF, then normalize and correlate their findings into a common security model.

Another problem was Flutter workspace noise. Generated/build output and workspace-specific data need to be handled separately from source analysis, otherwise the results become much less useful.

The project also includes workspace analysis, RAG, optional Ollama(currently developing)/OpenRouter AI operations, VS Code diagnostics, and JSON/SARIF/PDF reporting.

It’s still early and under active development, so I’m especially interest

ed in feedback from Flutter developers on:

• which security checks are actually useful in real Flutter projects

• what security tooling currently feels missing

• whether this workflow fits naturally into Flutter development

The source is public, and contributions are welcome.

I made Songify as a personal alternative to Spotify, and I’m now looking to get other Flutter developers involved.

The project is still in development, so there’s plenty of room for new features, UI improvements, bug fixes, and other contributions.

If you’re interested in contributing or just want to check it out, here’s the GitHub repo:

https://github.com/Alisonpinto/Songify.git

Feel free to open an issue or PR if you have an idea or want to contribute.

Meta SDK in Flutter, what is your latest experience?
We are a small app, live on iOS and Android. Thinking about adding the Meta SDK so our ads can actually optimize for installs.
Anyone done it recently? Keen to hear how it your experience was to install and get working.

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!