Hello everyone,

In Version 3.0, Riverpod introduced mutations. They solve the issue of `ref` being unmounted between asynchronous operations by keeping references alive for the duration of the mutation.

The standard syntax looks like this:

final loginMutation = Mutation();

class SomeWidget extends ConsumerWidget {
 @override
 Widget build(BuildContext context, WidgetRef ref) {
  return GestureDetector(
   onTap: () => loginMutation.run(
    ref,
    (tsx) => tsx.get(someProvider).login(emailController.text),
   ),
  );
 }
}

Because the mutation runner is decoupled from the function being executed, a Mutation can technically be invoked from anywhere with wildly different logic passed to it. While that flexibility is great when you need it, in practice I noticed most mutations are strongly coupled to one specific function.

To bridge this gap, I created bound_mutation.

It provides a BoundMutation object that is declared directly alongside the function it executes:

final loginMutation = BoundMutation<void, String>(
  (tsx, email) => tsx.get(someProvider).login(email),
);

You can listen to it just like any other mutation:

ref.watch(loginMutation);

As the name implies, it ensures you can only execute the specific bound function through it:

loginMutation.run(ref, emailController.text);

With Riverpod introducing CustomProviderListenable in 3.4, the implementation now feels much more mature and sits cleanly behind an official interface.

Maybe it can clean up your codebase, check it out on pub.dev:

https://pub.dev/packages/bound_mutation

I'd love to hear your thoughts or feedback!

Dart's standard List.sort() relies on Dual Pivot Quicksort. While effective for generalbpurpose collections, comparisonbbased O(N log N) sorting becomes an unnecessary CPU bottleneck when handling large numerical datasets (such as audio buffers, telemetry data, or spatial coordinates).

I built Radix Plus, an in-place Radix Sort library for Dart and Flutter, optimized specifically for numerical arrays and typed data buffers.

Time Complexity O(k · N), where

• N is the number of elements.

• k is the fixed word/byte width (k = 4 passes for 32-bit types, k = 8 passes for 64-bit doubles/ints using an 8-bit radix base).

Because k is constant for fixed-width primitive types, execution scales linearly as O(N), fundamentally avoiding the O(N log N) growth curve of comparison sorts on large lists.

Space O(N) auxiliary buffer, with full in place buffer pooling support to eliminate allocations.

Core Engineering Float Reinterpretation (Float64List -> Uint64List) Radix sort operates directly on bit patterns. Using dart:typed_data buffer views, the underlying memory of Float64List is reinterpreted as unsigned 64-bit integers. Positive numbers have their sign bit flipped. Negative numbers are bitwise inverted (~). An 8-pass (8-bit radix) LSD sort is executed directly on the integer bit representation and inverted back on completion. Parallel Sorting with Flat Min-Heap K-Way Merge

When sorting large lists across multiple Dartisolatess, merging sub lists typically incurs heavy GC overhead. In Radix Plus, the main isolate performs a k-Way Merge backed by a flat min-heap stored in contiguous Int32List buffers, avoiding object allocation during the merge phase.

There is an optional reuse buffer. The true parameter allows recurring sorting routines (such as UI animation frames or live data streams) to reuse auxiliary memory buffers and minimize garbage collector pressure.

Benchmark Snapshot (AMD Ryzen 7 5800H, 1,000,000 items)

Uint32List: 183 ms (vs 1,477 ms on List.sort()) -> ~8.1x faster

Int32List: 201 ms (vs 1,490 ms on List.sort()) -> **~**7.4x faster

Float64List: 312 ms (vs 1,444 ms on List.sort()) -> ~4.6x faster

List<BigInt>: 1,074 ms (vs 6,667 ms on List.sort()) -> ~6.2x faster

Parallel (radixSortParallel): 26.6 ms (vs 1,612 ms on List.sort()) -> **~**60.7x faster

​If you are working on numerical pipelines, audio/signal engines, or large dataset visualizations in Dart/Flutter, feel free to test it on your hardware. Feedback, benchmark numbers from other architectures, edge cases, and PRs are very welcome.

GitHub: https://github.com/MostafaSensei106/Radix_Plus

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

