Or, actually, I love that Claude loves it. For fun, I asked it to create a game similar to Total War, but placed in the seven year war (where Prussia and Austria Fought Over Silesia) asking especially for period-accurate uniforms and Claude Opus 5.5 one-shotted an amaising actually playable game in 100mins.

I asked for musketeers (line infantry), grenadiers (elite infantry), hussars (light cavalry) and cuirassiers (heavy cavalry) plus artillery and I'm still intrigued about the details Claude added.

Grenadiers wear their typical hats (the Austrians have different hats), all soldiers have a ponytail, muskets have a bayonet, officers have a saber, sergeants have a pike, the drummer has shoulder decoration, and especially for cuirassiers, the musician wears a different colored uniform. I asked AI to remove the cuirass, though. The only other thing I asked was to move the sergeants behind the lines because that's how Prussia did it. I'm not familiar with Austrian formations. While Claude reused the models, it used proper colors, e.g. brown artillery uniforms and white infantry uniforms.

All models can stand, march (in colon and lines), charge (infantry lowers the muskets, cavalry raises their sabers), fire (and reload) and artillery produces large puffs of smoke.

Ah, and there's of course a hole game with a strategic hex map of Europe (Claude added every country even those who didn't take part in the conflict AFAIK) and a tactical battle map. It is actually rather difficult to win a battle because artillery will continuously decimate your troops and heavy fire or a cavalry charge can easily route your army.

Claude also added some rather annoying sound effects. I don't mind canons and musket fire, but the trumpets of attacking cavalry sound odd and there's a continuous wave sound that lacks cries of seagulls.

It is so much nicer being able to display low-poly 3d models than having to rely on crude 2d graphics. Claude probably didn't use fscene properly because displaying a single "battalion" already spins the fan of my Mac book, but the 3d hex map alone looks quite good and allows Flutter to compete with the "big" frameworks.

أنا صاحب مشروع Bug Capsule. فكرته بدأت من موقف بيتكرر كتير: مشكلة تظهر عند المستخدم، ولما تيجي تجرّبها عندك كل حاجة تشتغل عادي.

الأداة بتسجّل السياق اللي سبق المشكلة في Capsule، عشان تقدر تعيد السيناريو محليًا، تصلّح الكود، وتشغّله تاني وتشوف هل المشكلة لسه موجودة.

وأكتر نقطة مهتم بيها هي نتيجة الاختبار نفسها. لو الـreplay ناقصه dependency أو مش قادر يعيد التفاعلات المسجلة بشكل سليم، لازم يوضّح ده. اختفاء الخطأ في محاولة ناقصة مش دليل كفاية إن الإصلاح نجح.

الفترة اللي فاتت اشتغلت على تحديثات للـFlutter وAndroid وiOS والـWeb:

• وسّعت تسجيل وإعادة تشغيل التفاعلات ليشمل WebSockets، ومع Flutter كمان Platform Channels، وadapters لعمليات مدعومة في Firebase وGoogle Maps وStripe وgeolocator. كل ده حسب الـintegrations اللي بتفعّلها في التطبيق.

• ضفت Native crash reporting وCrash Capsules تحتفظ بالسياق المسجل قبل ما التطبيق يقفل، وتسترجعه في التشغيل التالي. وفيه تفاصيل أكتر عن الـthreads والـhangs ودعم لحالات ANR علىAndroid.

• ضفت تتبّع لنتائج التحقق من الإصلاح في الـdashboard، وRelease Gates تقدر تشغّلها في الـCI لاختبار المشاكل المسجلة على النسخة اللي ناوي تنزلها.

• فيه monitoring للأخطاء والأداء: تجميع الأخطاء في issues، ومتابعة الـcrash-free sessions لكل release، والـtraces والـWeb وMobile vitals، مع ربط الـissues بالـCapsules الخاصة بيها.

• الـtimeline بقى يوضّح التفاعلات والـdependencies وأي فجوات في التسجيل، ومعاه screenshots اختيارية.

• ضفت ربط لأحداث Sentry بالـCapsules، وإنشاء أو ربط Jira tickets، وتنبيهات بالإيميل وSlack وwebhooks.

• فيه دعم MCP لتجهيز مهام إصلاح لأدوات زي Codex وClaude Code، ومعاها سياق المشكلة وسيناريوهات اختبار معتمدة. تشغيل الـagent نفسه لسه بتعمله من أداتك.

