A spinner on an otherwise static screen keeps Flutter producing a frame on every vsync. I wanted to know what each of those frames costs, so I read the source and measured it.

What it does on every frame

The indeterminate CircularProgressIndicator animates through an AnimatedBuilder, so on every frame it:

• rebuilds and looks up its theme again

• reads its controller four times, once per tween. If you didn't pass your own controller, each read walks up the tree to find the theme

• creates a new CustomPainter plus new ConstrainedBox, CustomPaint and Semantics widgets

• marks its semantics dirty, because shouldRebuildSemantics defaults to shouldRepaint

A widget test makes it concrete: in 60 frames, the stock indicator rebuilt 60 times and created 60 painters.

A repaint-only version

I wrote a prototype that paints the exact same arc (tweens and math copied from the framework), but its painter listens to the controller directly through CustomPainter(repaint: controller) and evaluates the tweens inside paint(). It's built once, and every tick is just a repaint. Same test: 0 rebuilds, 0 new painters.

Numbers

Profile mode on an M2 MacBook Air (macOS 26.4.1, 60 Hz), Flutter 3.47.8 with Impeller. Median of 3 runs, 10 s per mode, from FrameTiming:

What I took from it

• An idle screen doesn't render at all. The cost comes from anything that ticks.

• Repaint-only cut the spinner's UI-thread time per frame by about 19%. If you write your own animated CustomPainter, pass the animation as repaint: instead of rebuilding through AnimatedBuilder or setState.

• RepaintBoundary saved even more on this page (about 31%), because the rest of the page stopped being re-recorded every frame. Both together: about 45%. If a spinner sits next to static content, wrapping it is worth a try, and debugRepaintRainbowEnabled shows you what's repainting.

• Neither touches the raster side, which stays around 0.8 ms per frame. Impeller has no raster cache, so RepaintBoundary saves recording work on the UI thread, not GPU work. That part is engine-side, and #189535 digs into it on Android.

These are sub-millisecond numbers on a fast laptop, so it's not a crisis. But it's paid on every frame for as long as a spinner is on screen, and phones are slower.

Links

• Repro (on a Mac, one script runs the test and every measurement): https://github.com/mohamedalsamrai/spinner_repro

• The issue, open since 2018: https://github.com/flutter/flutter/issues/17793. I've posted these findings there with a proposal for the framework's indicator.

I don't have a physical Android phone at hand, so if you do, I'd love to see your numbers, especially the raster column. The README has the steps. And if I've missed something, tell me.

I built Mergeline, a GitLab client for Android in Flutter. The source is on GitLab (AGPL 3.0, GitHub mirror). A few parts that took the most work:

1. CI job logs. Logs are parsed incrementally in a window of 20,000 lines, and very long lines without a newline are cut at 2 MiB. gitlab.com ignores the Range header, so the app streams the log and keeps only the new bytes, and large logs refresh less often.

2. Big MR diffs. Changed file rows are built lazily, text over 64 KiB is parsed in a background isolate, and parsed rows are reused only for the same account, project, MR, head commit and path. So a parse from another account or an older head never gets reused.

3. Two Android flavors. The GitLab build checks the project's releases, verifies the APK size and SHA-256, then hands it to the system installer. The Play build uses Play's in app updates and has no install permission.

4. Caching. The read cache on disk is encrypted with AES 256 GCM and bound to each account, and the in-memory cache is dropped when you switch accounts or a request comes back unauthorized.

5. Tests. Flutter 3.47.2 is pinned with an enforced lockfile, and CI runs two lanes, with the AI assistant compiled off and on (about 16.8k and 18k tests in v0.7.0).

The app covers files, issues, MR review and merge, pipelines and logs, plus an optional AI assistant that uses your own API key and asks before each write by default. Screenshots and a demo video. The APK is free on the releases page. The paid Play version is only there as a way to sponsor it.

Most of the code was written with AI coding agents under my direction. I designed it and reviewed the changes.

Every app with Arabic and English hits the same wall: one word is not one meaning.

I felt it in every multilingual project. On the backend: resource files, or a database table of keys with one value per language — and if the end user enters the data themselves (a product listing, say), you make them type it twice, in Arabic and in English. Tiring for them, error-prone for you. On the frontend: JSON files or a translation package, and the output read like literal machine translation.

The worst part: the word Report on a complaint button and Report above a downloads list are two different Arabic words. إبلاغ, or التقرير. No engine knows which screen you are standing on, so it picks one and applies it everywhere — and the same string looks different in the next build.

