DEV Community: FlutterSDK

I Built Dusk: Playwright MCP, but for Flutter Apps

Anılcan Çakır — Sun, 14 Jun 2026 17:09:36 +0000

Last week I watched my AI agent try to test a Flutter screen. It wrote a test file, ran flutter test, copied the stack trace back into the prompt, pasted a screenshot, and called it a workflow. It was slow, and it was guessing.

On the web, agents do not work like that anymore. Playwright MCP gives them an accessibility tree to read and stable refs to act on. 33k stars, no screenshot guessing. Flutter never had that layer.

So I built Dusk.

The problem

End-to-end testing on Flutter has always been a stitched-together ritual.

flutter_driver ships a one-off socket protocol and is on the legacy track. integration_test runs in-process against a simulated WidgetTester, but you write a test file, build, run, and wait. Maestro is nice but pays around 3 seconds per action. Patrol is powerful but tends to be unstable on CI.

The deeper issue is the loop. An agent that wants to drive your app reaches for ad hoc flutter test runs, copies stack traces by hand, and pastes screenshots back. There is no live connection between the agent and the running app.

// The old loop: write a test file, build, run, wait, read the failure, repeat.
testWidgets('checkout flow', (tester) async {
  await tester.tap(find.byKey(const Key('checkout')));
  await tester.pumpAndSettle();
  // ...and you still rebuild and rerun the whole thing to see what happened.
});

How Dusk handles it

Dusk attaches to a running Flutter app over VM Service extensions. No test file, no flutter_test harness, no build step. You start your app, attach, and the agent has eyes and hands.

First it snapshots the Semantics tree:

dart run fluttersdk_dusk dusk:snap

That returns a YAML tree with stable [ref=eN] tokens. Every action targets a ref, so there is no brittle XPath and no coordinate guessing.

dusk:tap --ref=e7
dusk:type --ref=e3 --text "ada@fluttersdk.com"
dusk:screenshot

The same contracts power your terminal and your AI agent. dusk:tap --ref=e7 on the CLI and dusk_tap as an MCP tool reach the exact same code path. 32 CLI commands and 31 MCP tools: snap, tap, type, scroll, drag, observe, screenshot, and a hot-reload-and-snap round trip that returns the new tree, a screenshot, and any exceptions in one call.

Why it does not flake

Every gesture passes a 6-step actionability gate before it runs: not defunct, enabled, non-zero rect, on-viewport (it auto-scrolls), stable across 2 frames, and actually hit-testable. So your agent never taps a button that is not really there yet.

This is the part that turns "drive the app" from a demo into something you trust. The boring check is the whole point.

Where it fits

Dusk does not replace your test suite. It owns a different niche: the unscripted, running app.

Tool	What it is	Where Dusk fits
integration_test	Authored test file via `WidgetTester`	Owns the test file. Dusk owns the live, unscripted app. Use both.
patrol	Native dialogs on integration_test	Owns authored tests with native permissions. Dusk owns ad hoc driving by humans and agents.
flutter_driver	Legacy socket protocol	Dusk is hot-restart safe, one contract for CLI and MCP, no separate isolate.
maestro	YAML DSL over the OS accessibility layer	Dusk drives the Flutter widget tree directly. Zero YAML to author.
playwright-mcp	Browser MCP via the accessibility tree	Dusk is the Flutter-native equivalent, ported to Semantics.

Get started

flutter pub add fluttersdk_dusk
dart run fluttersdk_dusk dusk:install

dusk:install patches lib/main.dart behind kDebugMode and scaffolds the CLI. Release builds tree-shake the entire driver across web, desktop, and mobile, so Dusk never ships to production.

Wire it into your agent with one more command:

dart run fluttersdk_dusk mcp:install

That registers the stdio MCP server for Claude Code, Cursor, Windsurf, VS Code Copilot, and any MCP-compatible agent. Dusk also ships its own agent skill, so the agent learns the ref grammar and the tool surface, not just the syntax.

What I learned

Two things stuck with me.

First, the accessibility tree is the right interface for agents on Flutter just as much as on the web. Semantics nodes are stable, cheap, and already there. Screenshots are the slow, expensive fallback, not the default.

Second, the actionability gate matters more than the tool count. An agent that taps confidently on a widget that has not settled is worse than no automation at all. The 6-step check is what makes the rest usable.

Docs: https://fluttersdk.com/dusk
Agent setup: https://fluttersdk.com/dusk/ai

If you try it with your agent, I would love to hear what breaks. That's all.

I Built the iOS 27 Liquid Glass Look in Flutter (No Shaders)

Anılcan Çakır — Thu, 11 Jun 2026 18:24:59 +0000

This week at WWDC 2026, Apple refined Liquid Glass for iOS 27. The headline is a translucency slider that runs from ultra clear to fully tinted, and the whole system reacts to motion: surfaces lens the background, catch specular highlights, and pick up tint from the content behind them.