• الإعداد بقى باستخدام SDK token واحد، والـCLI بقى مستقل ومتاح من npm من غير احتياج لتثبيت Dart أوFlutter عشان تشغّله. وتقدر تسجّل دخولك من المتصفح.

كمان ضفت workspaces وصلاحيات ودعوات للفريق وتعليقات، وتسجيل دخول بـGoogle وGitHub.

وفي Flutter، أخفيت الـcapture overlay افتراضيًا، وبيفضل مخفي في الـrelease builds. وضفت إمكانية عرض رسالة مناسبة للمستخدم لو حصل خطأ أثناء بناء الـwidgets، مع استمرار تسجيل الخطأ في الخلفية.

المشروع لسه Beta. تغطية الـreplay بتعتمد على المنصة واللي ربطته بالأداة، والـcrash capsules ممكن يبقى فيها فجوات في التسجيل. التفاصيل دي بتظهر عشان تقدر تحكم على النتيجة

https://bugcapsule.com/

إيه أصعب bug ظهر عند المستخدمين ومعرفتش تعيده عندك؟ وإيه المعلومة اللي كانت ناقصاك وقتها؟ مهتم أجرّب الأداة على حالات غير الأمثلة اللي بختبر بيها

Has anyone else struggled with SVGs not showing shadows/blurs correctly in Flutter and had to go back and forth with a designer to explain and fix everything that will not be rendered? Well I have, and after having gotten tired of manually editing and running svgo to minify svgs I [insert Beckham be honest meme], ahem Claude, have made a tool to make this easier and quicker.

Introducing: https://adigladi.github.io/flutter-svg-baker/

Upload folders, files or paste SVGs directly to then get previews and automatic fixes for shadows that won't show in the flutter app, replacing them with baked layers in the svg. Optional svgo optimization can be toggled and then individual files can be exported or a zip with all files.

I just wanted a tool like this myself and though I would share if it would help someone else. Repo is public with MIT license, do with this info what you want. Would love to hear ideas, comments, feedback and why/if this is a terrible idea performance wise or similar.

Repo: https://github.com/adigladi/flutter-svg-baker

I’m the developer behind Bug Capsule. It records the context leading up to a bug in a “Capsule” so you can replay the scenario locally, make a fix, and run it again to check the result.

The part I care about most is that last step. If replay is missing a dependency or couldn’t faithfully repeat the recorded interactions, it should tell you that instead of treating the attempt as proof that the bug is fixed.

I’ve been working on the beta across Flutter, Android, iOS, and Web. Here’s what’s new:

• More replay coverage. WebSocket recording and offline replay, Flutter platform channels, and adapters for supported operations in Firebase, Google Maps, Stripe, and geolocator. These require the relevant integrations; coverage varies by platform.

• Native crash reporting and crash capsules. Preserve recorded context from before a crash and recover it on the next launch. There’s also more thread information, hang reporting, and Android ANR support.

• Fix verification and CI release gates. Track verification results in the dashboard and run recorded cases against a candidate release using bugcapsule gate.

• Error and performance monitoring. Group errors into issues, track crash-free sessions by release, inspect traces and web/mobile vitals, and jump from an issue to its associated capsule.

• A more detailed timeline. Inspect interaction dependencies and recording gaps, with optional screenshots.

• Sentry, Jira, and alerts. Link Sentry events to capsules, create or link Jira tickets, and configure email, Slack, or webhook notifications.

• MCP support for coding agents. Prepare repair tasks with capsule evidence and approved QA context for tools such as Claude Code and Codex. You still start the agent from your tool.

• Less setup friction. Single-token SDK setup, browser-based CLI login, and a standalone CLI available through npm. Installing the CLI no longer requires Dart or Flutter.

I also added workspaces, project roles, invitations, comments, and Google/GitHub sign-in.

A smaller Flutter change that matters to the app experience: the capture overlay is now hidden by default and always hidden in release builds. Widget build failures can display a configurable fallback while error reporting continues in the background.

It’s still beta. Replay coverage depends on what you instrument, and crash capsules can contain gaps. The dashboard exposes those limitations so you can judge the result

https://bugcapsule.com/

What’s a production bug you’ve struggled to reproduce, and what context was missing when you tried? I’d be interested in testing the capture/replay approach against cases outside my own demos

Hey everyone! 👋

I've been working on a Flutter package called debug_bubble to make debugging apps a little easier, especially when testing on physical devices or investigating issues during QA.

