المكوّنات

A pill-shaped action button rendered as liquid glass.

This is a plain widget: drop it anywhere in your layout (a Row, a Column, a Stack) and it renders a single LiquidGlassLens around its label/icon. It needs no position and no LiquidGlassView on Impeller; on Skia / Web place it inside a LiquidGlassView so it has a background to refract.

Styling uses one LiquidGlassStyle (style — shape + appearance + refraction), defaulted to a tuned iOS-style glass, so the simplest call is just label + onPressed. For a solid call-to-action (e.g. a blue "Continue"), pass a style with a colored tint — compose from defaultStyle to keep the rest of the tuned look:

A floating action button (FAB) rendered as liquid glass.

Supports standard circular FABs, custom child FABs, and extended FABs with an icon and label via LiquidGlassFab.extended.

Drop it anywhere in your layout or pass it to LiquidGlassScaffold's floatingActionButton slot.

Alias for LiquidGlassFab.

A generic dialog container rendered as a liquid glass surface.

An alert dialog rendered with a liquid glass surface.

Features standard Material 3 dialog slots (icon, title, content, actions) elevated on top of a frosted refractive liquid glass lens.

Displays a liquid glass dialog over the current route.

Uses showGeneralDialog with a tuned scale + fade modal animation to present LiquidGlassAlertDialog or custom LiquidGlassDialog widgets.

On Impeller the dialog takes a backdrop read of its own, even inside a LiquidGlassScaffold: the route sits outside the scaffold's tree, where no batch reaches it. Pass batch to have it join the scaffold's chrome batch instead — the read its tab bar's capsule already takes — so the dialog costs no read beyond that one. The batch then covers the whole dialog, its own glass and its buttons alike, and the copy they all sample was taken before the tab bar and the route painted: the dialog refracts the page as it lay under the bar, with no tab bar glass in it and no barrier scrim, and glass inside it — its buttons — reads that page rather than the dialog's surface; wrap it in LiquidGlassBatch.exclude to get that back. Outside a scaffold, or with the scaffold's batch off, the flag does nothing. On the Skia / Web capture path there is no shared key and it does nothing either.

A sheet of liquid glass — the panel showLiquidGlassSheet presents, and an ordinary widget you can place yourself.

It draws the surface and nothing else: the glass, an optional grabber, an optional header and the padded child. Where it sits and how it is dragged belong to whatever presents it.

The sheet takes the height it is given and hugs its content when it is given none, so all of these work:

On Impeller it works standalone; on Skia / Web it needs an ancestor LiquidGlassView with a background to refract.

Presents builder's content on a LiquidGlassSheet.

This is Flutter's own showModalBottomSheet with the glass put where its filled Material used to be: the route, the slide-up, the drag, the barrier and the dismissal are all Flutter's, unchanged, and every parameter of theirs is forwarded here. What the sheet looks like is this package's — style is the same LiquidGlassStyle vocabulary every other component takes.

Because it is the Material route underneath, everything you already know about it holds: isScrollControlled for a sheet taller than nine sixteenths of the screen, constraints to bound it, transitionAnimationController to drive it yourself. For a sheet that resizes as you drag it, put a DraggableScrollableSheet in a showModalBottomSheet and place a bare LiquidGlassSheet inside its builder — the glass has to be within what resizes, and this presenter wraps your content from outside it.

On the Skia / Web capture path, a sheet builds in the navigator's overlay rather than inside the LiquidGlassView that captured the page. showModalBottomSheet carries the ambient themes across for its own reasons, and the view's lens scope rides along with them, so a sheet opened from a context inside a view refracts the page behind it. Impeller never needed it.

On Impeller the sheet takes a backdrop read of its own, even inside a LiquidGlassScaffold: the route sits outside the scaffold's tree, where no batch reaches it. Pass batch to have it join the scaffold's chrome batch instead — the read its tab bar's capsule already takes — so the sheet costs no read beyond that one. The batch then covers the whole sheet, its own glass and every lens in builder's subtree alike, and the copy they all sample was taken before the tab bar and the route painted: the sheet refracts the page as it lay under the bar, with no tab bar glass in it and no barrier scrim, and glass inside the sheet reads that page rather than the sheet's surface; wrap it in LiquidGlassBatch.exclude to get that back. Outside a scaffold, or with the scaffold's batch off, the flag does nothing. On the Skia / Web capture path there is no shared key and it does nothing either.

