DEV Community: K M Shahriar Hossain

LayoutBuilder Does Not Support Returning Intrinsic Dimensions

K M Shahriar Hossain — Wed, 02 Sep 2026 19:51:59 +0000

You put auto-sizing text in a Table cell, hot-reloaded, and got this:

LayoutBuilder does not support returning intrinsic dimensions.

Calculating the intrinsic dimensions would require running the layout
callback speculatively, which might mutate the live render object tree.
  at _RenderLayoutBuilder.computeMaxIntrinsicHeight

The stack trace is long, it points at framework code you did not write, and the
widget worked perfectly ten minutes ago in a Column. So the obvious first
thought is that something is misconfigured.

Nothing is misconfigured. This is Flutter refusing to do something it genuinely
cannot do, and understanding why tells you exactly which layouts will break and
which will not — which is more useful than a workaround, because the same wall
is waiting behind three or four different widgets.

What an intrinsic dimension actually is

Most Flutter layout is a single downward pass. A parent hands its child a set of
constraints — you may be between 0 and 300 logical pixels wide — the child
picks a size within them, and the parent positions it. One pass, no
backtracking, which is why Flutter's layout is linear in the number of widgets
rather than quadratic.

Some widgets cannot work that way. IntrinsicHeight has to make all its
children the height of the tallest one, so it has to know how tall each wants
to be before it can decide what to hand them. Table sizes a column to fit its
widest cell by default. Baseline alignment needs to know where text sits before
it can align on it.

For those, Flutter has a second protocol. A parent can ask a child a hypothetical
question:

If I gave you 200 pixels of width, how tall would you want to be?

That question is computeMaxIntrinsicHeight, and the crucial part is the word
hypothetical. Nothing is being laid out. The child is being asked to predict a
size for constraints it has not been given and may never be given. The answer
must be computed without touching the render tree, because the tree is in the
middle of a layout pass and nothing may move yet.

Why LayoutBuilder cannot answer it

LayoutBuilder exists to run your code with the constraints as an argument:

LayoutBuilder(
  builder: (context, constraints) {
    final size = _bestFontSizeFor(constraints.maxWidth);
    return Text(label, style: TextStyle(fontSize: size));
  },
)

This is how essentially every auto-sizing text package works, and it is a
perfectly good idea. It measures the text at a candidate size, checks whether it
fits the constraints it was handed, and adjusts.

Now look at what answering an intrinsic query would require. To tell the parent
how tall it would be at 200 pixels wide, LayoutBuilder would have to run your
builder callback with maxWidth: 200. Your callback constructs widgets. Those
widgets get mounted into the element tree. That is a mutation — during a
speculative query, for a layout that may never happen, possibly several times
with different widths as the parent searches for a fit.

Flutter's own comment on the matter is blunt about it: doing so "might mutate
the live render object tree". So it refuses, loudly, rather than corrupting your
layout quietly. The error is the framework protecting you.

This is why it is not going to be fixed. It is not an oversight, it is the
boundary between two layout protocols that cannot both be satisfied by the same
widget.

The two-pass problem, and why Flutter avoids it

There is a deeper reason this protocol exists at all, and knowing it makes the
constraint feel less arbitrary.

Web layout is famously able to do this sort of thing — a CSS table sizes its
columns to content without anyone thinking about it. It manages that by doing
multiple passes over the tree, and by having a layout engine that can revisit
decisions.

Flutter deliberately does not. Its layout is single-pass and linear:
constraints go down, sizes come back up, each render object is visited once.
That is a large part of why Flutter can hit 60 or 120fps on a deep tree — there
is no risk of a pathological case where a small change triggers repeated
re-layout of a large subtree.

The intrinsic protocol is the pressure valve. It lets a parent ask a question
without triggering a real layout pass, at the cost of the query being a pure
computation with no side effects. Widgets that use it are explicitly documented
as more expensive, and IntrinsicHeight's own API docs warn that it can be
O(N²) in the depth of the tree.

