DEV Community: Luis Scripcaru

Flutter Just Stopped Shipping Fixed UIs. Inside GenUI and the A2UI Protocol

Luis Scripcaru — Mon, 13 Jul 2026 17:49:52 +0000

For most of Flutter's life, the deal has been simple. You write a widget tree, you ship it, and the only thing that changes at runtime is data. The structure of the screen stays frozen the moment you hit build.

That assumption just broke.

At Google I/O 2026, the Flutter team introduced Flutter GenUI, built on an open protocol called A2UI (Agent-to-UI). On paper it reads like a minor SDK addition. In practice it changes what "building a Flutter app" means. I wanted to write it up because it's easy to skim past in a changelog, and it only really clicks once you see what it enables.

The core idea

Instead of a developer hand-writing every screen, an AI agent can now compose real Flutter widgets on the fly. It generates fully interactive layouts based on what the user is actually trying to do, no app store update needed, no pre-baked layout sitting in the code waiting for that exact scenario.

Here's the part that matters: this isn't an image, a web view, or some HTML dropped into a Flutter app. A2UI defines a structured way for an agent (Gemini, Claude, GPT-4o, a local model, whatever speaks the protocol) to describe a Flutter widget tree, and Flutter renders it exactly like hand-written code. Same hardware acceleration. Same interactivity. Same everything.

Two demos at I/O made this concrete rather than abstract:

Finnish it, a language-learning app, generated its practice UI on the fly based on how the learner was interacting with it. The screen wasn't pre-built and swapped in. It was assembled live by a GenUI agent.
Hatcha, an event-planning app, showed the same capability in a completely different domain, which was the point being made: this isn't a party trick tied to one use case.

The part nobody talks about: knowing when not to use it

Honestly, the most useful part of the session wasn't the demo. It was Google DeepMind sharing lessons from building generative UI inside the Gemini app itself. A few of them stuck with me:

Constrain the agent. Give it an opinionated component system, not a blank canvas. Too much freedom produces layout chaos.
Add a critic pass. Running a second model call to review the generated UI before rendering it meaningfully improved reliability.
Template when you can, generate when you must. Deterministic screens should stay deterministic. GenUI earns its keep on personalized, high-variability interfaces, not on your settings page.

That's a healthy amount of restraint for a brand-new capability. It's also the difference between this being a genuinely useful tool and a novelty that makes checkout flows worse.

The DX story that ships with it: Agentic Hot Reload

GenUI is the flashy headline, but the feature that will actually change your day-to-day is Agentic Hot Reload, delivered through the Dart and Flutter MCP server in this same release (Flutter 3.44 / Dart 3.12).

The problem it solves is familiar if you've used any AI coding agent on a Flutter project. The agent edits your widget code, and then you copy output, run commands, wait, and figure out whether the change actually did what was intended. Agentic Hot Reload closes that loop. The agent auto-discovers your running app through the Dart Tooling Daemon, triggers a hot reload the moment it edits code, and can pull back live widget-tree and diagnostic state instead of reasoning about your app from static source alone. It works with any MCP-compatible agent, Gemini CLI, Claude Code, Cursor, Windsurf, so there's no vendor lock-in.

Paired with Flutter Agent Skills (task-specific guidance for things like localization, navigation, and state management, hosted on GitHub), the intent is clear: make AI agents behave like they actually know Flutter conventions, instead of freelancing generic patterns onto your codebase.

Where this sits in the bigger 3.44 release

GenUI didn't ship alone. It landed in a release with an unusual amount of structural change for one cycle:

Impeller is now the only renderer on Android 10+. Skia is gone, which means no more first-launch shader jank.
Material and Cupertino are being decoupled from core Flutter into independently versioned packages, so a new Material 3 component can ship the same day Google's design team finalizes it, not on Flutter's quarterly release cycle.
Swift Package Manager is now the default for iOS/macOS, finally displacing CocoaPods as the out-of-the-box experience.
Dart 3.12 quietly fixed a long-standing annoyance: private fields can now be used as named constructor parameters directly, no manual initializer list required.