How a LiquidGlassSheet meets the bottom of the screen.

مزلاج زجاجي يرتفع مقبضه ليصير عدسة تحت إصبعك، ويتمدّد بمقدار سرعة دفعك له، ثم يستقر عائداً إلى مساره. يملك زجاجه بنفسه فلا يحتاج عدسة حوله.

Geometry of a LiquidGlassSlider: the track, the two thumb sizes it morphs between, and the end icons.

The thumb has two sizes, not one. At rest it is a small solid pill lying in the track (thumbWidth × thumbHeight); the moment a finger lands it morphs into a larger glass pill (liftedThumbWidth × liftedThumbHeight) that is carried until the touch ends. The defaults are the tuned pair; scale both together if you resize one, or the morph changes proportion mid-flight.

A drop-in liquid-glass switch, in the sliding style where the thumb is picked up and carried rather than snapped between two ends.

You give it a value and an onChanged like a regular Switch; it owns its own LiquidGlassView, the colored track, the glass thumb and the whole touch simulation.

The behaviour it carries:

• A two-state thumb. A contracted solid pill (37×24) morphs into an expanded glass pill (58×38.33) the instant a touch lands (0.4 s, ζ 0.6 — bouncy), and back on release (0.6 s, ζ 0.7). One size + cover-fade morph, since both layers scale in lockstep.
• The thumb rides the finger 1:1, relative to where it was at touch-down, with a sqrt(overrun) rubber band past the two resting positions, saturating at LiquidGlassSwitchLayout.overshootRoom — the room the capture view actually reserves, which an unbounded sqrt would spend under a mouse. The track never deforms — the give is all in the thumb's overshoot.
• Dragging into an edge toggles early. Carry the thumb to within 5 px of the far position and the state flips right there — haptic tick, track color cross-fading under your finger (0.25 s) — while the thumb stays held. Dragging back can flip it again.
• Tap vs drag by distance, then time. A gesture that carried the thumb past kTouchSlop is a drag however brief it was — a mouse crosses the whole control inside any tap window. Anything else under 150 ms is a tap: haptic, color, thumb spring-gliding across (0.5 s, critically damped), contraction 0.2 s later. A drag that never reached an edge always toggles on release, so a long-press-and-release flips the switch.
• Programmatic changes stay calm. A new value arriving from outside while idle glides the thumb and cross-fades the track without ever expanding the thumb.

Refraction & the overhang The expanded thumb grows larger than the track, so its overhang samples the (transparent) area around the capsule. The shader honors the captured texel's alpha, so that overhang renders as transparent passthrough instead of a black blob. On the Impeller backdrop path the overhang refracts the live backdrop directly.

Sizing The track's two sizes are parameters here:

They size the track, not the thumb. For the whole switch in proportion, scale the layout — layout: const LiquidGlassSwitchLayout() .scaled(1.4) — and for anything finer, state it on layout outright: a LiquidGlassSwitchLayout carries the track's width and height, the thumb's resting size and the size it swells to. The resting positions, the travel, the rubber band's limits and the capture view are all derived from those. width and height are a shorthand for the layout's own two fields and win over them.

The control's layout footprint is the track alone (63×28 by default) while the glass painted around it is larger: the expanded thumb and its bounce overflow the footprint deliberately and are not clipped to it. See reserveSwellRoom if an ancestor clips.

Sizing for LiquidGlassSwitch — the track behind the thumb and the two sizes the thumb itself morphs between.

Everything the control positions is derived from these numbers: the two resting positions, the travel between them, the rubber band's limits, and the capture view painted around the whole thing. Change width and height and the rest follows.

The defaults are the iOS-26 sliding switch: a 63×28 track carrying a 37×24 handle that swells to 58×38.33 while it is held — wider AND taller than the track it sits in, which is why the thumb overhangs.

A sheet of liquid glass that MORPHS to fit whatever you put in it.