So when Flutter refuses to let LayoutBuilder participate, it is protecting the
guarantee that makes the whole layout system fast. Allowing it would mean
speculative builder invocations, which is a second pass through user code — the
exact thing the architecture is designed to avoid.

Where this bites

The failure only appears when something above your widget asks an intrinsic
question. That makes it feel random — the same widget works in one screen and
throws in another. It is not random at all. These are the layouts that ask:

Widget	Why it asks
`IntrinsicHeight`	Matches children to the tallest one
`IntrinsicWidth`	Matches children to the widest one
`Table`	Columns size to their widest cell by default
Baseline-aligned `Row`	Needs the text baseline before aligning
`ListView` with `shrinkWrap` in some nestings	Sizes to content

Table is the one that catches people, because nothing about writing
Table(children: [...]) suggests you have just opted into a second layout
protocol. You get a table. You put a heading in a cell. It explodes.

How to tell before you hit it

You do not need to memorise the table. There is a quicker heuristic: if a
widget needs to know its children's sizes before deciding what constraints to
give them, it will use intrinsics.

Column does not — it hands down its own constraints and takes whatever comes
back. IntrinsicHeight does, by definition. Table does, because a column width
is a function of every cell in it.

A second signal is the error itself. If a stack trace mentions
computeMinIntrinsicWidth, computeMaxIntrinsicWidth,
computeMinIntrinsicHeight or computeMaxIntrinsicHeight, you are in the
intrinsic protocol regardless of which widget triggered it.

The fix: do the fitting in a RenderBox

The way out is to stop asking the widget layer to measure things and drop to the
layer that is allowed to. A RenderBox can measure text with a TextPainter
whenever it likes, because a TextPainter is not part of the render tree — it is
a standalone object that lays out a paragraph and reports its size. No mutation,
no speculative element mounting.

That means the fitting can happen in two places that both work:

during performLayout, for the real pass
during computeMaxIntrinsicHeight, for the hypothetical question — because measuring with a TextPainter is exactly the kind of pure computation the intrinsic protocol requires

The binary search for the largest font size that fits is the same algorithm the
LayoutBuilder approach uses. The difference is entirely about where it runs.

This is what I built fit_text to do:

FitText('A headline that must never wrap', maxLines: 1, minFontSize: 12)

It works inside Table, IntrinsicHeight, IntrinsicWidth, baseline rows,
Expanded, and unbounded constraints. The package's test suite contains a case
that puts a LayoutBuilder-based sizer and a FitText in the same widget tree
and asserts that the first throws while the second lays out — so the difference
is pinned by a test rather than claimed in a README.

It has no dependencies, and it runs on all six platforms.

Why TextPainter is allowed and LayoutBuilder is not

The distinction is worth stating precisely, because it is the whole trick.

TextPainter is a standalone object. Constructing one and calling layout()
on it does not touch the render tree, does not mount elements, does not schedule
a frame, and has no effect on anything outside the object itself. It is a pure
function from (text, style, constraints) to a size, with some caching inside.

LayoutBuilder is the opposite. Its entire purpose is to run a callback that
builds widgets, and building widgets means creating elements and mounting them
into the tree. That is a side effect, and side effects are exactly what an
intrinsic query is forbidden to have.

So the rule generalises beyond text. If you can compute your intrinsic size
with a pure function, you can implement the intrinsic protocol. If computing
it requires building widgets, you cannot, and no amount of cleverness at the
widget layer will change that. Drop to a render object and compute directly.

If you would rather not add a package

You do not have to. The approach is the point, and it is reproducible:

Subclass RenderBox rather than composing widgets.
Keep a TextPainter as a field. Call layout() on it with candidate styles.
Binary search font size between your minimum and maximum, checking didExceedMaxLines and the resulting size against the constraints.
Implement computeMinIntrinsicWidth, computeMaxIntrinsicWidth, computeMinIntrinsicHeight and computeMaxIntrinsicHeight using the same measurement, and do not touch the tree in any of them.
Cache by (text, constraints, style) — intrinsic queries are called more often than you expect, sometimes several times per frame.

