u/RutabagaLow6979

What they do is let you build custom scrollable layouts where each child controls its own scroll behavior and geometry. That might not sound like a big deal but it is — because it means you can have headers that pin, sections that shrink, and lists that collapse all in one scroll view without hacking anything together. Its performant in a way that most nested scroll approches aren’t.

I think the reason nobody uses them is the API looks kind of intimadating at first. You implement a SliverPersistentHeaderDelegate and override build and maxExtent and minExtent, and your dealing with shrinkOffset and overlap values to drive your UI. Coming from ListView brain it feels foriegn. But once it clicks it clicks.

stuff like collapsing app bars with custom content, sticky section headers, parallax hero images at the top of a scroll view — anything where you’ve got scroll-driven UI that needs to feel native and smooth. people oftentimes reach for NestedScrollView with a bunch of workarounds for this kind of thing and it works but Slivers are doing it cleaner and cheaper under the hood.

Honestly the Flutter docs don’t do it any favors. The example they give is not exactly inspiring. But if you go look at how the actual Flutter team uses it internally (SliverAppBar is built on it) that’s where it starts to make sense.

Anyway if ya’ll never looked at it, worth 20 minutes. Might save you from a janky NestedScrollView solution next time you need somthing like this. I personally didn’t know about this until recently

Has anyone actually used custom Slivers in a real project??? Curious what the use case was. And are there other widgets like this that feel to intimidating on the surface but are worth digging into?”

Similar vibe to that Flow widget post from a bit ago — another Flutter thing that looks scary from the outside but once it clicks it's kind of a superpower.

Most people see CustomPainter and think "ok that's for drawing circles and lines, not for me." And yeah it does that. But the deeper thing is that you're working completely outside the widget tree. No rebuilds. No layout passes. You get a Canvas and you just... paint. Directly to the screen.

The part that might change how you think about it is repaint boundaries. Wrap your CustomPaint in a RepaintBoundary and that layer becomes totally isolated. So if you've got some animation going crazy in one corner of the screen, the rest of your UI doesn't care. Doesn't even know it happened.

stuff where this actually matters:

- particle systems or anything with dozens of moving objects

- waveform visualizers, audio stuff

- custom chart rendering where a library is overkill

- game-adjacent UI (health bars, radar, that kinda thing)

basically any time you've got a LOT of things moving and you've been reaching for AnimatedContainer or whatever — that's probably the wrong tool and you know it because your frame times are suffering lol

the Canvas API itself is not that bad either. drawPath, drawCircle, drawImage — its pretty readable once you stop being intimidated by it. The hard part is the coordinate math but thats just math, not Flutter weirdness.

also shouldRepaint. People either return true always (bad, unnecessary repaints) or return false always (also bad, stale renders). Its a simple method but you gotta actually think about what state your painter depends on.

Flutter docs are decent on this one compared to Flow tbh but still dont really show you when to reach for it vs just using widgets.

anyway same question as last time — has anyone shipped something real with CustomPainter? I know someobdy out there built a whole charting thing with it. Also curious if anyone has mixed CustomPainter with Fragment shaders becuase that rabbit hole seems deep and kind of terrifying

Been working on a small but meaningful update to Spoken Animals, my Flutter app that teaches kids about animals through sounds and cards.

The new feature: tap any animal card and get 3 AI-generated fun facts written specifically for young kids, followed by a chat interface where they can ask follow-up questions. Something like “why do elephants have big ears?” and actually get a real answer, not a pre-written script.

The backend is Firebase Cloud Functions (Python) + LangChain + Gemini Flash. The system prompt enforces child-safe, animal-only responses — no violence, no predator/prey gore, warm and encouraging tone throughout. If the AI produces something off-topic or malformed after a couple retries, it falls back to “I’m still learning about this animal!” rather than surfacing an error to a 5-year-old.

Still in progress but the architecture is solid. Curious if anyone else has shipped AI features in kids’ apps and run into content safety edge cases I haven’t thought of yet.

App is iOS, free with a expansion packs that can be added: https://apps.apple.com/us/app/spoken-animals/id6753104253

What it does is let you do custom multi-child layouts but the delegate runs during the paint phase instead of the layout phase. That might not sound like a big deal but it is — because it means you can reposition children during animations without triggering a full layout pass. Its fast in a way that most custom layout approaches aren’t.

I think the reason nobody uses it is the API looks kind of scary at first. You implement a FlowDelegate and override paintChildren, and your passing transform matrices to position each child. Coming from Row/Column brain it feels weird. But once it clicks it clicks.

stuff like animated radial menus, expanding toolbars, fan animations — anything where you’ve got multiple children that need to fly around in response to some animation value. people oftentimes reach for Stack with a bunch of AnimatedPositioned widgets for this kind of thing and it works but Flow is doing it cleaner and cheaper under the hood.

Honestly the Flutter docs don’t do it any favors. The example they give is not exactly inspiring. But if you go look at how the actual Flutter team uses it internally (NavigationToolbar uses it) that’s where it starts to make sense.

Anyway if ya’ll never looked at it, worth 20 minutes. Might save you from a janky Stack solution next time you need something like this. I personally didn’t know about this until recently

Has anyone actually used Flow in a real project??? Curious what the use case was. And are there other widgets like this that feel to intimidating on the surface but are worth digging into?

Okay so the Flutter and Dart teams just shipped something quietly cool — official Agent Skills repositories, and they work with basically every major AI coding assistant out there.

Here's the quick rundown. There are two official repos now:

• flutter/skills — layouts, routing, JSON serialization, integration tests, overflow fixes
• dart-lang/skills — unit test gen, pub dependency resolution, static analysis fixes Install them into your project with one command:

npx skills add flutter/skills --skill '*' --agent universal
npx skills add dart-lang/skills --skill '*' --agent universal

That dumps everything into .agents/skills and your agent (Claude Code, Cursor, Copilot, Antigravity, whatever you're using) just... picks them up automatically.

---

So why is this actually interesting and not just more AI slop??

Instead of cramming a wall of instructions into a rules file and hoping the agent remembers them, skills use progressive disclosure — the agent reads just the metadata first, then pulls in the full instructions only when it needs them for a specific task. Context window stays lean, and the agent gets laser-focused guidance exactly when it matters.

Think of it like giving your AI a proper runbook instead of just vibes.

And it goes further — the skills CLI on pub.dev can pull skills directly from your dependency tree, meaning packages could eventually ship their own skills alongside their code. Imagine adding a package and your AI agent automatically knows how to use it correctly.

---

Are you already using agent skills or custom rules files in your Flutter projects? Has AI-assisted Flutter dev actually clicked for you yet, or does it still feel like more trouble than it's worth? And which AI assistant are you reaching for most — Claude Code, Cursor, something else?

Flutter has a global boolean you can set at the top of main() that most devs have never heard of:

import 'package:flutter/widgets.dart';

void main() {
  debugPrintRebuildDirtyWidgets = true;
  runApp(const MyApp());
}

One line. Now every widget that rebuilds gets logged to the console — "Rebuilding MyWidget" — for every dirty widget built each frame.

The first time you turn this on in a real app it's kind of humbling. You tap a button and watch half your widget tree light up in the console when you expected maybe two or three rebuilds. That's the moment you realize something needs fixing.

It's also a natural companion to RepaintBoundary — use this flag to find what's rebuilding when it shouldn't be, then wrap the offenders.

There are a few related flags worth knowing too. debugPrintScheduleBuildForStacks gives you a full stack trace for each rebuild trigger so you can see exactly what caused it. debugProfileBuildsEnabled sends the same data to the DevTools timeline instead of the console if the firehose of logs gets overwhelming.

And the best part: it's wrapped in assert() internally, so it's automatically stripped in release builds. You don't have to remember to remove it.

One line to turn on, zero cost in production. Not sure why this isn't talked about more.

---

Have you ever turned on something like this and been surprised by how much was rebuilding that you didn't expect? And are there other debug flags you reach for regularly that don't get enough attention?

Think Tony Stark’s JARVIS, running entirely on your own machine.

Axon is a multi-agent system: a Commander that breaks down your requests and delegates to specialized workers — research, building, creating, communicating. You give it a goal and it executes while you go live your life.

What makes it different:

•	Voice calls — literally dial in, ask what it’s doing, redirect it mid-task. Axon narrates its current state conversationally: “I’ve got three agents running — the Researcher is pulling sources, the Builder is halfway through your draft.”  
•	Live screen share — say “show me your screen” and it drops a link in Telegram. You open it in your browser and watch it work in real time — browser tabs, terminals, files, everything  
•	Proactive agent — it doesn’t just wait for you. It surfaces things it thinks you should know and acts on scheduled tasks in the background  
•	Confirmation Gate — pauses and asks before doing anything irreversible  
•	Two-tier memory — knowledge graph for machine recall + human-readable notes that synthesize what it’s learned about you over time  
•	Fully self-hosted — your data never leaves your machine

Planning to release as a turnkey self-hosted product. One command to spin up, Flutter mobile app to command it from anywhere.

Would love feedback — especially from anyone who’s built agentic systems or wrestled with the voice/screen share layer.

Basically what it does is stop Flutter from nuking your tab or page state when you swipe away from it.

The thing is most devs dont even know they have the bug. You swipe to a different tab, come back, and your scroll position resets or your initState fires again and kicks off another API call. You just kinda assume thats how PageView works. It’s not lol.

The fix is slapping AutomaticKeepAliveClientMixin on your State class, overriding wantKeepAlive to return true, and calling super.build(context) at the top of your build method. Thats litterally it.

Most useful when your tabs have lists with scroll position, forms a user is mid-way through filling out, or anything doing a network fetch on init. Basically any statefull tab content.

Quick way to confirm you have the problem before fixing it — throw a print in initState. If it fires everytime you come back to a tab, yeah you’ve got it.

Idk why this one doesn’t get brought up more. Would’ve saved me a good chunk of time if I’d known about it sooner.

Anyone else run into this and just assumed it was normal behavior for a while? Also curious — are you guys using this or just reaching for IndexedStack instead? Is there a reason people prefer one over the other?

Basically what it does is isolate a subtree from the rest of the widget tree for repainting purposes. So when something inside it changes, Flutter only repaints that region instead of potentially walking up and repainting a bunch of ancestors too.

The practical use case is wrapping things like animations or frequently updating widgets so they don’t cause unecessary repaints elsewhere in the tree. You can verify it’s working by turning on “Highlight Repaints” in DevTools — it color codes regions that are repainting each frame so you can actually see what’s happening visually instead of just guessing.

The other thing it can do that I didn’t know about until recently — if you attach a GlobalKey to one, you can call toImage() on it and capture the widget as an image at runtime. So if you need to screenshot a specific widget programatically, you don’t actually need a package for it. It’s built in.

Not sure why this widget doesn’t come up more. Feels like the kind of thing that would save people some headscratching if they knew about it earlier.