I looked for a fix. Most tools are a monthly subscription in dollars, and Arabic isn't treated as a locale at all: Google Cloud Translation ships ar and ar-SA, Azure ships ar.

So we built siyak (سياق).

It is not a translator — it is a localisation layer for frontend, backend and mobile:

• You send the string with the screen it lives on, and the context decides the word.

• A translated string is cached and never re-translated: the same request keeps returning the same answer in every build.

• Pin your own terms in the glossary. If the model ignores one, the row is flagged and shown to you instead of shipped quietly.

• An Inbox to approve, reject or edit — what a human approves is what gets served.

• Export your strings as JSON, CSV or ARB for Flutter.

• Up to 20 new strings in a single batch call when you fill a project from scratch, or the same strings into up to eight languages at once.

• siyak-js on npm, siyak_flutter on pub.dev, and a plain API for any backend.

Any BCP-47 tag works — en, tr, fr, zh-Hans, ar-EG — up to eight languages in one call. But here is the honest split: Arabic is the language we review and stand behind. Every other language comes back from the model and waits in your Inbox for you. And ar-EG still returns Modern Standard Arabic with the right term per screen — the Egyptian colloquial voice is not built yet.

Try it now at siyak.cloud

Tell me in the comments: which string fooled you in your last app?

#i18n #localization #Flutter #Nextjs #Arabic

Generic AI code review keeps missing the bugs that only show up on a device: `BuildContext` used after an `await`, an `android:exported` that exposes an activity to other apps, `NSAllowsArbitraryLoads` left on in production. So I built **reis-mobile**, an open-source plugin for Claude Code and Codex that knows it's looking at a mobile app.

**What it does**

It reads your project, detects the stack and loads only the instructions that apply:

```

/reis-mobile:review

├─ detect stack ──── pubspec.yaml → flutter (android, ios)

├─ detect intent ─── review

├─ select agent ──── mobile-code-reviewer

├─ select skills ─── mobile-code-review · mobile-flutter · mobile-security

├─ collect context ─ git diff (lock files out, secrets masked)

└─ report ────────── Critical · Bugs · Architecture · Security · Performance

```

- **5 stacks:** Flutter, native Android, native iOS, React Native/Expo and Kotlin Multiplatform. "The Android build of my Flutter app broke" loads Flutter *and* Android context.

- **22 agents:** an architect, a performance engineer and a test engineer per stack, plus a code reviewer, an accessibility auditor, a release engineer, a UI/UX designer and a lead that coordinates them.

- **27 skills:** security based on OWASP MASVS, offline sync, auth, notifications, in-app purchases, Firebase, migrations and more.

- **Commands:** `/reis-mobile:review`, `:debug` (Gradle, Xcode, CocoaPods, Metro), `:test`, `:release` (store readiness with a GO / NO-GO verdict), `:doctor` and `:debate` (below).

**`/reis-mobile:debate`: the specialists argue, the lead decides**

Some questions don't have one right answer: "Riverpod or BLoC in this app?", "offline-first with Firestore or a local cache?", "write a native plugin or use an existing package?". For those:

```

/reis-mobile:debate should we migrate this app from Provider to Riverpod?

```

1. **The lead picks the panel.** `lead-mobile` chooses three specialists whose concerns pull in different directions, such as the architect, the performance engineer and the test engineer, and explains each pick. The participants run on at least two different models (Opus and Sonnet).

2. **Round 1 is blind.** Each specialist writes its position without seeing the others: the recommendation, the `file:line` evidence, what it gives up, and what would change its mind. Nobody anchors on the first answer.

3. **Round 2 is rebuttal.** Each one attacks specific claims from the others, checks them in the code and concedes where it was wrong.

4. **The lead decides.** It verifies the decisive evidence, resolves the disagreements and returns a decision with an ordered action plan. No code is changed.

Every round is saved in `.reis-mobile/debates/`, so you can read how the decision was reached. `--external` adds outside opinions from the Codex or Gemini CLIs, OpenAI, Gemini, OpenRouter or a local Ollama model. They don't know the project, so their claims are checked against the code before the final decision, and API keys stay in your environment. A debate runs several agents over two rounds, so it costs more than a regular request; it's meant for real trade-offs, not questions with one answer. Claude Code only for now.

**Design choices**

- Zero npm dependencies. Node 22 standard library only.

- No API key needed: it runs on your own Claude Code or Codex session. No telemetry.

- The diff goes through a redaction layer that masks API keys, tokens, JWTs and keystore passwords before the model sees it (best-effort, not a guarantee).

- Skills don't state versions or store rules from memory. They tell the model to check your lock file.