Point five is the one people miss. Table may ask each cell more than once while
resolving column widths, and a binary search over twenty font sizes per query
adds up quickly in a list.

The subtleties that bite in a custom implementation

If you do write your own, these are the ones that cost an evening each:

didExceedMaxLines is not enough on its own. Text can fit within maxLines and still be wider than the constraint if a single word cannot break. Check the painted size against the constraints as well as the line count, or a long unbroken token will silently overflow at your minimum size.
textScaler must be part of your cache key. A user changing their system font size will not invalidate a cache keyed only on the string and the box.
TextDirection is required and easy to forget, since it usually comes from the ambient Directionality. In a render object you have to thread it through yourself.
Round your candidate sizes. A binary search over continuous doubles will happily spend iterations distinguishing 14.001 from 14.002. Search in whole or half points and stop.
Respect the minimum. When even minFontSize does not fit, decide deliberately whether to overflow, clip or ellipsise — and make it a parameter, because different call sites genuinely want different answers.

The short version

LayoutBuilder cannot answer intrinsic queries because answering them means
running your builder, and running your builder means mutating the tree during a
speculative measurement. Any auto-sizing built on LayoutBuilder inherits that
limit. Move the measurement into a RenderBox with a TextPainter and the
limitation disappears, because measuring a paragraph was never the thing that
needed the tree.

If you want it already done: fit_text on pub.dev, MIT
licensed, no dependencies.

Originally published at devshakib.jumyn.com. I write about Flutter, Dart and the parts of shipping that are genuinely awkward — and publish the packages that came out of them at pub.dev/publishers/jumyn.com.

Running Apple's On-Device AI From Flutter, With No API Key and No Server

K M Shahriar Hossain — Wed, 02 Sep 2026 19:08:58 +0000

Every "add AI to your Flutter app" tutorial ends the same way: get an API key,
add a billing card, send the user's text to somebody else's server, and hope the
latency is tolerable.

On iOS 26 and macOS 26 there is a different option that most Flutter developers
have not tried, because the plugins did not exist. Apple ships a language model,
an image generator and a LiDAR room scanner on the device. No key, no
account, no per-token cost, no network — and nothing the user types leaves their
phone.

I built three packages to reach them from Flutter. This is what each one can
genuinely do, and where each one stops.

The language model

final session = await LanguageModelSession.create(
  instructions: 'You summarise text in one sentence.',
);
print(await session.respond(article));
await session.dispose();

That runs entirely on the device. It streams, it supports tool calling, and —
the part that matters most in practice — it does schema-constrained structured
output. You describe the shape you want and the model is constrained to produce
it, rather than being asked nicely in a prompt and then parsed hopefully.

If you have ever written a retry loop around jsonDecode because a hosted model
returned prose instead of JSON, that is the problem this removes at the source.

Structured output is the feature

It is worth dwelling on this one, because it is the difference between a demo
and something you can put in a product.

The usual pattern with a hosted model is: write a prompt asking politely for
JSON, get back something that is usually JSON, wrap jsonDecode in a
try/catch, add a retry, and accept a failure rate you cannot drive to zero. Every
production LLM integration has this scar tissue.

Schema-constrained generation removes the problem rather than mitigating it. The
model is constrained during sampling to tokens that keep the output valid
against your schema. It is not being asked to produce the right shape; it is
unable to produce a wrong one.

For anything where the model's output feeds code rather than a human — extract
these fields, classify into these categories, pull the dates out of this text —
that is the difference between a feature you ship and a feature you keep
apologising for.

Tool calling, on-device

The model can also call functions you expose. The pattern is the familiar one —
you describe the tools, the model decides when to call them, you run them and
hand back results — but with the round trip happening entirely on the device.

The practical use is less "agents" and more "give the model access to the user's
own data without that data going anywhere". A tool that reads the user's local
notes or transactions lets the model answer questions about them, while the notes
themselves never leave the phone. That is not achievable with a hosted model at
any price.