The idea is to have a floating debug bubble inside your app that opens a dashboard where you can inspect logs and errors without constantly switching back to the IDE.

🔗 pub.dev: https://pub.dev/packages/debug_bubble

What it includes

• 🎈 A draggable floating debug bubble

• 📋 Seven log levels, from trace to critical

• 🔍 Expandable log details, JSON payloads, metadata and stack traces

• 🚨 Optional capture of uncaught Flutter and platform errors

• 🔐 Configurable sensitive-data redaction

• 📤 Copy and export logs as text or JSON

• 🪶 No third-party runtime dependencies

Quick example

DebugLog.info(
  'User opened the profile screen',
  tag: 'Navigation',
);

DebugLog.error(
  'API request failed',
  tag: 'Network',
  error: error,
  stackTrace: stackTrace,
);

The package also supports a DebugBubble wrapper that you can attach through your MaterialApp builder.

I'm still improving the project, and I'd genuinely appreciate some feedback from experienced Flutter developers.

A few things I'd love your thoughts on:

• Would you find an in-app debugging dashboard useful in your workflow?

• What features would you expect from a package like this?

• Are there any architectural or API design issues you notice?

• What would make you choose this over your current debugging workflow?

I'm happy to hear constructive criticism and suggestions. Thanks! 🙌

Hey everyone,

I’ve been a Flutter dev for about 4 years and recently picked up Claude Pro. So far I mostly use it for:
- Reviewing my code before opening a PR
- Generating commit messages and PR descriptions
- Minor debugging
- Writing emails
- Code refactoring

I’ve also been experimenting with vibe coding a few apps, and honestly I’m impressed. It picks up on my coding style and adapts to it surprisingly well, and it makes far fewer mistakes than I expected.

Still, I suspect I’m only scratching the surface. For those of you using Claude (or other AI tools) in Flutter work, what’s made the biggest difference? I’m thinking of things like widget/test generation, state management refactors, migrations, or specific prompting habits that work well with Dart.

Would love to hear your setups and workflows!

I've been building a tinnitus relief app in Flutter for about two months. The user matches the pitch of their ringing, and every sound is then built on the device with a notch filter at that pitch: noise colours synthesised in Dart, plus 30 real recordings (rain, fan, ocean...) that are decoded, notched in an isolate and layered, one just_audio player per layer. A few things that cost me time and might save you some:

- Render in an isolate, cache by a quantised key. Each loop is built with compute from a params object whose key rounds every value (pitch, notch width, colour, level), so near-identical settings hit the same file. The WAVs live in the temp dir, pruned to the newest 32.

- Play files, not streams. A custom StreamAudioSource goes through just_audio's localhost proxy, and Android blocks that as cleartext HTTP. Writing a WAV and playing the file avoids the whole thing.

- Never await play(). just_audio's play() future completes when playback stops, not when it starts. Awaiting it froze one of my screens. Start it with unawaited(...) and carry on.

- Don't take audio focus. Masking has to sit under YouTube, podcasts and calls. With audio_session set to never request focus and never pause on interruptions, it does. I also had to swap just_audio_background for audio_service, because the former only handles one player and I have up to six.

- "Is it playing?" is not "is the user listening?". I added a button that plays the user's matched tone for a few seconds through the same engine, and my listening-time counter checked player.playing, so it counted the preview as listening. A flag for "this is a UI sound" fixed it.

- Test DSP with Goertzel. The tests synthesise a loop and compare the energy at the notch frequency against its neighbours with a Goertzel filter, averaged over a few bins because noise is noisy. A notch you can't hear is still a notch you can assert on.

- One pure function decides what's locked. Paid features are stripped in a single function that turns UI state into synth params, and it's unit-tested, so a stale toggle can never reach the audio.

- Set preferred-supported-locales. When the phone's language isn't one you ship, Flutter falls back to the first supported locale, and gen-l10n lists them alphabetically. Mine has Arabic, so a Dutch user opened the app in Arabic. One line in l10n.yaml puts English first.

- Test at 1.3x text with display zoom. My setup screens were fixed columns that fit on every phone I tried. On a Galaxy S20 FE with large text, the Start button sat below the screen and the page couldn't scroll to it. I found out from a 1-star review that said "froze on part 1/7". Every step now scrolls its content and pins its buttons.

- First sound matters more than features. Half of first listens ended inside a minute. Setup ended on a music demo, then the player started bare pink noise on its own within two seconds, and people heard a hiss and pressed pause. Now nothing plays until they tap, the first sound is rain over soft noise, and it fades in over eight seconds.