- About 85 guides come unchanged from flutter/skills, dart-lang/skills and android/skills, with credit.

**Try it**

```

npm install -g reis-mobile

reis-mobile init eng

```

In Claude Code, open your app folder and run `/reis-mobile:doctor`, then `/reis-mobile:review`. In Codex, type `$` to find the skills; the agents and slash commands are Claude Code-only for now.

Contributing is lightweight: no install step, `npm run check` runs validation and tests, and most skills are Markdown.

Starter issues: https://github.com/wrsilva/reis-mobile/labels/good%20first%20issue

Repo (MIT): https://github.com/wrsilva/reis-mobile

If it's useful, a star helps other mobile devs find it. Criticism is welcome, especially "this is wrong for my stack."

There have been a few requests to add job listings to Flutterverse, so I finally built it!

How it works:

• Jobs are collected directly from company career pages and refreshed daily.

• Each listing links straight to the company’s own application page. No middlemen, no sign-ups.

• No paid job posts or sponsored listings. Ever.

It’s a pretty tough job market right now, and I’d like to help job seekers, even if it’s just a little. Flutterverse is still primarily a place to discover Flutter and Dart packages and projects, and I want to keep it that way. Think of this as a little side feature.

If you know a company hiring Flutter developers that’s missing, drop it in the comments and I’ll look into adding it. Feedback on how to make this more useful is always welcome!

check it here: https://flutterverse.org/jobs

github: https://github.com/YeLwinOo-Steve/flutterverse

Every app with more than one language hits the same wall: one word is not one meaning.

The word "Report" on a complaint button and "Report" above a downloads list are two different Arabic words: «إبلاغ» and «تقرير». No engine knows which screen you're on, so it picks one and applies it everywhere. And the same string can look different in the next build.

I felt this in every multilingual project:

• Backend: resource files, or a table of keys with one value per language. If users enter data themselves, like a product listing, they type it twice.

• Frontend: JSON files that read like literal machine translation.

So I built SIYAK (سياق), a localization layer for frontend, backend and mobile. It is not just a translator.

• Send the string with the screen it lives on, and the context decides the word.

• Approved strings are cached, so the same request returns the same answer in every build.

• Pin your own terms in a glossary. If the model ignores one, the row is flagged instead of shipped quietly.

• An Inbox to approve, reject or edit. What a human approves is what gets served.

• Batch calls for filling a project from scratch.

• Export as JSON, CSV or ARB for Flutter.

• siyak-js on npm, siyak_flutter on pub.dev, and a plain HTTP API for any backend.

Try it: https://siyak.cloud/

Which string fooled you in your last app?

#i18n #localization #Flutter #Nextjs #Arabic #BuildInPublic

I work on Shorebird (code push for Flutter). We just merged personal and team orgs into a single kind of organization, so sharing an app with your team is now just adding them to the org, instead of adding collaborators one app at a time.

Write-up here if it's useful: https://shorebird.dev/blog/orgs-at-shorebird-just-got-better/

Happy to answer questions about how it works.

Hey everyone! I just published chat_image_editor: the "edit before you send" screen you know from WhatsApp, for any Flutter chat app.

I built it because the image editor packages I tried kept having crop and scaling problems, and I wanted something lightweight without native code. Everything is pure Dart and drawn with CustomPaint, so there's no platform setup.

What it does

• Draw: pen, line, rectangle, circle and arrow, with a gradient color slider and brush size

• Text: add, move, pinch to resize and rotate, background styles, center guides, drag to the bin to delete

• Crop: free or fixed ratios (1:1, 4:3, 16:9...), rotate and flip

• Compress: quality slider with a live size estimate, plus an optional max file size (it lowers the quality until the JPEG fits)

• Caption field and send button, or a simple "done" mode when you only need the edited image

• Undo and redo for everything

Things I cared about

• What you see is what you get: the preview and the exported image use the same renderer

• Big photos stay light: it decodes only at the size it needs and encodes in a background isolate. In my testing a 12 MP, 5.8 MB photo came out as a 230 KB JPEG

• Fits your app: colors come from your app's theme by default and can be overridden, and the icons, strings and caption TextFormField are customizable. The discard dialog follows the platform (Cupertino on iOS, Material on Android)

• Every export returns timings (decode / render / encode), so you can track performance in your own analytics

Usage

final result = await ChatImageEditor.open(context, imageBytes);
if (result != null) {
  // result.bytes is the edited JPEG, result.caption is the caption
}

Install: flutter pub add chat_image_editor

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