Where it stops. This is a small model. It is very good at summarising,
extracting, classifying, rewriting and answering questions about text you give
it. It is not a frontier model and it will not reason its way through a hard
novel problem. Treat it as a fast, free, private text-processing engine and it
is excellent. Treat it as a substitute for a large hosted model and it will
disappoint you.

apple_foundation_models — iOS and macOS.

Image generation

await for (final image in ImageCreator.generate(prompt)) {
  setState(() => _preview = image);
}

Image Playground generates on the device too, and the API streams partial
images as they are made. That is not a nicety, it is the entire user
experience. Here is the timing I measured:


first image	6.8s
second image	10.3s
size	~4 MB PNG each

Seven to ten seconds of a spinner feels broken. Seven to ten seconds of an image
visibly resolving in front of you feels like something is being made for you.
Same wait, completely different experience — which is why the package streams by
default rather than offering it as an option.

The same package also wraps the native text field that carries Writing Tools
and Genmoji, so users get the system rewrite, proofread and summarise
affordances they already know from Notes and Mail, in your app, without you
building any of it.

Why streaming is not a nicety

Look at the timings again and think about what the alternative looks like.

A modal spinner for 6.8 seconds is a long time. Long enough that a meaningful
share of users will assume it has hung and back out. Long enough that on the
second image, at 10.3 seconds, some will kill the app.

The same 10.3 seconds spent watching an image emerge from noise into shape is not
a wait at all — it is the product. The user is watching their idea being made.
Nobody backs out of that, because there is visible progress on every frame.

This is the general lesson for on-device generation, not a quirk of this API. The
compute is slower than a datacentre GPU. You cannot fix that. What you can do is
make the latency visible and interesting rather than hidden behind a spinner,
and the perceived experience inverts.

Budget around 4 MB per PNG, which matters if you are storing or syncing them.

apple_intelligence — iOS and macOS.

Scanning a room

final controller = RoomScanController();

RoomPlan uses the LiDAR sensor to scan a room and hand back structured geometry:


`walls`, `floors`	surfaces with metre dimensions and a transform
`doors`, `windows`, `openings`	found within the walls
`objects`	recognised furniture — chair, table, bed, storage…
`usdzPath`	a USDZ model, ready for AR Quick Look
`raw`	RoomPlan's own encoding, untouched

Real dimensions in metres, not a point cloud you have to interpret. For anyone
building for interiors, property, removals, insurance or furniture retail, that
is the difference between a demo and a product.

The package deliberately hosts Apple's own scanning UI rather than
reimplementing it. Users have seen that interface in Apple's Measure app; the
coaching overlays that tell you to move slower or point at the wall are tuned by
people with the sensor data. Replacing that with a custom camera view would be
worse in every way that matters.

roomplan — iOS, LiDAR required.

What RoomPlan is actually for

The USDZ output gets the attention because it drops straight into AR Quick Look.
The structured geometry is the more valuable half.

Because you get walls with metre dimensions, doors and windows located within
them, and recognised furniture, you can answer questions rather than just display
a model: will this sofa fit through that door? how much paint for these
walls? what is the floor area, excluding the built-in wardrobe?

That is the difference between a scanning feature and a product. Estate agents,
removals firms, insurers, interior retail and trades all have a version of that
question, and all of them currently answer it with a tape measure and a phone
call.

The limits, plainly

These are Apple frameworks, so the constraints are Apple's:

iOS 26 / macOS 26 or newer. There is no polyfill. Check availability and design a fallback path — all three packages expose a capability check, and you should call it before showing any UI that depends on the feature.
Apple Intelligence must be enabled by the user on a supported device. Availability is not the same as "the device is new enough".
RoomPlan needs LiDAR — Pro iPhones and iPads, not the base models.
iOS and macOS only. Nothing here runs on Android or the web, and no amount of wrapping changes that.

Which is why the honest framing is not "replace your hosted model". It is: for
the substantial set of tasks these handle, you get them for free, instantly,
offline, and without any user data leaving the device — and you fall back to
whatever you use today when the device cannot help.

That fallback path is not a workaround. It is the design.