Swap the child and the glass measures the new one and flows to its size. You do not tell it how big to be:

That is the whole API. Add a row to Menu and the glass grows to match, because there is only one truth about how big the menu is and the glass reads it rather than being told it a second time.

width and height are OVERRIDES for the cases where you genuinely own a dimension — a sheet with detents, a fixed-width menu whose height varies. Set one and that axis is pinned while the other is still measured; set both and nothing is measured at all.

How it moves

The morph is two blobs of one liquid, rendered as a single surface by a LiquidGlassBlender. The new shape is born inside the old one and grows around its anchor while that anchor travels to where it will finally sit; the old shape lingers, then drains into it. The two are joined by the blender's smooth union while they overlap, so mid-morph the outline has a waist — which is what a resize can never have and what the eye reads as liquid. At rest the blobs coincide and the union is switched off, so the resting shape is exact.

Which of those you get is the motion: pick one of its presets. One of them, LiquidGlassMorphMotion.plain, is not two blobs at all but a single lens whose outline springs from the old shape to the new: no neck, no drain, one backdrop pass. Any preset becomes that kind with copyWith(blended: false).

Each blob keeps its own corner curve and radius. Nothing is interpolated or swapped: the old shape is drawn as the old shape until it is gone, and the new one as its own from the moment it appears.

Content is not stretched with the glass. The old child blurs, fades and scales out; the new one blurs, fades and scales in around the anchor as the glass arrives, pinned where it will finally sit. Both run on the morph's own clock — its duration is the spring's period — at the fractions LiquidGlassMorphAdvanced names: the old child is gone by contentOutEnd, the new one starts at contentInStart and has landed by contentInEnd. A swap that reverses mid-flight carries each child on from wherever it had got to, so a child that had not yet appeared never does. And the material thickens as the glass grows — more blur, deeper refraction — the way Apple's does when a menu opens from a button.

Layout, and why alignment matters

This widget fills the box it is given and places the glass inside that box according to alignment. It has to: a size on its own does not say which way a surface should grow, and that is the difference between a morph that works anywhere and one that only works in the middle.

Centred, both edges move and every direction looks correct — which is exactly why getting this wrong stays invisible until you move the thing. At Alignment.centerLeft the left edge holds and it opens rightward; at Alignment.bottomRight that corner holds and it opens up and to the left. Grow symmetrically at an edge and the surface walks across the screen or straight off it.

Alignment is continuous, so this is not a nine-position menu: an axis at x sends (1 + x) / 2 of any size change out one side and the rest out the other. Alignment(-0.37, 0.12) is as valid as Alignment.centerLeft. If the surface is placed by something that is not an alignment — a Positioned, a list, a drag — use alignmentFor to recover the alignment its own rect implies.

Under unbounded constraints there is no box to anchor inside, so the widget shrinks to the glass and alignment stops mattering.

How a LiquidGlassMorph travels between shapes.

Pick a preset and stop there — they are the whole point:

A morph is two blobs of one liquid, not a box being resized. The new shape is born inside the old one and grows around its anchor while that anchor travels to where it will finally sit; the old shape lingers, then drains into it. The two stay joined by a neck until the new shape has swallowed the old. This descriptor is the physics of that: one spring, how far the leading blob runs ahead of its own size, and where it grows from. The quantities that are set once and left alone live in LiquidGlassMorphAdvanced, behind advanced.

blended is the exception: false drops the second blob and the blender with it, and the morph is a single lens whose outline springs from the old shape to the new — no neck, no drain, one backdrop pass. That is what plain is; any other preset becomes the one-lens kind with copyWith(blended: false).

The morph's duration — what the content timing in advanced is a fraction of — is the spring's own period, 2π / √stiffness: the number LiquidGlassMorphMotion.spring takes as duration, and 0.45 s for the presets.

The knobs of LiquidGlassMorphMotion that are set once and then left alone — grouped so they stay out of the way without being out of reach.

Reach for them when the preset is nearly right but one thing is off: the old shape hangs around too long (linger), the new content lands too early (contentInStart), the neck is too fat too soon (neckRamp).