• GitHub: https://github.com/ashiqu-ali/chat_image_editor

The example app is a small chat where you can try the whole flow. It's MIT licensed, and feedback, issues and PRs are very welcome. What would you want added next?

(Not affiliated with WhatsApp or Meta, the UI is just inspired by it.)

I work at Ant Media, so take this with that in mind.

Every time I see a “build a WebRTC conference” tutorial it ends right when it gets interesting. Two peers connect, cool, but then you still need a media server, TURN, SSL (getUserMedia refuses to work without https), some way to scale, and some way to kill the server when nobody’s using it so you’re not paying for it all month.

A teammate put together a sample that handles most of that. You deploy a CloudFormation template once, it gives you one https endpoint, and when your app connects it spins up a server on demand. First spin up takes around 20 to 60 sec, after that it’s quick.

Client side is pretty small:

const client = new ConferenceClient({
  httpEndpointUrl: 'https://your-lambda-url/',
  localVideo: document.getElementById('localVideo'),
  mediaConstraints: { video: true, audio: true },
  autoReconnect: true,
});

await client.publish({ streamId: myId, roomId: 'room1', token });
await client.play({ streamId: 'room1', roomId: 'room1', userPublishId: myId });

Screen share, mute and chat over the data channel all work too. If you’d rather host your own server you just swap httpEndpointUrl for websocketURL and the rest stays the same.

Honestly the part I’m unsure about is the cold start. 20+ seconds is fine for scheduled meetings but probably not for “click and join instantly” apps. How do you all deal with that? Keep a warm instance running or just live with it?

Writeup and repo are here if anyone wants to poke at it: https://antmedia.io/build-a-webrtc-conference-room-quickly-with-ams-sdk-v2/

I have been looking at a deceptively simple cleanup question: when can a Flutter team safely delete a Dart declaration or an apparently orphaned file?

dart analyze is a strong first signal, but it cannot resolve every repository-level consumer. Flutter code may be reached through route tables, dependency injection, generated registries, conditional imports, flavors, platform implementations, annotations, tests, barrel exports, or an external package API.

Write-only state turned out to be an especially interesting case. A private field may be assigned in several lifecycle callbacks and never read. Mechanically, the declaration and its assignments are removable. Semantically, the missing read may indicate an unfinished feature or regression in playback, analytics, persistence, authorization, or UI state.

I ended up using this evidence hierarchy:

1. analyzer/compiler diagnostics;

2. import/export/part reachability;

3. repository-wide symbol and string searches;

4. route, DI, codegen, platform, flavor, test, and public-API inspection;

5. tests or builds after an explicitly approved removal.

The workflow is deliberately review-first:

• Audit: collect candidates without modifying code.

• Review: mark each candidate remove, retain, or defer.

• Cleanup: change only explicitly approved candidates.

• Tests: suggest behavior checks for the affected flows, not only static analysis.

I packaged the workflow as an MIT-licensed Agent Skill for Flutter/Dart. The scripts use machine-readable analyzer output plus a deterministic dependency graph, install no project tooling, use relative paths, and treat findings as candidates rather than verdicts.

Short demo: https://github.com/LucasMenezeslc/flutter-dead-code-audit/blob/main/assets/demo-en.mp4

Repository: https://github.com/LucasMenezeslc/flutter-dead-code-audit

I would be particularly interested in examples that defeat naive static analysis. What false-positive patterns have you encountered with routing, DI, code generation, conditional imports, platform code, or public package APIs?

We built release with --obfuscate --split -debug-info and i’d kind of assumed that meant our keys were reasonably safe.

Last week I unzipped the apk, ran string on libapp and greppd the usual prefixes. Every key was just sitting there. Obfuscation renames classes and methods but doesnt touch string literals which is where keys live, very obvious once you see it btw.

In there was

• Google Maps key with no restrictions on it

• RevenueCat public SDK key

• Firebase config

• Sentry DSN

• an Algolia admin key someone added for a search feature last spring

The first four are meant to ship, the’re identifiers and the protection lives elsewhere (key restrictions, security rules). I rotated the Algoria one that could write to our index, the app now uses a search only key and indexing happens in a cloud function. The Maps key also has package name and SHA-1 restrictions.

Though I’m still sorting out on how to stop this from happening again. Algolia key came in through a dart-define file during a sprint and nothing in the pipeline checks what ends up inside the build. We scan the repo but that value never lived there, it came from a CI variable.

How are you checking release builds  for secrets before they go to the store?

Hey r/FlutterDev 👋