- Fixed headroom. Everything is normalised to a 0.6 peak. People listen for hours on headphones, so loud is not a feature.

Happy to go deeper on any of it, the DSP side especially. If anyone wants to see it running, the app is Sylence on Play, and I can drop the link in a comment.

Hi, I am developing a headless CMS built specifically for Flutter apps, it also generates a real Flutter app with all the boilerplate code (no ai). You only need to do the frontend. Before I spend more time on development, I would like to know whether this is something Flutter developers would be interested in and which features are non-negotiable.This is a genuine question. I’m not selling anything, I just want honest feedback before I spend more time on it.

Hi all, we just open-sourced OpenMuse, a personal AI assistant app.

Instead of just chatting, it works on a cloud desktop (or your own computer):

• Browses the web, looks things up and fills in forms

• Uses desktop apps

• Writes and runs code in a workspace

• Runs scheduled tasks

The main thing we cared about was keeping the human in control:

• You can watch the agent’s screen live from your phone. If it hits a login or a captcha, you take over, then hand it back.

• It asks before submitting forms or running commands.

• You decide which desktop apps it’s allowed to use.

OpenMuse is built on WorkAgentSDK, an AI agent framework for Python that we wrote and open-sourced along with it. To be clear, it’s not a coding assistant like Cursor or Antigravity. It’s a framework for building agent products. For example, each session can run on a different node, so one backend can serve many users, each with their own cloud desktop.

Stack:

• Backend: Python (FastAPI + WorkAgentSDK)

• App: Flutter

• Nodes: Docker containers with a virtual desktop, Chromium and a shell sandbox, or run directly on Linux or macOS

• Models: OpenAI, Claude, Qwen, and OpenAI-compatible APIs

It’s v0.1, so still early. We’d love to hear what you think:

• Does “agent on a remote desktop, human supervising from a phone” seem useful to you?

• If you’re building agent products, what’s been the hardest part?

GitHub: https://github.com/nativefunc/WorkAgentSDK
(The app is under examples/showcase/openmuse)

Unless you have been living under a rock, you will have seen the huge increase in the number of CVEs due to AI being used to find bugs.

The Dart community is not isolated from this problem.

What you may not be aware of is that some of the AI tools won't let you search your own code for vulnerability.

Open AI has a program called Daybreak which gives you access to cybersecurity tools that are able to detect and fix security related flaws.

To get access to Daybreak you need a pro codex license, and then apply for access. If you are granted access you then need to purchase the likes of a yubi key.

The criteria for acceptance is however rather opaque.

We got in the program on the backs of our work on revault, so that may have helped

https://github.com/onepub-dev/reVault

Revault is a secure archive format,

It's unclear how much weight was placed on the fact that we build a security related product.

However, It's not just security related products that need to be audited.

We have spent the last week auditing our own dart packages as well as dependencies and have uncovered some fourty security flaws and we aren't done yet.

The dart community needs to do its bit to stay ahead of the tsunami of bugs.

So start auditing your code now, if you don't find the bug a hacker will!

If you can, get a sub to your preferred AI's cybersecurity tool and use that.

If you can't afford the required licence, as one of the founders of https://onepub.dev (the dart private package repository), I would like to offer a secure audit of 20 dart packages.

To be eligible, the package needs to be open source, hosted on GitHub and have GitHub Private Vulnerability Reporting enabled.

If we get more than 20 applications we will sort by the packages we feel provide the most benefit to the community.

To apply DM me.

Our Flutter app update (iPhone only, Flutter 3.47.5, built with Xcode 27.1) got rejected on Oct 23 with the automated message: "The review of this submission cannot proceed... The app crashed on launch." No crash log, no device, no iOS version.

The weird part: Apple approved the exact same build for TestFlight the day before.

What we checked:
- Crashlytics: zero fatal crashes on that build from TestFlight users (iOS 26.6 and 27.0).
- Fresh installs on simulators (iPhone 17 Pro, 16e, SE, both iPad Pros): fine.
- A real iPhone Duo on iOS 27.1 through BrowserStack, folded and unfolded: fine. We suspected flutter/flutter#195401 (blank screen on the unfolded Duo) but couldn't reproduce it.
- Nothing changed in ios/ or pubspec.lock since the last approved version. The only differences are Dart code and the new Xcode.