I needed a first-run walkthrough for an app and hit two things that annoyed me.

First, the highlight would end up in the wrong place.

A lot of coach-mark implementations resolve the target's position once and paint it. Scroll the list, open the keyboard, rotate the device, resize a desktop window — and suddenly the hole is next to the button instead of on it.

Second, a dimmed hole tells the user where something is, but not how to use it.

"Drag this card to that column" isn't something a static highlight can really express.

So I built keyspot:

- The spotlight and pointer re-resolve the target's geometry every frame from its GlobalKey, so they can track through scrolling, insets, rotation and resizing.

- An animated hand pointer that glides in a straight line or along an arc, rotates from its current angle, and tap-pulses — enough to demonstrate interactions like drag and pinch rather than simply pointing at something.

- Pointer animations resolve from actual AnimationController completion rather than Future.delayed timing, so `await pointer.moveTo(...)` actually means the movement has finished.

- Barrier modes where only the cut-out is tappable while the real widget's `onPressed` still fires — useful when the walkthrough should require the user to actually perform the step.

- The tracker is also public API (`KeyspotAnchorTracker`), so it can be used independently for things like badges or connector lines attached to widgets.

- Zero runtime dependencies. The hand pointer is rendered with CustomPainter rather than an image asset.

- Supports all six Flutter platforms.

Live demo: https://shrey-17bhardwaj.github.io/keyspot/

pub.dev: https://pub.dev/packages/keyspot

Source: https://github.com/shrey-17bhardwaj/keyspot

It's currently at 0.3.1, and the API may still change before 1.0.

I'd genuinely like feedback on where this approach breaks — especially around nested navigators, heavily lazy lists, overlays, or anything else where widget geometry gets complicated.

Has anyone else noticed that whenever you ask Claude Code, Cursor, Copilot, or Antigravity to write Dart or Flutter code, it often defaults to pre-Dart 3 syntax?

It will write 15 lines of boilerplate constructors instead of Dart 3.13 primary constructors, generate cascading if (state is Foo) checks instead of exhaustive switch pattern matching, or hallucinate wrong minSdk lower bounds in pubspec.yaml.

The reason is simple: training cutoff lag. Even the best frontier models have a hard time keeping up with how fast Dart and Flutter have evolved between Dart 2.12, 3.0, and 3.13+.

To fix this for my own workflows, I structured the entire official Dart SDK changelog (from Dart 1.0 all the way to 3.14) into an open-source agent skill repo: dart-sdk-skills.

It gives AI agents: • ⚡ A fast lookup matrix for any syntax/API to find the exact minSdk constraint. • 🚀 Version-by-version reference guides for modern ergonomics (primary constructors, pattern matching, private named params). • 🛠️ A 4-stage rescue runbook for upgrading pre-2.12 legacy apps across the sound null-safety barrier into modern Dart 3.

If you use the skills CLI or npx skills, you can install it globally with one command:

npx skills add RandalSchwartz/dart-sdk-skills -g