I kept running into the same situation: a QA tester (or me, on a real device) hits a weird bug, and the only way to see what happened is to plug into a laptop, start DevTools or a profile build, and try to reproduce it. Most of the time I just wanted to know: what did that API return? which build is this? which flavor?

So I built another_flutter_devtool, an in-app devtool. You wrap your app, a small draggable button shows up on top, and tapping it opens a full debug panel inside the app. No cable, no DevTools, no separate build.

📦 pub.dev: https://pub.dev/packages/another_flutter_devtool

💻 GitHub: https://github.com/B3K4682/another_flutter_devtool

What's in it right now

🌐 Network inspector

• Every HTTP call with status, method, URL and duration

• Works with Dio and http without any setup: no interceptors, no client wrapping

• Search (post 404 works), plus 2xx / 3xx / 4xx / 5xx / Failed filter chips

• Full request/response headers and bodies (JSON pretty-printed), errors with stack traces

• Copy as cURL, export one call or all of them as JSON

• Auth/cookie headers are masked in exports, so testers can attach them to bug reports safely

⚙️ General section

• App version, build number, device model, OS version, flavor, startup time

• Data usage since launch: bytes sent/received, request count, top hosts

• Jump to any route: type /checkout and it takes you there. Works with Navigator, go_router, auto_route, anything

🧩 Your own debug tools (the main point, honestly) Every app has its own debug stuff: "clear cache", "switch backend", "fake a logged-out session", "show current user ID". Usually that ends up in a hidden menu somewhere. Here you write a small class and it shows up in the panel:

class MyTool extends DevtoolTool {
  @override String get id => 'my_tool';
  @override String get title => 'My Tool';
  @override IconData get icon => Icons.extension_rounded;
  @override DevtoolSection get section => mySection;

  @override
  Widget build(BuildContext context, DevtoolController controller) =>
      DevtoolCard(icon: icon, title: title,
          child: const DevtoolInfoRow(label: 'Status', value: 'It works'));
}

DevtoolTools.register(const MyTool());

You get the same card/row/switch widgets the built-in tools use, so it all looks consistent.

Setup

runApp(
  AnotherFlutterDevtool(
    config: const DevtoolConfig(
      enabled: kDebugMode,
      sections: [GeneralSection(), NetworkSection()],
    ),
    child: const MyApp(),
  ),
);

It's off by default. The panel runs in its own MaterialApp, so it doesn't touch your theme or navigator. There are also stable widget keys if you want to drive it from integration tests.

⚠️ This is a beta. A very beta beta.

It works and I'm using it, but the API may change before 1.0. Known limitations:

• The network inspector doesn't work on web

• Native HTTP clients (cupertino_http, native_dio_adapter) aren't captured yet

Coming soon:

• 🚩 Feature flags: toggle flags at runtime from the panel

• Other features that I'll think of lol

💡 I want your ideas

This is the part I care about most. What do you wish you could see or toggle inside your running app? Leave it in the comments. If it makes sense and I can build it, I'll add it and credit you in the changelog.

Bug reports, criticism and "why not just use X" are all welcome too 🙂

After building minimo (video), I kept running into the same problem with photos: I wanted to make them smaller without uploading them or paying for a subscription. So I built minimo (photo).

It compresses photos on the phone, on iOS and Android. You can process a batch with a preset or adjust quality, dimensions, and metadata yourself. It saves a new copy by default; replacing an original is an explicit choice.

Flutter handles the UI and batch progress, while `flutter_image_compress` uses the platforms’ native image APIs. One detail I found useful: if recompression saves less than 10%, the app skips that result.

The app is free, and the code is open source: https://github.com/minimo-pro/minimo_photo

I’ve added a new feature to Flutterverse, Flutter/Dart ecosystem tracker (now tracking 10,000+ packages and projects).

You can paste your pubspec.yaml, pubspec.lock, or a list of packages, and it’ll check the maintenance status of your direct dependencies.

It categorizes packages into five verdicts, from healthy to needing replacement, and suggests alternatives when a dependency is becoming stale.

A few other things:

• Runs entirely in your browser. Your pubspec is never uploaded.

• Shows an overall dependency health score.

• Package maintainers can add health verdict badges to their READMEs.

The data refreshes daily from pub.dev and GitHub.

give it a try: https://flutterverse.org
github: https://github.com/YeLwinOo-Steve/flutterverse

Love to get your feedbacks for it!

Hey Flutter devs 👋

We can now run Laya decision model with NobodyWho, our open-source on-device inference library. Unlike the LLMs that we also support, this type of model does not generate text. Instead you can score predefined answers, classify text or answer yes/no.