Checking availability properly

There are three separate questions and they have three different answers, which
is why a single isSupported boolean is not enough:

Is the OS new enough? A compile-time and runtime version check.
Is the hardware capable? Apple Intelligence needs specific silicon; RoomPlan needs LiDAR.
Has the user enabled it? Apple Intelligence is opt-in and can be off on a perfectly capable device.

Only the third can change while your app is running, and it is the one people
forget. Query availability at the point of use rather than caching a result from
launch, and design the UI so an unavailable feature is absent rather than
present-and-failing. A greyed-out button with a tooltip explaining an OS
requirement is worse than not showing the button, because it advertises
something the user cannot act on.

Why on-device is worth the trouble

Three reasons that survive contact with a real product.

Cost. Per-token pricing turns every active user into a running bill.
On-device inference costs nothing and does not scale with success.

Latency. No round trip. For summarise-as-you-type or classify-on-paste, the
difference between 40ms and 900ms is the difference between a feature people use
and one they wait for.

Privacy you can state simply. "Your notes never leave your phone" is a
sentence you can put in an App Store listing and defend. It is also the only
version of that promise that is true without a legal team.

The honest comparison

To be clear about when not to reach for these:

	On-device	Hosted
Cost per call	none	per token
Latency	~40ms to first token	300ms–2s round trip
Works offline	yes	no
Data leaves device	no	yes
Reasoning depth	limited	frontier
Platform	iOS/macOS 26+	anywhere
Availability	user must enable	always

The right architecture for most apps is both: on-device for the high-frequency,
low-complexity, privacy-sensitive work, hosted for the occasional hard question,
and a capability check deciding which one runs. That is not a compromise, it is
just using the cheaper tool for the easier job.

All three packages are MIT licensed with public source, and all three hold a
perfect 160/160 on pub.dev. Start with whichever problem you actually have —
the full list is here.

Why Your Loading Spinner Flickers, and the Two Rules That Fix It

K M Shahriar Hossain — Wed, 02 Sep 2026 19:07:49 +0000

Every Flutter app has this somewhere:

bool _loading = false;

Future<void> _signIn() async {
  setState(() => _loading = true);
  try {
    await api.signIn(email, password);
  } finally {
    setState(() => _loading = false);
  }
}

And a Stack with a spinner on top when _loading is true. It is the first
thing everyone writes, it is in every tutorial, and it is correct in the sense
that the state is never wrong.

It also looks broken on a fast connection, and the reason is worth understanding
properly — because the fix is not a nicer spinner, and no amount of animation
polish will help.

The failure is in the timing, not the widget

Your API call returns in 90 milliseconds. At 60fps that is about five and a half
frames.

So the spinner mounts, paints for five frames, and unmounts. The user does not
perceive "loading". They perceive the screen flinching — a flash of grey, a
shape that appeared and left before their eye could settle on it. On a fast
network, every single tap does this.

It gets worse when the timing sits near the boundary. A call that takes 200ms
on Wi-Fi and 900ms on cellular produces two entirely different experiences from
the same code: a flash on one, a legible wait on the other. Users on the fast
network get the glitchy one, which is precisely backwards.

There is decades-old research on this. Jakob Nielsen's response-time limits put
0.1 seconds as the threshold below which an action feels instantaneous, and
1 second as the limit for uninterrupted flow of thought. The important
implication is the one most implementations miss: below about 100ms, showing
progress is worse than showing nothing, because the feedback itself becomes
the disruption.

A bool cannot express that. A bool says "in flight" or "not in flight", and
maps both directly to pixels. What you need is a third state — in flight, but
not yet worth mentioning — and that requires a clock.

Rule one: nothing paints before the reveal delay

Start a timer when the operation begins. If the operation finishes before the
timer fires, render nothing at all. No spinner, no scrim, no success tick.
The screen never moves.

A threshold somewhere around 140ms works well in practice. Below it, an
operation is fast enough that feedback is noise. Above it, the user has begun to
wonder whether their tap registered, and feedback is reassurance.