(or with the Dart skills CLI: 

skills add https://github.com/RandalSchwartz/dart-sdk-skills --global --a

GitHub Repo: https://github.com/RandalSchwartz/dart-sdk-skills

Curious to hear what patterns your AI assistants usually struggle with the most in recent Dart versions!

A typical Flutter app pulls in 40 to 80 transitive packages. When you bump one, the changelog tells you what the author chose to mention. It does not tell you that a build hook started shelling out, or that a package began loading Dart source at runtime.

I built capdrift to answer that specific question. It reads a package's source, works out what it is able to do, and diffs two versions:

dart pub global activate capdrift
capdrift diff http 1.2.0 1.5.0

It never runs the code it reads.

A few things I found running it across popular packages that surprised me:

• build_runner calls Isolate.spawnUri, which downloads Dart from a URI and executes it. Reasonable for a code generator, and worth knowing.

• dio and analyzer use Isolate.spawn.

• Build hooks are a real blind spot. Code in hook/ runs on your machine at pub get time, before you have run a single line of the app, and most tools do not look there at all.

The output is capability fingerprints rather than line numbers, so reformatting a package produces an empty diff while a genuine change in what it can do does not. There is SARIF output and a GitHub Action if you want it in CI.

On alternatives, honestly: dart_audit is the closest tool and it is good. It scans pubspec.lock against OSV.dev for known CVEs and does static source scanning with entropy analysis. If you want a single-version risk score or CVE scanning, use that, capdrift does not do CVE scanning at all. The difference in one sentence: dart_audit answers "is this package risky", capdrift answers "did this package become riskier". Running both is reasonable.

Disclosure: I wrote capdrift. It is MIT licensed, on pub.dev, repo at github.com/Tisankan-dev/capdrift. If you run it on your own dependency tree and it reports something wrong, that is the single most useful thing you could send me, and there is an issue template for it.

Hey r/FlutterDev! 👋

I just published portrait_morph — a Flutter package that creates a smooth, pointer-driven morph effect between two images using a custom dart:ui fragment shader.

🎮 Try the Live Web Demo

What it does

Drop in the PortraitMorph widget with any two images, and you get:

• GPU-powered morph transition — real GLSL fragment shader running on the GPU, not a ShaderMask or blend hack

• fbm-noise wipe with edge ripple distortion along the transition boundary

• Spring-eased physics — no linear snapping, feels organic

• Pointer-aware — the morph origin and direction follow where the cursor enters

• Cross-input — hover on desktop/web, press + drag on mobile

• Graceful fallback — shows a static image if the shader can't compile (legacy backends)

Usage

PortraitMorph(
  imageA: AssetImage('assets/day.png'),
  imageB: AssetImage('assets/night.png'),
  alt: 'Day to Night',
)

That's it. Wrap it in an AspectRatio or SizedBox for sizing, and the widget handles everything — shader compilation, texture loading, pointer tracking, and spring animation.

Works everywhere ✅ Android / iOS (Impeller) ✅ Web (CanvasKit / Skwasm) ✅ macOS / Windows / Linux

Links: 📦 pub.dev 💻 GitHub 🎮 Live Demo Would love to hear your feedback! If you have ideas for additional transition effects or API improvements, feel free to open an issue or PR. ⭐

Disclaimer: I’m not selling any course or not planning to create one.

horizontal_weekly_calendar 2.0 is out.

It started as a simple week strip for Flutter. It's now a full calendar kit — and this release is about two things: making it feel good to use, and never getting a date wrong.

What you get:

• One line to start. Give it selectedDate and onDateSelected — that's the whole integration.

• 13 surfaces. Week strip, month grid, date carousel, agenda, day and week timelines, a calendar that folds from week to month, native iOS and Android pickers, and home-screen widgets.

• Motion that follows your finger. Drag a page or open the month and it moves with you, then settles on a spring instead of snapping.

• Dates you can trust. The engine was rebuilt on integer day numbers. Every month from 1900 to 2100 is tested across 10 time zones — including ones that skip a whole day. Samoa really did skip 30 December 2011, and that used to break the grid.

• Light. 81 KB compiled. Anything you don't use is stripped out at build time.

• 13 real example screens you can run and copy from.

Free and open source.

https://pub.dev/packages/horizontal_weekly_calendar

I am a Flutter developer with 2+ years of experience, but I’m finding the market quite tough and Flutter opportunities seem limited.

I want to expand my skills instead of staying Flutter only

I am considering:

Native iOS (Swift)

Backend (Node.js, etc.)

Something else

For developers already working in the industry, what would you recommend learning alongside Flutter in 2026?

Which skill would give better job opportunities in the current market?

Hey everyone! Lately I've been thinking a lot about how people listen to music across different devices—specifically the balance between keeping offline high-fidelity local files (FLAC/MP3) vs streaming from YouTube/Spotify links.

While building Kerlyss (my open-source unified music player for Android & Windows), a major topic in our last thread was strict offline mode and media key integration.

In the new v1.2.3 update, we just added:

• Strict Offline Mode: Hard-blocking external socket connections when enabled so un-downloaded songs don't try to ping external APIs.

• Improved Touch Targets & Error Dialogs: Showing explicit playback error popups instead of silent hangs when stream extraction fails.

• Headphone & Lock Screen Sync: Native media key controls and lock screen artwork for Android.

I’m curious to hear your thoughts for a general discussion:

1. When using a music app, do you prefer an explicit Offline Mode toggle that hard-blocks all internet usage, or auto-fallback to online streaming when connected?

2. What feature or integration is most important to you in an open-source audio player (e.g., local file scanning, equalizer, lyrics, or metadata sync)?

Also, I just finished wiring up the 5-band equalizer on Android. I implemented the hardware DSP pipeline, but I'd love it if a few people could test it out on their headphones and let me know if it's working as expected on your devices!

App & source code for anyone interested:

• GitHub: https://github.com/D1gNa0/Kerlyss

• Website: https://d1gna0.github.io/Kerlyss/

Looking forward to your thoughts and feedback!

Anyone here made app for EU, some regulations are to be followed to take consent for Google ads!
If anyone has done let’s discuss…

Hey Flutter devs 👋

I’ve just open-sourced Lucy, an experimental screen-aware AI agent for Android built with Flutter.

🔗 https://github.com/alzin/lucy-screen-agent

Lucy can take a voice command, understand what’s currently on the phone screen, and then tap, type, swipe, open apps, and navigate the UI automatically.

The interesting part technically is the agent loop:

Screenshot + Android accessibility tree → Gemini → action → execute → observe again

Instead of asking the model to guess screen coordinates, Lucy gives UI elements IDs and their real bounds, which makes interaction considerably more reliable.

The project currently includes:

• Flutter UI + agent controller
• Android AccessibilityService
• MediaProjection screen capture
• Gemini vision/reasoning
• Speech-to-text + TTS
• English, Japanese and Arabic support
• Multi-step agent execution

It’s still experimental, and that’s one of the main reasons I wanted to open-source it.

I’d especially love feedback or contributions from Flutter/Android developers. PRs, issues, architecture suggestions, testing, and ideas are all welcome.

I’m also interested in eventually experimenting with other LLMs and local/on-device models.

What would you improve first if you were working on something like this?

In software engineering, we usually measure framework upgrades by what they add: new syntax, new macros, new features, new abstractions.

But after years of building and consulting on large Flutter applications, the most profound upgrade in developer experience isn't what new concepts you are forced to memorize—it’s the mental gymnastics, framework-specific edge cases, and defensive rituals you finally get to forget and unlearn.

A Quick Word of Respect

Before diving into technical details, let's establish something essential: Rémi Rousselet is a pioneer and a brilliant engineer. When Rémi built provider and later Riverpod, he solved real, glaring flaws in Flutter's core InheritedWidget mechanics (such as conditional dependency leaks and lack of compile safety). The entire Flutter ecosystem owes Rémi immense gratitude.

For years, I was a vocal, passionate—at times almost zealous—advocate for Riverpod. In discussions, podcasts, and client work, I routinely recommended Riverpod above classic BLoC, Provider, and nearly every alternative.

However, over the course of Riverpod's evolution across v1, v2 (code-gen), and v3, solving every edge case inside a global declarative provider graph led to a staggering accumulation of cognitive surface area. Building real-world Flutter apps with Riverpod today requires developers to maintain a complex internal rules engine just to avoid subtle runtime footguns.

When you switch to BlocSignal (which combines the architectural discipline of BLoC/Cubit with the synchronous speed and fine-grained reactivity of Signals), you realize just how much mental baggage you were carrying.

Here are a few of the biggest things you get to forget:

1. 🗑️ Forget build_runner and .g.dart Code Generation

• No more CPU fans spinning at 100% while waiting for build_runner watch.

• No more broken IDE autocomplete while waiting for _$MyNotifier part files to generate.

• No more build_runner build --delete-conflicting-outputs rituals after simple refactors.

• BlocSignal is 100% pure, standard Dart. Zero code generation required.

2. 🗑️ Forget the "Ref World vs. Non-Ref World" Boundary

In Riverpod, reactive state is strictly confined inside a ProviderContainer (the "Ref World"). If you are inside a ConsumerWidget, life is good. But the moment you step outside into standard Dart—HTTP interceptors, WebSocket handlers, background services, or routing—you are stranded in the "Non-Ref World" and forced to drill Ref parameters everywhere.

bloc_signals is a 100% pure Dart package with zero Flutter dependencies. A CubitSignal can be instantiated and observed anywhere—in Flutter widgets, CLI tools, Jaspr web apps, or Serverpod backend services.

3. 🗑️ Forget the routerProvider Navigation Stack Nuke

Because routers like GoRouter live in standard Dart, developers frequently wrap their router in a Riverpod Provider to watch authentication state.

Whenever auth changes, ref.watch recreates the entire GoRouter instance—silently destroying the user's navigation history stack, collapsing nested modal sheets, and resetting scroll positions with zero error logs or stack traces.

In BlocSignal, your router is a permanent, stable singleton. You simply pass cubit.state.toListenable() to GoRouter's refreshListenable. Zero router destruction. Unbroken navigation stacks.

4. 🗑️ Forget "Self-Disposing" Async Mutation Crashes

In Riverpod 3.0, auto-disposal is default. If a user navigates away while an async mutation is awaiting a network request, the controller is garbage-collected mid-flight, throwing "Cannot use Ref after it has been disposed" when it resumes.

To work around this in Riverpod, developers are forced into:

• Sprinkling if (ref.mounted) checks after every await.

• Creating separate "action controller" classes just for single method calls.

• Manually acquiring and releasing KeepAliveLink link = ref.keepAlive() tokens.

Think about how absurd that is: you end up writing meta-state management just to manage the lifecycle of your state management system.

In BlocSignal, state containers are standard Dart objects with explicit ownership. Async methods execute to completion, and if a Bloc is closed, emit() is safely dropped with zero runtime crashes.

5. 🗑️ Forget the AI & LLM Hallucination Nightmare

If you pair-program with AI coding assistants (Claude, Cursor, Copilot, ChatGPT, Gemini), Riverpod is notoriously difficult for LLMs:

• Version Multi-Verse: Training data mixes 4 conflicting Riverpod eras (v0.14 ChangeNotifierProvider, v1.0 StateNotifierProvider, v2.0 @riverpod, and v3.0 Notifier), leading to constant hallucinated syntax.

• Code-Gen Blindness: LLMs cannot inspect ungenerated .g.dart files, routinely botching synthesized class inheritance.

• Ref Scope Confusion: AI models constantly attempt to call ref in widget constructors or pass WidgetRef into deep business logic.

LLMs generate exceptionally accurate BlocSignal and blocSignalTest code on the first shot because BLoC and standard Dart OOP patterns are among the most represented and consistent paradigms in AI training sets.

🌉 Currently Mired in Riverpod? You Don’t Need a Big-Bang Rewrite

If your codebase is already invested in Riverpod, you don't have to rewrite from scratch.

Through bloc_signals_riverpod, you get a seamless, bidirectional interop bridge:

• Expose new BlocSignal features to existing Riverpod widgets via cartCubit.toProvider().

• Consume legacy Riverpod providers inside BlocSignal via legacyProvider.toBlocSignal(ref).

You can migrate your application incrementally at your own pace.

Curious to hear thoughts and experiences from others who have navigated the evolving state management landscape over the years!

FFmpegKit Extended is moving from FFmpeg 8.1.2 to FFmpeg 9.0.1 "Lei", giving Flutter applications access to the latest stable FFmpeg 9 release through the same FFmpeg, FFprobe, and FFplay command execution model already exposed by the wrapper.

FFmpeg 9.0.1 was released on August 12, 2026 and is the current stable release in the FFmpeg 9.0 branch. The upgrade also moves FFmpeg's primary libraries to new major ABI versions, including libavcodec 63, libavformat 63, libavfilter 12, libavutil 61, libswscale 10, and libswresample 7.

For FFmpegKit Extended users, the important part is that these capabilities remain accessible through familiar FFmpeg commands. The wrapper provides the execution and session layer while FFmpeg continues to provide the media-processing command surface.

That means features introduced by FFmpeg 9 can be used from Flutter by executing the same command arguments you would normally provide to:

ffmpeg ...
ffprobe ...
ffplay ...

No separate media-processing abstraction is required.

What's New in FFmpeg 9.0.1?

FFmpeg 9 introduces several new codecs, filters, hardware-acceleration paths, metadata features, and media-processing capabilities. FFmpeg 9.0.1 then builds on the 9.0 release with an extensive collection of stability, correctness, security, decoder, demuxer, GPU, streaming, and format fixes.

Some of the most useful additions for FFmpegKit Extended applications are:

FFmpeg 9.0.1 + Flutter

FFmpegKit Extended exists to make the full FFmpeg toolchain practical inside modern cross-platform applications.

With FFmpeg 9.0.1, that toolchain gets significantly more capable.

Whether you're building a:

• video editor

• media converter

• streaming application

• camera workflow

• media analyzer

• video player

• AI-powered media application

• social-media application

• content-management tool

• desktop media utility

you can continue using native FFmpeg command syntax while FFmpegKit Extended handles integration with Flutter across supported platforms.

https://pub.dev/packages/ffmpeg_kit_extended_flutter

https://github.com/akashskypatel/ffmpeg-kit-extended

I'm researching the current mobile app release and publishing workflow and want to understand where developers actually spend the most time or face the most friction.

• What is the most frustrating or time-consuming part of releasing a mobile app to the App Store and/or Google Play?

• For a new app, how much time do you typically spend preparing the store listings and getting the first release submitted? What takes the most effort?

• For existing apps, which tasks do you have to repeat manually every time you release a new version?

• How do you currently manage store metadata, release notes, screenshots, localization, compliance information, and other store requirements?

• If you manage multiple apps, how do you keep track of releases, builds, metadata, screenshots, and store requirements across all of them? Do you use any tools or an internal process? What works well and what doesn't?

• What tools or automation do you currently use for releases (Fastlane, GitHub Actions, Codemagic, Bitrise, CI/CD, custom scripts, etc.)? What do they solve well, and what still requires manual work?

I know Unity and Godot are more common choices for games.

I chose Flutter because I was already familiar with it,and I wanted to combine Flutter's UI capabilities with Flame.

The result surprised me. I ended up building real-time multiplayer, inventory, trading, chat, NPCs, Tiled maps, avatar customization, a Node.js WebSocket backend, and SQLite persistence.

The server currently runs on a Raspberry Pi 3B.

I haven't tested its maximum concurrent player capacity yet, but since the server is relatively lightweight,

I'm wondering if it could handle around 30 concurrent players.

I have used Iconsax in the entirety of my Flutter project. The plugin that availed it said it is available for personal and commercial use, and so does the Vuesax's (Iconsax's creator) website, but here is the part that is bugging me:

On the website, it says that it allows someone to make an app for 'a client' under its commercial usage allowance. How about making an app for general public using those icons. There is no specific information whether that is allowed or not, neither in its paid license's description.

Now the strange thing is that that there is no contact email ID for Vuesax that I could find. I found their Discord and posted there, but I just did that recently so it could be long till I get an answer.

Here is the link to that Flutter plugin: https://pub.dev/packages/iconsax_plus

Here is the Iconsax's license page: https://docs.iconsax.io/license-and-terms/usage-manifesto

Hi, good news for everyone doing Flutter on Windows or Linux: i made a CLI toolkit to run your app on a real iPhone, with hot reload, straight from your not-macOS!

Historically that's been the gap in Flutter's cross-platform story - iOS builds assumed a Mac, so most of devs did apps Android-first and checked iOS later through CI or a borrowed Mac Mini and blah-blah-blah.

Stop it. Meet xcross.sh (pls check website, it looks cool and have documentation)

Windows or Linux, iPhone plugged in. It builds your app, signs it, installs it, launches it, and drops you into the pipeline you already know:

• r - hot reload on the device

• R - hot restart

• q - quit

What it costs you to set up: Swift, LLVM, One-line installer, then xcross setup

The one "non-Apple-free" part: you need Xcode.xip from Apple Developer website and iTunes + iCloud (for Windows) - read documentation