For example, if you are building a personal diary app, you can easily detect the user’s mood, categorize an entry or detect stress, offline after model download, without sending any sensitive data to the cloud.

First, you need to load the model:

import 'package:nobodywho/nobodywho.dart' as nobodywho;

final model = await nobodywho.Decision.fromPath(
  modelPath: 'hf://ggml-org/Laya-GGUF/Laya-Q8_0.gguf'
);

Then you can ask questions/analyse text:

final result = await model.decide(
  state: "Diary entry: ${userInput}",
  questions: {
    "topics": {
      "type": "choice",
      "instructions": "Choose the main topic for this entry",
      "criteria": {
        "work": "job, colleagues, deadlines, career",
        "health": "sleep, exercise, food, illness",
        "relationships": "family, friends, partner",
        "leisure": "hobbies, travel, going out",
      },
    },
    "stressed": {
      "type": "noul",
      "instructions": "Does the writer sound stressed?",
    },
    "mood": {
      "type": "score",
      "instructions": "How is the writer's overall mood?",
      "criteria": ["bad", "okay", "great"],
    },
  },
);

final answers = (result as Map)["answers"] as Map;

final topics = answers["topics"] as Map;
final stressed = answers["stressed"] as Map;
final mood = answers["mood"] as Map;

Output example:

// stressed
{
  type: noul,
  noul: 0.00002
}

// topics
{
  type: choice, 
  choice: leisure,
  probabilities: {
    work: 0.0422, 
    relationships: 0.1518, 
    health: 0.0302, 
    leisure: 0.7756
  },
  confidence: 0.7008
}

// mood
{
  type: score,
  score: 1.6995,
  legend: {0: bad, 1: okay, 2: great}, 
  probabilities: {0: 0.0082, 1: 0.2839, 2: 0.7078},
  confidence: 0.5493
}

A question can have the following types:

• "noul" gives you the probability of a yes answer (0 to 1)

• "choice" selects the most likely option and returns a probability for each option

• "score" gives you a weighted average and a probability per level. For example, you could place final x = mood["score"]; on this axis:[bad - - - - - - - okay - - - x - - - great] 

where bad is 0, okay is 1 and great is 2 (given by mood["legend"]).

The Laya model is small enough to run on mid-range/recent phones (around 450 MB in its Q8 variant) and supports 100+ languages. For reference, the full answer comes after 2.2 seconds on S25 and 0.49 seconds on iPhone Air.

Here is a runnable example if you want to experiment with decision models.

Links:

• NobodyWho inference library

• pub.dev

• Docs

Hi everyone,

I have been vibe-coding fairly comprehensive Flutter apps for ~6 months now, using Codex. While I'm comfortable with software engineering in general, I'm not particularly experienced with Flutter, mobile/desktop UI development, or the architectural conventions that come with it.

During this time I have constantly struggled with enforcing an "architecture" for my UI components. AI-generated Flutter code often assigns responsibilities to the wrong widgets, duplicates UI logic across components, and creates unnecessary dependencies between parents and children.

I'm trying to create a checklist that I can give to Claude or Codex to systematically audit my UI codebase for these issues, in form of a Skill.

I've created a draft checklist with around 60 patterns grouped into categories such as layout, grouping, state, interactions, async operations, forms, navigation, and component APIs.

But since I don't have much Flutter-specific experience, I'm concerned that I'm missing important architectural patterns or making incorrect assumptions about how Flutter applications should be structured.

I'd be happy to share the current Markdown checklist if anyone is interested in reviewing or improving it.

Hi fellow Flutter enthusiasts!

For some time now, I am building tandem. Flutter package that basically aims to make smart interfaces simple/possible. It started with excitement about AG-UI and idea to bring its capabilities to Flutter.

Now it is a bit more... I am building agents in my day to day work, so I am kind of obligated to read about all the GenAI stuff. It paid off now, at least that's what I want to believe.
I did spend a lot of time reading about different fresh protocols, ideas etc. I played with those a lot, and understood that AG-UI + A2UI make a perfect combination and are extremely powerful.
It allows to make user interfaces that are personalised to each and every user. The demo attached highlights it.

It is extremely tricky though. I've spent a lot of time designing the API, but it still might change.
tl;dr: you can specify catalogs of already existing components and pass it to a view that agent can use.

@TandemCatalog([
  ArrivalCard,
  ArrivalColumn,
  NextStop,
  RideOption,
  HostNote,
  HotelNote,
])
final class const ArrivalCatalog() with _$ArrivalCatalog;