None of these are as headline-grabbing as "AI builds your UI at runtime." Together, though, they point at where the framework is heading: a leaner core, faster iteration loops, and design systems that can move at their own speed.

Why I think this matters

Server-driven UI has existed for years as a pattern people reach for when they want to change screens without shipping updates. It has always meant giving up native rendering quality or building a pile of custom plumbing to fake it. GenUI is Google trying to make that pattern a first-class, protocol-level citizen of the framework, with real production lessons baked into the guidance instead of a "figure it out yourself" release note.

It's still labeled preview, and the DeepMind team's own advice, use it selectively, template where you can, tells me this isn't ready to replace your navigation shell just yet. But as a direction for the framework, it's the most interesting thing to happen to Flutter's UI model in a while. Worth having an opinion on before it shows up in a client's requirements doc.

If you're experimenting with agent-driven Flutter workflows already, I'd love to hear what's working, and what's clearly not ready yet, in the comments.

Sources: Google I/O 2026 Flutter session, Flutter and Dart team release notes for Flutter 3.44 / Dart 3.12.

Why I Switched to Slang for Flutter Localization (and You Might Want To Too)

Luis Scripcaru — Thu, 09 Jul 2026 10:26:19 +0000

When I started my first Flutter app, I did what every tutorial told me to do: set up flutter_localizations with .arb files and let the official intl-based codegen handle translations. It worked. It also made me miserable.

Here's why I moved to slang (with slang_flutter) instead, and why beginners especially might want to skip the "official" route.

The problem with ARB + intl

The built-in Flutter localization setup isn't bad, exactly. It's just clunky for small and mid-size projects:

.arb files are verbose JSON with metadata blocks for every single string.
You need flutter: generate: true, an l10n.yaml file, and a rebuild step that sometimes silently fails.
Accessing strings means AppLocalizations.of(context)!.someKey, and that ! is doing a lot of quiet lying to you.
Typos in keys aren't caught until runtime, which for a beginner means a confusing "LateInitializationError" instead of a helpful compile error.

What changed with Slang

Slang flips the experience. You write plain JSON (or YAML/CSV if you prefer) files per locale:

// en.i18n.json
{
  "hello": "Hello $name",
  "login": {
    "success": "Logged in successfully"
  }
}

Run the generator, and you get fully typed Dart code. Usage looks like this:

import 'package:my_app/i18n/strings.g.dart';

String greeting = t.hello(name: 'Tom');
Text(t.login.success);

No context lookups, no nullable bang operator, and (this is the part that sold me) if you typo a key, your code doesn't compile. As a beginner, that single change removed an entire category of "why is my text blank" bugs.

Where Slang beat easy_localization for me

I'd also tried easy_localization before landing on Slang. It's a solid package, but it resolves keys as strings at runtime ('login.success'.tr()), which means the same typo problem as ARB, just with a friendlier API. Slang's compile-time generation is the real differentiator: your IDE autocompletes every translation key, and refactors (renaming a key) are safe, because you're renaming a real Dart property, not a magic string.

Setup, quickly

dependencies:
  slang: ^4.18.0
  slang_flutter: ^4.18.0
dev_dependencies:
  build_runner: ^2.15.1

Drop your JSON files in lib/i18n/, run:

dart run slang

Wire it into MaterialApp:

MaterialApp(
  locale: TranslationProvider.of(context).flutterLocale,
  supportedLocales: AppLocaleUtils.supportedLocales,
  localizationsDelegates: GlobalMaterialLocalizations.delegates,
  child: MyApp(),
)

That's genuinely most of it. Pluralization, rich text, and namespaces are all supported when you're ready to grow into them, but you don't need to touch a single YAML config file to get started, which is rare for an i18n package.

Bottom line

If you're new to Flutter and dreading localization setup, skip the ARB detour. Slang gets you type-safe, typo-proof translations with less boilerplate and a much gentler learning curve. My only regret is not switching sooner.

Have you tried Slang or another i18n package in Flutter? I'd love to hear what's worked for you in the comments.