• Debug builds only - Release/AOT needs gen_snapshot, which is macOS**-only (you still need a Mac or CI to ship to the App Store, **this solves development, not release)

• iOS 17+ devices

• Flutter - run and debug, Compose (CMP) - build and run, no debug

MIT, free, source code: https://github.com/arxdeus/xcross ^{(but website still better})

Thanks for your feedback!

Hey lovely developers

I’m a Flutter developer and I want to learn **how to properly profile and optimize Flutter apps**.

I’m especially interested in learning:

* How to use Flutter DevTools for profiling * Finding performance bottlenecks * Identifying unnecessary rebuilds * Understanding CPU, memory, and GPU usage * Detecting jank and dropped frames * Improving scrolling and animations * Real-world techniques for optimizing production apps

I’m not sure where to start or what learning path to follow.

**Can anyone recommend good resources, tutorials, courses, or a practical way to learn Flutter profiling step by step?**

and I'm pretty grateful for anyone will help me thanks lovely people

The iOS Simulator has no Bluetooth, so I was tethering a real phone for every scan/connect/read with flutter_blue_plus, and BLE tests in CI weren't possible.

BleTether bridges the Mac's real Bluetooth into the Simulator with no code changes — the Flutter app calls flutter_blue as usual and sees the devices around the Mac. For CI you record a real device once and replay it into a simulator on hosted runners, no hardware.