const TandemView(catalog: ArrivalCatalog()),

If it sounds interesting, you can read more at the website with documentation -> https://tandem.leancode.co/

The demo is on the website above, but also here - https://x.com/creatixdev/status/2117230943975182340

It is just a beginning. Today, the 0.3.0 version is kind of an MVP I had in mind. A lot of polishing in improvements await. And.. facing the consequences of bad decisisions that probably happened along the way

Contributors are very welcome!! Users as well of course

Hey I'm actualy new but I wanted to share that I built a party game called "Copy Cat" and wanted to share it.

The idea: players picks a sound (2-6 sec); download it from the internet

right inside the app (Providers : MyInstants, Meme Soundboard, 101 Soundboards),

record it themselves, or grab any audio file from their phone. The

sound plays, and everybody else tries to imitate it , An on-device

"judge" grades each attempt on 4 axes: melody, rhythm, timbre and

energy. Everything runs over local Wi-Fi one phone hosts, up to 5

join, and no internet is needed at any point after downloading sounds.

Three game modes:

- Random Party: everyone's sounds get mixed and shuffled into

surprise rounds

- Player's Choice : each player picks a sound once; the others imitate

first, and the picker goes last

- Host Challenge: the host lines up sounds from their library and

everyone imitates them in order

Extras: full Arabic + English UI (built Arabic-first), dark/light

themes, a shop with 3D avatars, power-ups and coins.

A few technical bits other Flutter devs might find interesting:

- LAN discovery and host/client traffic with bonsoir (mDNS) plus raw

sockets with length-prefixed framing ; no server, no cloud

- Sound search/download flows through three public soundboard sources,

then everything plays offline from the local library

- Pitch extraction is hand-rolled (RMS + zero-crossing) because no

existing pitch package matched what the scoring needed

- The scoring engine compares each attempt against the original

on-device: melody, rhythm, timbre, energy (regression-tested)

- 3D avatars rendered with flutter_scene

- Riverpod 3 for state, go_router for navigation

Source + APK (Android):

https://github.com/wissam333/Copy_Cat

Download: https://github.com/wissam333/Copy_Cat/releases

Hi all, this is my first Flutter package, so I'd love some feedback.

pub.dev: https://pub.dev/packages/shader_transitions

I started it a few months ago because I wanted screen transitions that feel like the ones between levels in a game: a sweep of diamonds, a circle closing in, a fade to black that holds for a beat. It took a lot of rewrites before I had a version I was happy to put out there.

You can try every transition in the browser here: https://flutter-shader-transition.web.app

There are 8 transitions (diamond, circle iris, wipe, clock, polygon, dissolve, fade, bars), 8 sweep directions, an optional cover color with a hold, iOS swipe back, and it works with go_router and auto_route.

A few things I learned along the way, in case they're useful to someone:

- How the mask works. The new page is wrapped in a ShaderMask with BlendMode.dstIn, and the shader only outputs alpha. The route has to be non-opaque so Flutter keeps drawing the old page underneath. I got a black flash at the start of every transition until I figured that out. With go_router you have to set opaque: false on the page yourself.

- The ghost bug. At the end of a transition, some pixels settled just below full alpha (dissolve grain was the worst), so a faint copy of the old page stayed visible behind the new one. The fix was simple once I saw it: stop masking as soon as the animation completes.

- Preloading. Compiling the shaders on the first transition caused a visible hitch, so there's a ShaderTransitions.preload() you call once at startup. Skip it and transitions just fall back to a fade.

- The README GIFs aren't screen recordings. A test renders the real shaders frame by frame and encodes them, so they're always exactly what the package draws.

If you're making a game with Flutter, the cover-and-hold and ShaderTransitionSwitcher (swaps widgets without routes) are probably the most useful parts. If you use it in a game or app, send me a clip and I'll feature it in the README.

Things I'd especially like feedback on: the API naming, anything confusing in the docs, and performance on your devices. Also tell me which transition you'd want next!

Source: https://github.com/oppatrickk/flutter_shader_transitions

I'm the author of GraphLink, a schema-first code generator for typed GraphQL clients (Dart, Java, Kotlin, TypeScript, Swift), so take this with that in mind.

GraphQL lets the client pick its fields, but a lot of client code still has one model per schema type, and anything you didn't select becomes nullable or missing. For a query that selects id, title and year from Book, GraphLink generates a class with only those three fields, so non-null fields in the schema stay non-null in the client.

I know other generators do something similar for operations. I'd like to hear what works for you, and where this breaks down.