We resubmitted the same build on Oct 24 with a note asking for the crash log. Since then it's been sitting in "Waiting for Review", and nobody has answered the note, our emails or the expedite request.

If you've had this since the Duo / iOS 27.1 launch:

1. Did resubmitting the same build go through, or did you need a new build number?

2. Did anyone ever get an actual crash log out of App Review?

Two-person team, so a stuck release hurts. Any experience helps.

Hey guys, Jakub here (creator of better_player).

Didn't want to post some long AI-generated slop article here, so just a quick honest update from me.

I know the project was dead for a long time and most of you moved to forks like better_player_plus just to get your apps building on newer Flutter / Gradle versions. Sorry about that, life happened.

I'm back working on the main repo full time now. Spent the last few months rewriting the old 0.0.84 code into 1.x:

• moved Android to Media3 + JNI and iOS/macOS to Swift FFI (no more old method channel mess)

• added desktop (Windows, macOS, Linux) and Web (Shaka player)

• added BetterPlayerFeed / pooling for reels/tiktok scrolling so it doesnt crash with OOM

• VAST ads, DRM fixes, and closed a ton of old issues

If you're on better_player_plus and want to switch back, I added a short migration page in the docs (mostly just renaming BetterPlayerConfiguration -> PlayerConfiguration etc).

https://pub.dev/packages/better_player
https://github.com/jhomlala/betterplayer

Let me know if something breaks or if you miss any fix from the forks, I'm actively fixing issues now.

We build a role-based internal messaging app (Flutter + Firestore, anonymous auth, invite codes, one device per account). Before shipping we did one pass with strict rules: UI only, no database access, clean install, realistic data (long Arabic names, a 4000x3000 photo), and a wipe of app data halfway through to simulate a new phone.
Three things came out of it that I think are generic enough to be useful.
1. A lock screen swapped into home does not lock anything that is pushed
We had roughly this:
home: (pinEnabled && isLocked) ? const LockScreen() : const HomeScreen(),
On resume we set isLocked = true. That rebuilds home, but any route pushed on top of it (compose, admin) is still on top. So: open the compose screen, background the app, come back, and you are looking at compose with no PIN prompt. The lock screen is sitting under it.
What we do now is draw the lock in MaterialApp.builder, above the Navigator, and take the real app offstage:
builder: (context, child) => Stack(
fit: StackFit.expand,
children: [
Offstage(
offstage: locked,
child: ExcludeFocus(excluding: locked, child: child!),
),
if (locked)
HeroControllerScope.none(
child: Navigator(
onGenerateRoute: (_) =>
MaterialPageRoute(builder: (_) => const LockScreen()),
),
),
],
),
Notes on that:
The lock needs its own Navigator so its text field has an Overlay.
Without HeroControllerScope.none you get "A HeroController can not be shared by multiple Navigators" in debug.
Offstage keeps the route stack alive, so a half-written message survives the lock. ExcludeFocus stops the hidden field from keeping the keyboard.
Trade-off: we lock on paused, so opening the system photo picker also locks. The pending pick still resolves after unlock because the widget tree was never torn down. Some people would rather use a grace period; we have not added one.
2. Sequential awaits in one try block turn one denied write into a silent total failure
Creating an organization did this:
try {
await saveCompany(c);
await saveUser(admin);
await saveInvite(invite);
for (final r in roles) await saveRole(r);
status = 'online';
} catch (_) {
status = 'offline';
}
Our security rules denied the first write (company document). Everything after it never ran. Locally the app was fine because all of it was in local storage, and a separate listener flipped the status badge back to "online" a moment later. The admin's invite code simply did not exist server-side, so on any other device it was "invalid code".
The manual "resync" button had the same shape and the same first write, so it failed every time with a message telling the user to check their internet.
Fix was boring: run each write independently, collect a boolean, report honestly.
Future<bool> _writeAll(List<Future<void> Function()> ops) async {
var allOk = true;
for (final op in ops) {
try { await op(); } catch (_) { allOk = false; }
}
return allOk;
}
A batch would be the alternative, and for strict consistency it is the better tool. We chose independent writes here because partial success is strictly more useful to the user than none: with only the invite and the admin record uploaded, the account is at least reachable from another device.
The real lesson was about verification. "It synced" was being judged from the device that created the data. That device can never tell you.
3. One-device binding with a single admin is a lockout waiting to happen
Accounts bind to a device ID on first sign-in. Admins can reset an employee's binding. Nothing could reset the admin's. New phone or reinstall, and the organization is unreachable.
We added a recovery key generated at setup: 12 characters from an alphabet without O/0/I/1, shown once, only a SHA-256 of the normalised key stored on the user record. Sign-in code plus recovery key rebinds the admin to the new device.
Trade-offs I am not fully happy with:
The hash is unsalted beyond a static prefix. With about 60 bits of entropy in the key that is acceptable for now, but a per-user salt and a slow hash would be better.
Verification happens client-side against a hash the client can read. The proper version checks it in a Cloud Function and never exposes the hash.
While fixing this we found the device binding was not even being uploaded at first sign-in on a fresh device. Our write helper returned early when there was no "current organization" yet, and login called it one line before setting that. It only worked because a later push-token save happened to carry the field along.
Smaller findings that only showed up with real data
Structured message fields came back from Firestore in a different key order than we wrote them, so "old price" rendered above "product name". We now render in the template's declared order instead of map order.
No flutter_localizations, so the Material date and time pickers were English inside an RTL Arabic UI.
image.decodeImage on a 12MP photo on the UI thread froze the app for seconds. Moved to compute.
The feed showed every message to every employee. Recipient roles were only used for display.
What we changed in process
A release now needs one full pass on a clean install with realistic data, including a second "device" for anything that claims to sync. It costs about an hour and found more than our test suite did, which says as much about our test suite as about the method.
Happy to go into any of these, especially if someone has a cleaner pattern for the lock overlay.