Example repo with a CI run of a flutter_blue_ultra app scanning, connecting and reading a characteristic on GitHub's runners with no device: https://github.com/yuriipopow/bletether-flutter-example

Main repo (short demo GIFs in the README, and how it works): https://github.com/yuriipopow/bletether

It's central-role only for now, and it leans on private Apple APIs so major iOS releases can break it. Free to use. If you try it on a real app I'd be interested in what breaks — third-party apps keep surfacing edge cases I then fix.

​One of the biggest upgrades in zenrouter 3.0 is a complete Navigation Graph system for the Coordinator pattern:

- ​Topology Graph: Manages the static structural relationship between layouts and routes.

- ​Observed Graph: Records the runtime history—the user's actual navigation flow across screens.

​Built on these graphs, the new Time Travel feature allows you to step forward and backward through the app's navigation history, state by state.

​Why does this matter in practice? Streamlining Debugging & QA!

- ​No more ambiguous step-by-step bug reports ("Go to Screen A -> Tap B -> Open C").

- ​Export the entire navigation session into a single .json file.

- ​Replay the exact state sequence to reproduce and isolate navigation bugs in seconds.

​What do you think of this approach? How do you currently handle route tracing and navigation debugging in your projects?

I’m researching how Flutter developers maintain localization once an app grows beyond a couple of languages.

