What's New in Flutter 3.35: Productivity, Previews, and Performance

Beyond the headline stable-hot-reload-on-web change, 3.35 carries a lot of accessibility work worth knowing about: semantics now respect the user's preferred locale for screen readers, SemanticsLabelBuilder replaces ugly string concatenation for composed labels, and offscreen items in complex scrollables stay represented in the semantics tree instead of disappearing. Material and Cupertino both pick up new widgets — DropdownMenuFormField, a scrollable NavigationRail for large menus, CupertinoExpansionTile — plus higher-fidelity touches like true RSuperellipse corner shapes and haptic feedback on Cupertino sliders and pickers.

The experimental Widget Previewer is the one to watch even though its API is still early — running a widget in isolation with theme and screen-size variations, without bootstrapping a full app, is exactly the missing piece for iterating on a design system. It's paired with groundwork for Wasm web builds (a dry-run flag flags anything incompatible, like dart:mirrors usage) and a stable MCP server that lets AI coding assistants auto-resolve common runtime errors like RenderFlex overflow.

Accessibility, in More Detail

The locale-aware semantics change matters more than it sounds — a screen reader announcing content in the wrong language for a bilingual or multi-region app is a real, jarring experience, not a cosmetic gap. SemanticsLabelBuilder cleans up a pattern that used to be genuinely awkward:

// Before: manual string concatenation, easy to get wrong across locales
Semantics(label: '${item.name}, ${item.price} dollars, ${item.inStock ? "in stock" : "out of stock"}')

// After: composed pieces the framework assembles correctly
Semantics(
  label: SemanticsLabelBuilder()
    .add(item.name)
    .add(item.priceLabel)
    .add(item.inStock ? 'in stock' : 'out of stock')
    .build(),
)

Offscreen items staying in the semantics tree fixes a specific, previously-annoying bug class: a screen reader user swiping through a long list that virtualizes its widgets would sometimes have items silently vanish from the accessibility tree the moment they scrolled out of the rendered viewport, even though they were still logically part of the list.

New Widgets, Concretely

DropdownMenuFormField wires DropdownMenu directly into Form validation — previously this required wrapping DropdownMenu manually in a FormField to get validation error text, a small but common pain point. The scrollable NavigationRail matters for any app with more destinations than fit in a fixed-height rail on a tablet or foldable — it degrades gracefully instead of silently clipping items. CupertinoExpansionTile fills a gap that's existed since Material's ExpansionTile shipped years ago — iOS-styled apps previously had to hand-roll the expand/collapse animation to match platform conventions.

The visual polish items compound more than they look on paper: RSuperellipse corner shapes are the actual curve iOS uses for app icons and cards (not a true circular-arc rounded rectangle), so widgets using it now match native iOS chrome pixel-for-pixel instead of approximating it. Haptic feedback on Cupertino sliders and pickers is the kind of detail that's invisible until you compare it side-by-side with a native iOS control and notice the difference immediately.

The Widget Previewer, and Why It's Worth Tracking Early

Even in its experimental state, the pitch is straightforward: annotate a widget, run the previewer, and see it rendered with theme and screen-size variations — without spinning up the full app, navigating to the screen, and hot-reloading through whatever setup gets you there. That's the exact workflow gap Flutter's had compared to component-driven tools like Storybook in the React ecosystem, where isolating and iterating on one component is the default way of working rather than something bolted on.

Groundwork You'll Feel Later

The Wasm dry-run flag is a forward-looking addition — Flutter's push toward WebAssembly as a first-class web compilation target means catching incompatible patterns (dart:mirrors usage being the most common one) early, before a team discovers it during an actual Wasm migration attempt, saves real debugging time down the line.

The stable Dart & Flutter MCP server is arguably the most consequential change for anyone using AI coding assistants day to day — instead of an assistant guessing at a fix for a RenderFlex overflow from generic pattern-matching, it can query actual structured Flutter context (the widget tree, the specific constraint violation) and produce a fix that's correct for this layout rather than a plausible-looking one that happens to compile.

Should You Upgrade to Flutter 3.35?

None of 3.35's changes are individually breaking in a way that demands an immediate upgrade, but the accessibility fixes and the new form-validated dropdown are worth pulling in for any app actively shipping UI work, and teams already experimenting with AI-assisted Flutter development get real, immediate value from the MCP server the moment they upgrade.