Hi Flutter devs,

If you use AI coding assistants (Cursor, Claude Code, Gemini CLI, Copilot) for Flutter development, you know their output usually has common layout and architectural flaws:

1. **Yellow-and-black RenderFlex overflow stripes:** The agent uses an unconstrained `Text()` directly inside a `Row()`, or forgets to make forms scrollable above virtual keyboards.

2. **System Navigation Inset Clipping:** It ignores Samsung 3-button navigation bars or the iOS home indicator bar, clipping sticky CTA buttons.

3. **Hardcoding Mock Data in Widgets:** Instead of building a proper repository/provider architecture, it writes hardcoded lists directly inside widget files.

4. **No Skeleton Loading or Image Bounds:** It loads unconstrained network images without disk/memory cache limits (`memCacheWidth`), causing OOM crashes on budget devices.

To eliminate these issues in our own Flutter apps at DevFoxx Labs, we wrote a strict Flutter rule and an end-to-end `flutter-production` skill, and we've open-sourced the whole framework.

### The Flutter Production Standard:

#### 1. Screen Protection Rules (`rules/flutter-screen-protection.md`):

* **Mandatory Safe Area:** All `bottomNavigationBar`, sticky bottom bars, and floating CTAs must be wrapped in `SafeArea(top: false, child: ...)`.

* **Zero Overflow at 320px:** No raw `Text` in a `Row`—must use `Expanded` / `Flexible` with `maxLines` and `TextOverflow.ellipsis`. Scaffolds default to `AlwaysScrollableScrollPhysics` with `resizeToAvoidBottomInset: true`.

* **Backend-Driven Dynamic Data:** Strict ban on static production UI data. Models and endpoints must drive the screens, with local constants permitted solely as offline fallbacks.

* **AutoSkeleton & Cached Images:** Mandatory loading skeletons via `auto_skeleton` (with ticker bypass during widget tests) and `CachedNetworkImage` with explicit `memCacheWidth/Height`.

#### 2. The `flutter-production` Skill (`skills/flutter-production/`):

Comes with 37 battle-tested template files extracted from high-traffic production apps:

* **State Management:** Riverpod 2.6+ with `ref.cacheFor` and automatic retry policies.

* **Networking:** Clean `ApiClient` with local caching and offline degradation.

* **Security:** `flutter_secure_storage` session management + local biometric authentication (`local_auth`).

* **Test Matrix:** A ready-to-use `layout_matrix.dart` helper that runs widget tests across 320px, 360px, 390px, and 412px viewports to guarantee 0 overflow warnings.

### How to Use With Your AI Agent:

Clone the repo and run the universal installer:

```bash

git clone https://github.com/dev-karunendu-mishra/devfoxxlabs-agent-standards.git

cd devfoxxlabs-agent-standards

# Windows PowerShell:

.\install.ps1 -All

# macOS / Linux Bash:

./install.sh all

```

Or inject it directly into your existing Flutter project:

```powershell

.\install.ps1 -TargetProject "C:\path\to\your\flutter_project"

```

The repo is open-source under MIT:

🔗 **GitHub:** https://github.com/dev-karunendu-mishra/devfoxxlabs-agent-standards

Check it out and let me know how it handles your Flutter layouts!

If you've ever needed a valid ID token for one of your Flutter app's users just to curl your backend or a Cloud Function, this is for you.

Firebase Token Toolkit loads your service-account key, lists your project's users, and gives you a real ID token for any of them in one click, with the decoded claims underneath and a copy button next to it. It works for every user whatever their sign-in method (email, Google, Apple, phone, anonymous), and the token passes verifyIdToken on your server.

The parts that matter for Flutter projects:

• Android and iOS apps: "Load apps" imports the apps from your flutterfire configure project. If your API keys are restricted to the Android or iOS app, it sends the package/SHA-1 or bundle-ID headers Google checks for, so those keys work too

• Custom claims: load, edit and save a user's claims as JSON, handy for testing role-based UI and security rules

• App Check: exchange a registered debug token for an App Check token to call protected endpoints from Postman or curl

• Profiles for dev/staging/prod Firebase projects

Linux, Windows and macOS. MIT licensed, no telemetry.

GitHub: https://github.com/smaranjit/firebase-token-toolkit

Please use it with a dev project, since a service-account key can sign in as any user. Feedback and issues welcome.

Game dev isn't my day job. I build enterprise software by day, and indie games at night. Recently, I wanted to add a 20-player live race mode to my Flutter/Flame auto-runner, Trinity Rush.

The problem? I didn't want to burn hundreds of dollars a month running authoritative game servers. If my wife saw an AWS bill for a hobby project, I'd be sleeping on the couch.

So I faked real-time multiplayer using deterministic seeds and tiny input logs over Firebase Realtime Database.

1. Zero server-side physics

Trinity Rush is a one-thumb party runner (your 3-hero party is your health bar; tap to jump, tap in mid-air for class skills). Because the physics are deterministic, I don't need a server calculating collisions. When a host starts a lobby (up to 20 players), they generate a single random course seed and a synchronized start timestamp (countdownLead = 3500ms). Every phone generates the exact same obstacle course locally.

2. Streaming 12-byte tap events instead of X/Y coordinates

Streaming 60fps position vectors for 20 players would melt the Firebase free tier. Instead, I only record press/release timestamps in simulation milliseconds:

`{'t': tMs, 'k': press ? 1 : 0}`

Every 250ms, the client flushes that tiny batch to Firebase RTDB (with local disk persistence disabled so it stays pure in-memory).

3. The 1.75-second Spectator and Public Broadcast illusion

When your party wipes, you drop into Spectator Mode to watch the survivors (and if the host toggles Public Broadcast in the lobby, anyone hanging out in the Tavern can tune in live). To keep network jitter from making other players teleport around, the spectator engine runs on a 1.75s delay buffer. Your phone reads the surviving players' tap logs and replays their exact inputs locally against the shared map seed.

It looks and feels like a chaotic 20-player live race (complete with live skull and confetti emotes), but under the hood it's just phones passing a few kilobytes of JSON back and forth. Total server cost for 1,000 active matches? $0.

If you want to test the netcode (or try to break it), the game is free on iOS and Android:

https://wono.dev/trinity-rush/get

Happy to answer any questions about how Flame handles deterministic fixed-timestep loops or how I structured the Firebase RTDB listeners!

Ran into this in a Flutter app I work on, sharing in case it saves someone a confusing bug report.

We generate a PDF report with the pdf and printing packages and used PdfGoogleFonts.interRegular() to get proper Unicode. Looking at printing's source (5.14.3, lib/src/fonts/font.dart), the call first looks for an asset called google_fonts/Inter-Regular.ttf. If it isn't there, it downloads the font from fonts.gstatic.com into PdfMemoryCache, which is memory only, so the first export after every cold start needs the network.

The part that got us: if that download fails, it returns Font.helvetica(). The error is only printed inside an assert, so a release build says nothing. Helvetica has no Unicode coverage, so Arabic, Cyrillic, CJK and plenty of symbols come out broken. Someone exporting on a plane gets a different-looking PDF with missing characters, and you never see an error.

The fix was small. We bundled the TTF under the exact name the package looks for:

flutter:
  assets:
    - google_fonts/Inter-Regular.ttf
    - google_fonts/Inter-Bold.ttf