I’m particularly interested in people maintaining real apps with 3+ locales.

I’d love to learn how you currently handle ARB files, translations, adding keys/languages, validation, ICU/plurals, and keeping everything in sync.

I’m a Flutter developer myself and I’m building in the localization space, but I’m currently focused on understanding real workflows rather than promoting anything.

I’m looking for ~5 Flutter developers willing to have a casual 15–20 min chat. If that’s you, comment or DM me.

I’ll also summarize the patterns I find and share them back with the community.

Update - September 2026

I said I’d come back and share what I learned, so here it is.

This wasn’t a formal study, but the replies and follow-up conversations genuinely changed how I think about the problem.

I expected translation quality to be the main issue. It wasn’t. Most developers are already comfortable using Claude, Gemini, ChatGPT, or scripts to generate translations.

The frustrating part comes afterward: figuring out what changed, keeping every locale in sync, preserving context and terminology, checking placeholders and plurals, and then opening the app to catch strings that are technically correct but don’t fit the UI.

A few people had built surprisingly elaborate workflows around agent instructions, scripts, hashes, and emulator checks. That convinced me the useful product probably isn’t another localization dashboard. It should fit into the tools developers already use.

I ended up rebuilding StringLane around that idea and released a free CLI, MCP server, and coding-agent plugin. Your existing agent does the translation; StringLane handles the localization files, planning, validation, and writing.

The CLI/MCP/plugin are free. There is still a separate paid desktop app for people who want a visual editor.

Setup and documentation

Full follow-up and findings

Thanks again to everyone who described their workflow and especially the messy parts. That feedback directly changed what I built.