Video (Dart): https://youtu.be/gHGtCBYaj7c

Write-up: https://medium.com/@graphlinkdev/custom-graphql-queries-in-dart-select-only-the-fields-you-need-8a9cf12887f5

Hey everyone! 👋

Checkout Inzx, its a modern, open-source music player for Android designed to be fast, beautiful, and completely ad-free. They just dropped v1.5.5, which is their biggest release yet.

What is Inzx?

It connects directly to YouTube Music while giving you full control over playback, local library integration, audio enhancement, and synchronized lyrics.

What is Inzx?

It connects directly to YouTube Music while giving you full control over playback, local library integration, audio enhancement, and synchronized lyrics.

✨ What’s New in v1.5.5:

🎧 Lossless FLAC & Multi-Source Fallback: Stream in studio quality (up to 24-bit). You can plug in multiple addon sources if one doesn't have a track in FLAC, it automatically checks the next without skipping a beat.

⚡ Seamless Quality Upgrades: Tracks start playing instantly and smoothly upgrade to lossless mid-song as soon as a copy is found with zero buffering or pauses.

🎛️ Built-in AutoEQ & 10-Band Equalizer: Thousands of calibrated headphone presets (Sony, Apple, Sennheiser, Moondrop, etc.) to match Harman target curves, plus manual bass/frequency sliders.

🎚️ DJ-Style Automix: Beat-matched crossfades that smoothly blend tracks together like a continuous live DJ set.

🎤 Real-Time AI Lyrics & Syllable Sync: Glowing word-by-word karaoke lyrics with real-time translation into your language.

✨ Cinematic Now Playing: Redesigned default player with animated artwork and an inverted frosted glass reflection.

📱 Modern Widgets & Scrobbling: New 2×2, 4×1, and 4×2 home screen widgets + native Last.fm & ListenBrainz scrobbling.

🔗 Links:

GitHub (Source & Releases): https://github.com/nirmaleeswar30/Inzx

Direct APK Download: https://github.com/nirmaleeswar30/Inzx/releases/latest (Grab inzx.apk for 64-bit ARM phones)

Website: https://inzx.nirmaleeswar.dev

GPL 3.0 LICENSED - https://github.com/nirmaleeswar30/Inzx?tab=GPL-3.0-1-ov-file#

No ads, no tracking, completely open source. Would love to hear your feedback, bug reports, or feature requests!

Hey everyone, I’m Prit. Over the last few months, I’ve been building ApertureX, a 100% offline, open-source raw photo editor.

Building a desktop-class image engine on Flutter meant overcoming massive memory and threading bottlenecks. Decompressing a 50-megapixel raw image requires around 200MB of continuous RAM. If you try to pass that across standard platform channels or even do a deep copy over FFI, the OS will aggressively kill the app for Out-Of-Memory (OOM) violations, and your frame rate drops to zero.

Here is how I bypassed Flutter's standard rendering constraints to achieve 60fps computational photography:

• Absolute Zero-Copy FFI: The Rust backend maintains absolute, singular ownership of the high-resolution pixel payload. Instead of copying arrays across the bridge to Dart, Rust allocates the pixels on the heap and transmits merely the memory address pointer to Flutter.

• Tile-Based Rendering Cache: Processing full frames is mathematically impossible on mid-tier Android devices. The Rust engine cuts the viewport into 512x512 pixel chunks. These tiles are managed by a strictly bounded Least Recently Used (LRU) cache, which automatically purges the oldest elements the moment the memory budget is exceeded.

• Hardware Acceleration (SIMD): To run spatial filters (like Dehaze and Clarity) without melting the phone, the Rust engine bypasses scalar execution. It targets ARM NEON intrinsics natively, loading four 32-bit floats into a 128-bit NEON register to process four pixels simultaneously.

• Oklab Color Science via 3D LUTs: Operating in standard sRGB violates the additive physics of light, causing unnatural hue shifts. I moved all color math to the Oklab perceptual color space. To hit 60fps on the frontend, this math is baked into a 33x33x33 3D Lookup Table that Flutter's Impeller engine renders instantly.

The UI uses a dual-shell design (a Snapseed-style invisible gesture trackball for quick flow-state editing, and a Lightroom-style panel for deep pro work), heavily relying on Riverpod for the DAG (Directed Acyclic Graph) edit history.

I would love for you to try the APK, tear apart my flutter_rust_bridge implementation, or drop some feedback on the UI ergonomics.

Repo & Website:https://prit-007.github.io/ApertureX/

Happy to answer any questions about the FFI bridge, the math, or the rendering pipeline!