This single rule eliminates the majority of flicker in a typical app, because
the majority of requests in a typical app are fast. Cached reads, local
database queries, a warm API on a good connection — all silent.

Rule two: once it paints, it holds

The second rule is less obvious and just as important.

Say your reveal delay is 140ms and the request finishes at 170ms. Without a
second rule, the spinner appears for 30 milliseconds. You have replaced a
five-frame flash with a two-frame flash, which is worse.

So once the overlay commits to appearing, it stays for a minimum — half a second
is a good default. The user waits slightly longer than strictly necessary, and
in exchange the interface reads as deliberate rather than glitchy.

That trade is worth being explicit about, because it sounds wrong at first: you
are deliberately making the app slower. But perceived performance is not average
latency. An interface that is 300ms slower and never flinches feels faster and
more trustworthy than one that is technically quicker and visibly twitchy. The
user is not timing you with a stopwatch; they are forming an impression of
whether the software is solid.

Those two rules are the whole reason loading_kit
exists:

final user = await Loading.run(
  () => api.signIn(email, password),
  message: 'Signing in…',
  successMessage: 'Welcome back',
);

run rethrows whatever the task threw, so your error handling is unchanged.
Everything else in the package follows from taking blocking state seriously
rather than from having more spinner shapes.

The six things a bool never handles

Timing is the headline. These are the problems that show up afterwards, once a
real app grows past one screen — and each one is a bug I have seen in production
code that started as bool _loading.

Concurrent requests

Two operations start. The first finishes and sets _loading = false. The second
is still running, and the overlay is gone — the user can now tap into a screen
that is mid-mutation.

The fix is reference counting: the overlay leaves when the last operation
retires, not the first. Related: if one request succeeds while another is still
in flight, busy must outrank settled, or a check mark flashes mid-flight and
tells the user the work is done when it is not.

The overlay outliving its screen

A request starts on the profile screen. The user hits back. The request fails
slowly. The finally block runs on a State that is no longer mounted, or the
overlay is hosted above the navigator and is now sitting over a completely
different screen with a message about a profile the user has left.

This needs route awareness — an observer that clears overlays when the route
beneath them changes. A bool in a State cannot know that a navigation
happened somewhere above it.

Input that leaks through

A Stack with a spinner on top does not necessarily block taps. If your overlay
does not have an opaque hit-test target, the buttons underneath are still live
and the user can fire the same request three times.

Keyboard focus

Even with taps blocked, a hardware keyboard can still tab to buttons under the
scrim and activate them with Enter. On desktop and web that is a real
double-submit path, and it is invisible in testing because nobody tabs during a
loading state on purpose.

The blocked subtree needs to come out of focus traversal entirely.

Screen readers

A visual spinner communicates nothing to a screen reader user. Without markup
they get silence, then the screen changes.

The overlay should be a live region that announces its message and its progress,
and — just as important — the blocked application underneath should be hidden
from the accessibility tree with BlockSemantics, or the user can navigate to
controls that no longer work.

Reduced motion

If the platform asks for reduced motion, the entrance animation should drop its
scale. It is a small thing that takes one conditional, and it is the sort of
thing that never gets added to a hand-rolled overlay because it is nobody's
ticket.

When an overlay is the wrong answer

The mistake in the other direction is blacking out the entire application for
something small.

A form that saves in place does not need the whole screen scrimmed — it needs
that form to stop accepting input. Scoping the overlay to a subtree keeps the
rest of the app usable, and it should still apply the same timing policy so a
fast save flashes nothing:

LoadingBarrier(
  loading: _saving,
  message: 'Saving…',
  borderRadius: BorderRadius.circular(16),
  child: const ProfileForm(),
)

And a great deal of what gets a spinner should not block anything at all. Work
that has already succeeded, or that continues in the background, wants a toast:

Loading.toast('Draft saved');
Loading.toastSuccess('Order placed');
Loading.toastError('Could not sync', detail: 'Retrying in the background');

The rule of thumb: block only when proceeding would be wrong. If the user
could carry on doing something else while this finishes, taking the screen away
from them is a bug in the design, not a loading state.