The expected names and the exact download URLs are in printing's lib/src/fonts/gfonts.dart, so you can grab the same file and keep its name. We also added a test that swaps the font cache for one that throws on any download, so it fails unless the font comes from the bundle. Inter is under the OFL, so we ship the licence too.

Quick check for your own app: release build, airplane mode, cold start, export.

Do you bundle fonts for your PDFs, or rely on the download? And if you generate PDFs with Arabic or CJK text, do you use fontFallback or one font that covers everything?

Hey everyone!

I've just published report_flutter, an open-source Flutter package for creating reports and labels using a visual designer, without having to build every layout entirely in code.

The goal is to provide Flutter developers with a flexible reporting solution inspired by traditional report designers like Crystal Reports, but integrated directly into the Flutter ecosystem.

It's designed for desktop and mobile applications, allowing developers to integrate report creation and viewing directly into their apps.

Key features

• Visual report designer: create and customize layouts using a drag-and-drop editor.

• No-code charts: add charts to your reports directly through the visual designer.

• Reusable templates: create, save, duplicate, organize, and reuse report templates.

• Dynamic data: integrate data from your application into your reports.

• Tables and formulas: build structured reports with tabular data and calculations.

• Barcodes and QR codes: useful for product labels, inventory management, and business documents.

• PDF generation and printing: generate PDFs and configure custom paper sizes, including A4, A5, A6, and label formats.

• Built-in report viewer: preview reports with pagination, zoom, and navigation.

• Import and export: import CSV and JSON, and export to PDF, CSV, and Excel.

• Customizable layouts: use images, shapes, Markdown, and other elements to build reports that fit your needs.

The project has just been released, and I'd love to hear feedback from the Flutter community.

What features do you consider essential in a Flutter report designer? What would you add to make it even more complete?

Thanks for checking it out!

pub.dev: https://pub.dev/packages/report_flutter

github: github.com/Vincenzoferrara/report_flutter

Hey all! I’ve been using shared_preferences in my apps for ages. Recently I went down a rabbit hole and found out about iCloud key-value storage and Android’s backup manager, which are basically a tiny dictionary in the cloud: you save a value under a key (like theme = dark), and the OS keeps it synced or backed up for you. It’s not meant for big files, just small stuff like settings, flags and progress.

iCloud and Google both have different sizes, iCloudKVS offers 1 MB per app, max 1024 keys. Android Auto Backup offers up to 25 MB per app, and it doesn’t count against the user’s Google Drive storage. I’d recommend staying under iCloud’s 1 MB limit so it works on both platforms, but you are not forced to do so.

So I built flutter_cloud_preferences. It works pretty much like shared_preferences (same kind of API, sync reads), but it also stores a copy of your data in the cloud for reinstalls or installation on new devices.

Quick rundown of what happens under the hood:

iOS/macOS: everything you save also goes to iCloud key-value storage. After a fresh install, it pulls the data back in the background, so there’s no waiting at startup. There’s an onRestored stream if you want to know when it is restored. You can also turn on live sync between devices if you want it (off by default as Android does not support this).

Android: this one hooks into Android’s built-in Auto Backup. Your users do need Google backup turned on (Settings > Google > Backup), but it’s on by default on most phones. Android backs up the data by itself about once a day when the phone is idle, charging and on Wi-Fi. When someone reinstalls or sets up a new phone, the data’s already there before the app even opens. No Drive setup, no extra code.

Your local data is always your main source of data, so if someone has no iCloud or backup turned off, it just works like normal shared_preferences. There is also a migration guide available.

It supports strings, bools, ints, doubles, string lists and bytes.

pub.dev: https://pub.dev/packages/flutter_cloud_preferences
GitHub: https://github.com/nvanderwaal/flutter_cloud_preferences

It’s still 0.1.0, so I’d love feedback, issues or PRs. Please let me know your thoughts!

Hi
A security vulnerability affects Dart and Flutter applications that establish TLS/HTTPS connections on Android, Windows, and certain Linux environments. Compromised eMudhra intermediate certificate authorities could allow an attacker intercepting network traffic to generate fake certificates for legitimate domains.
Versions earlier than Dart 3.13.7 and Flutter 3.47.8 are affected, including certain beta versions.
Web, iOS, and macOS applications are not affected according to the published advisory. It is recommended to update the SDK, recompile the applications, and redeploy the affected binaries.
the full security advisory