I wanted to see how close I could get to that look in Flutter. Two problems showed up fast.

Flutter does not ship a Liquid Glass widget

In April 2026 the Flutter team froze new Material and Cupertino design work inside the SDK. New design work, including any iOS 26/27 Cupertino styling, moves to standalone packages later. So there is no official Liquid Glass widget today, and there will not be one for a while.

The community filled the gap with packages that reach for the real optics: BackdropFilter, custom FragmentProgram shaders, refraction, the works. That is the faithful route and it is genuinely impressive. But it also means offscreen render passes and shader code for what is, at the end of the day, a card with a nice background.

I went the other way. I built the look, not the optics, with no shaders and no BackdropFilter at all.

What Liquid Glass actually is (and what I skipped)

Be honest about this part. Apple's Liquid Glass is a real-time optical simulation: it bends light per pixel, samples the layer behind the element, and reacts to device motion. Reproducing that needs Metal-level control of the render pipeline.

I did not reproduce any of that. What I kept is the visual vocabulary that reads as glass:

translucent fills layered over a vivid background
light, semi-transparent borders that catch a highlight
soft depth shadows
generous rounded corners

That is Liquid-Glass-inspired, not Liquid Glass. You get the look; you do not get the lensing. The upside: no offscreen blur pass, so it stays cheap on mid-range devices.

Building it with utility classes

I used Wind UI, our utility-first styling library for Flutter. Think Tailwind, but it compiles classNames to real Flutter widgets. The glass surface is just a WDiv with a className string. No custom painter, no shader, no nesting ten widgets deep.

Here is the core of the translucency card:

WDiv(
  className: '''
    w-[360px] flex flex-col gap-6 p-7 rounded-3xl
    border border-white/40 dark:border-white/30
    bg-white/15 dark:bg-white/10
    shadow-2xl shadow-black/30 dark:shadow-black/50
  ''',
  children: [
    // settings icon, the iOS 27 badge, the slider, the buttons
  ],
)

Read that className and you can see the whole trick:

bg-white/15 is a 15% white fill. Over a colorful background it reads as frosted glass. Wind parses the /15 and applies it with Color.withAlpha, no Opacity widget needed.
border border-white/40 is the catch-light edge. A thin, 40% white border is what your eye reads as the rim of a glass panel.
shadow-2xl is a drop shadow for depth. Important: this is a drop-shadow blur (it softens the shadow itself), not a backdrop blur. The content behind the card is never sampled or blurred.
rounded-3xl and the layered translucency do the rest.

The "glass over color" effect needs something vivid behind it, so the card sits on a gradient with a few color orbs (also just translucent WDivs):

WDiv(
  className: '''
    relative w-[420px] h-[600px] overflow-hidden rounded-[44px]
    bg-gradient-to-br from-orange-300 via-pink-500 to-purple-700
  ''',
  children: [
    WDiv(className: 'absolute -top-14 -left-10 w-56 h-56 rounded-full bg-amber-200/40'),
    WDiv(className: 'absolute top-40 -right-14 w-64 h-64 rounded-full bg-fuchsia-300/40'),
    // the glass card on top
  ],
)

The orbs are not blurred either. They are translucent circles, and the layered transparency is what sells the depth.

Four surfaces, same primitives

I built four iOS-27-style surfaces this way. Same building blocks (translucent fills, borders, shadows, a gradient), different layouts.

1. The translucency control card, the iOS 27 headline feature:

Live and runnable: https://fluttersdk.com/wind/snippets/63ygefgd/flutter-ios-27-liquid-glass-translucency-control-card

2. A floating glass tab bar over a gradient home:

https://fluttersdk.com/wind/snippets/ujfa333h/flutter-liquid-glass-tab-bar-with-floating-navigation

3. A now-playing card where the album art bleeds its color through the surface:

https://fluttersdk.com/wind/snippets/78hfr0re/flutter-liquid-glass-music-player-with-now-playing-card

4. The iOS 27 Siri panel with a soft glow from the Dynamic Island:

https://fluttersdk.com/wind/snippets/nt4rbedt/flutter-ios-27-siri-ai-panel-with-dynamic-island-glow

Every one of these is a WDiv tree with className strings. Open any playground link and you can read the whole source and edit it live.

What I learned

You do not need a shader for the look. Layered translucency over a vivid background gets you most of the way, and it is cheap. Save the shaders for when you actually need refraction.
The border is doing more work than the fill. A thin border-white/40 is the single class that makes a translucent box read as glass instead of a faded box.
Be honest in your copy. This is Liquid-Glass-inspired, not the real lensing. Developers notice, and the honest version is the more useful tutorial anyway.
Utility classes keep the surface readable. The whole glass card is one className string you can scan in a second, not a BoxDecoration buried in a Container buried in a Stack.

Try it

flutter pub add fluttersdk_wind

Docs: https://fluttersdk.com/wind

If you build a Liquid-Glass surface with it, drop a link in the comments. I want to see how far the no-shader approach can go.