Progress, and when to offer cancelling

Indeterminate spinners are honest when you genuinely do not know how long
something will take. When you do know — uploading eleven files, processing a
list — show it:

await Loading.runTask((task) async {
  for (var i = 0; i < files.length; i++) {
    task.throwIfCancelled();
    task.report((i + 1) / files.length, detail: '${i + 1} of ${files.length}');
    await upload(files[i]);
  }
}, message: 'Uploading…', cancelAfter: const Duration(seconds: 3));

Two details in there matter more than the progress number.

cancelAfter reveals the cancel affordance only once that much time has
passed. A cancel button on a one-second operation is clutter that nobody will
ever click. A cancel button on a thirty-second upload is the difference between
a patient user and a force-quit.

Cancellation is cooperative. Tapping cancel rejects the future immediately
so the UI responds at once, and the body stops at its next throwIfCancelled().
Pretending you can abort arbitrary Dart mid-execution would be a lie; making the
cancellation points explicit is the honest version.

For long work, a bar reads better than a ring. The difference between 60% and
70% is obvious in a line and genuinely hard to judge in a circle:

LoadingStyle.material.copyWith(progressStyle: LoadingProgressStyle.bar)

One continuous form, not three widgets

A detail that is easy to skip and changes how the whole thing feels.

Most implementations swap widgets at each stage: a CircularProgressIndicator,
then an Icon(Icons.check), then nothing. Three unrelated shapes appearing in
the same slot. Each swap is a small visual discontinuity.

Drawing all the states as one CustomPainter means the arc closes into a
ring, crosses to the terminal colour, and strokes the check inside itself. The
outcome grows out of the waiting rather than replacing it. It costs one painter
instead of three widgets, and it is the difference between an interface that
transitions and one that cuts.

Making it free when idle

An overlay host sits above your entire app, so its cost while nothing is loading
matters more than its cost while something is.

With nothing in flight it should build SizedBox.shrink() — no scrim, no blur,
no ticker, no hit-test target. And critically, the app subtree must be passed
through by identity, so that when loading starts and stops Flutter can skip
rebuilding your entire application. If your overlay wrapper rebuilds its child,
every loading state in your app is now a full rebuild.

Two more that add up:

Stop the ticker when it settles. A repeating animation left running through the exit transition schedules frames for no reason.
Scope any blur to the card. A backdrop filter over the whole screen is one of the most expensive things you can composite; clipped to a small card it is cheap.

Testing timing behaviour

The nice property of making the rules explicit is that they become testable —
on Flutter's fake clock, with no real waiting:

testWidgets('a fast call shows nothing', (tester) async {
  final controller = LoadingController();
  addTearDown(controller.dispose);

  final work = controller.run(
    () => Future.delayed(const Duration(milliseconds: 80)),
  );
  await tester.pump(const Duration(milliseconds: 80));
  expect(controller.value.visible, isFalse);

  await tester.pump(const Duration(milliseconds: 400));
  await work;
});

One caveat that applies to any indeterminate indicator, including Flutter's own:
a spinning arc schedules a frame forever, so pumpAndSettle() will never
settle while one is on screen. Pump explicit durations instead. This catches
people out and produces mysterious test timeouts that look like a deadlock.

If you take nothing else

You do not need a package for any of this. The two rules are twenty lines:

Start a timer on begin. Paint nothing until it fires — around 140ms.
Once painted, hold for a minimum — around 500ms.
Reference-count so overlapping operations do not strand each other.
Block input and focus, not just taps.
Announce to screen readers, and hide the blocked app from the a11y tree.
Do not block at all unless proceeding would be wrong.

That list is most of the value, and it applies whatever you build it with.

If you would rather have it done: loading_kit is on
pub.dev — MIT, no dependencies, all six platforms, 160/160 pub points. Five
presets that resolve against your ThemeData, six indicator styles, and an
indicatorBuilder slot if you would rather supply a Lottie file or your own
brand mark and keep only the timing behaviour.