DEV Community: flutter

Offline-First Flutter Architecture

ROCI — Sun, 06 Sep 2026 13:03:25 +0000

Deep dive into offline caching with Hive and SQLite.

What It Actually Takes to Run a Cross-Border Marketplace: Six Years of Shpper

K M Shahriar Hossain — Sun, 06 Sep 2026 12:16:06 +0000

Shpper is a cross-border personal-shopping marketplace. A buyer wants something
they cannot get where they live. A traveller is already flying that route with
unused luggage space. The platform introduces them, holds the money until the
item arrives, and turns an empty few kilos in someone's suitcase into a delivery
network.

I am the CTO. I own the platform end to end — the Flutter apps for both sides,
the backend, payments and escrow, identity verification, and the release
pipeline. We are on version 14.2.0, rated 4.64 on the App Store from 72 ratings.

Fourteen major versions is enough distance to say something useful about what
this kind of product actually demands. Almost none of the hard parts were the
ones I expected.

You are not building one app

The first structural fact about a two-sided marketplace is that "the app" is two
products with opposed interests, and you ship both.

The buyer wants their item cheaply, quickly, and with certainty it will arrive.
The traveller wants to be paid well, carry as little risk as possible, and not be
blamed for customs. Those are not complementary desires. Every feature has to be
designed twice, from two points of view, and any change to the shared middle —
the request, the offer, the trip — reaches into both.

This has a consequence people underestimate: your release cadence is bounded by
the slower side. A change to how offers work is not shipped when the buyer app
ships. It is shipped when both apps are live, on both platforms, and enough of
both populations have updated. Mobile app review is not a build step you can
optimise away; it is a scheduling constraint that shapes how you design changes,
which is why so much of the logic has to be able to change without a release.

The hard problem is trust, and it is not a feature

A marketplace's actual product is trust between strangers. Everything else is
plumbing.

Consider what the platform is asking. A buyer sends money for an item that does
not exist yet, to be bought by someone they have never met, in a country they
are not in, and carried across a border. A traveller agrees to spend their own
money on someone else's goods, in exchange for a promise of repayment, and to
carry those goods through customs under their own name.

Neither side would do that for a stranger. They do it because the platform
stands between them, and everything about the engineering follows from that
position:

Escrow is not a payments feature, it is the entire trust mechanism. Money is
held from the moment a deal is struck until the item is confirmed delivered. That
single design decision is what makes the rest possible — the buyer risks nothing
until they have the item, and the traveller knows the money genuinely exists
before they spend their own.

Identity verification is what makes escrow meaningful. Held funds only
protect you if there is a real, identified person on the other end when
something goes wrong. Verification is not a compliance checkbox bolted on for
regulators; it is the thing that makes the escrow promise enforceable.

The state machine is the product. A request becomes an offer, becomes an
accepted deal, becomes a purchase, becomes a carried item, becomes a delivery,
becomes a release of funds. Every transition can fail, and each failure needs a
defined answer: what happens to the money, what each side sees, who is told what
and when. The unhappy paths outnumber the happy one, and they are where the
product either holds together or falls apart.

Money makes everything irreversible

Ordinary app bugs are annoying. Bugs that touch money are a different category,
because you usually cannot fix them by shipping a patch.

A double-charge is not resolved by correcting the code — the money has already
moved, and now there is a human on the other end who is angry and correct to be.
A payout that fires twice is gone. A state transition that releases escrow early
cannot be un-released by a hotfix.

This changes how you write things. Every money-moving operation has to be
idempotent, because networks retry and users tap twice and both of those are
normal. State transitions have to be atomic, because a partial write in the
middle of a payment is worse than a failure. And ledgers have to be
append-only — the record of what happened is not something you edit, because the
moment it is editable it stops being evidence.

None of this is exotic. All of it is the difference between a bug you fix and a
bug you refund.

Cross-border is a category of its own

Everything above applies to any escrow marketplace. Crossing a border adds
problems that are not software problems at all, and the engineering has to
absorb them anyway.

Prices move while a deal is open, because currencies move. Customs and duty are
real costs that land on somebody, and the product has to be unambiguous about who
before anyone commits, not after. Items that are perfectly ordinary in one
country are restricted in another. Trips get cancelled, delayed, or rerouted, and
a delivery network built from other people's travel plans inherits all the
volatility of those plans.

The engineering lesson is that a design which assumes stability will spend the
rest of its life being patched. Timelines slip, prices change, routes vanish.
Building for that from the start is much cheaper than discovering it across
fourteen versions.

What being CTO of this actually means

The title suggests architecture diagrams. The reality is that owning it end to
end means the boundary between "engineering problem" and "business problem" does
not exist.

When a delivery goes wrong, the question is not only what the code did. It is
what the policy should be, who absorbs the cost, what both users are told, and
what changes so it happens less often. That is one conversation, not four, and
being the person who understands both the state machine and the commercial
consequence is most of the job.

The other half is choosing what not to build. Every marketplace has an infinite
backlog because both sides always want more, and the sides want different things.
Fourteen versions in, the decisions I am most glad about are almost all
subtractions.

The stack, briefly

Flutter for both apps, so one codebase covers iOS and Android on each side —
which matters enormously when "shipping a feature" already means shipping two
products. Firebase for the backend. The choice that has aged best is not a
technology but a principle: keep as much behaviour as possible changeable
without an app release, because you cannot hotfix your way out of a marketplace
problem when app review sits between you and your users.

The thing I would tell someone starting one of these: you are not building
software that connects buyers and sellers. You are building the reason two
strangers are willing to take a risk on each other, and every technical decision
either strengthens that or quietly erodes it. Escrow, verification, and an
honest state machine are not features on a roadmap. They are the product, and
everything else is how it is delivered.

Shpper is at shpper.com, and there is a longer
case study on this site.

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.

Your Flutter 404 Page Is Probably Crashing, and Your Server Is Probably Lying About It

K M Shahriar Hossain — Sun, 06 Sep 2026 12:16:05 +0000

Someone sent me a screenshot of my own 404 page. Washed-out grey text on a light
background, barely readable, nothing like the dark theme every other page uses.
My first thought was a styling bug.

It was not a styling bug. The page was crashing before it could paint, and the
fallback I had built for exactly that case was doing its job. Underneath it was a
second bug that had been hiding the first one for months.

Bug one: the status code was a lie

The site is a Flutter web app with every route prerendered to a real HTML file.
Firebase Hosting served those files, and anything unmatched hit a catch-all
rewrite:

"rewrites": [
  { "source": "**", "destination": "/404.html" }
]

That looks right. It is not, and the reason is worth internalising: a Firebase
rewrite always responds 200. That is what a rewrite is — serve this other
content under the requested URL. So every nonexistent URL on the site returned
200 OK with a page that said "Page not found".

Browsers do not care. Crawlers care a great deal. A 200 means "this is a real
page, index it", so every typo, every dead inbound link, every scanner probing
for /wp-admin was eligible to be indexed as a real page. This is the soft 404,
and it is invisible from a browser because the page looks correct.

The fix is to delete the catch-all rather than repoint it. With every real route
prerendered as a file, Firebase serves those directly, and for anything with no
matching file it falls through to its own handling — which serves 404.html
with an actual 404 status.

One caveat that will bite you if your app has client-only routes. My admin panel
has no prerendered file, so removing the catch-all 404'd my own admin URL. It
needs a rewrite scoped to that path alone:

"rewrites": [
  { "source": "/your-client-only-path/**", "destination": "/index.html" }
]

Scoped rewrites for the routes that genuinely need them; no catch-all; real 404s
for everything else.

Bug two: the page was crashing the whole time

Fixing the status code is what made me actually look at the page, and that is
when the grey rendering stopped looking like a theme problem.

My prerendered HTML carries the page's text in the DOM, clipped to a single
pixel, with a boot guard that reveals it if Flutter never paints. The idea is
that a failed boot shows the content rather than a spinner turning forever. So
the washed-out text was the guard firing correctly, telling me Flutter had
died.

The console had it:

GoError: There is no GoRouterState above the current context.
This method should only be called under the sub tree of a RouteBase.builder.

Here is the chain. errorBuilder renders my NotFoundPage. That page uses the
same shell as every other page, and the shell contains the nav bar, and the nav
bar asks which route is current so it can highlight the right link:

final current = GoRouterState.of(context).uri.path;

On every real route that is fine. On the 404 page it throws, because
errorBuilder renders outside any RouteBase.builder — there is no route
subtree above it and therefore no GoRouterState to inherit.

The fix that does not exist, and the one that also fails

The instinct is maybeOf. In go_router 17 there is no GoRouterState.maybeOf.
of() throws unconditionally; there is no nullable variant to fall back to.

So the next instinct is to ask the router itself, which definitely sits above
everything:

current = GoRouter.of(context).state.uri.path;   // also throws

I tried exactly this, and it fails too — differently, which is what makes it
interesting. GoRouter.state reads matches.last on the current match list, and
on an unmatched URL that list is empty, so you get a StateError: Bad state: No element. The accessor fails for precisely the reason you are on the 404 page
at all.

Both router-side answers are dead ends. But the browser knows the path regardless
of what the router made of it:

String current;
try {
  current = GoRouterState.of(context).uri.path;
} catch (_) {
  current = Uri.base.path;
}

The broad catch is deliberate, and I would defend it specifically here.
Determining which nav item to highlight is decoration. This widget renders inside
every page on the site. Failing at decoration must never be able to take down the
page around it, and the two failure modes above are different exception types
from different call sites — narrowing the catch buys nothing except a chance to
miss the third one.

Nothing highlights on a 404, which is correct: no nav item corresponds to a page
that does not exist.

Why it survived so long

Because the two bugs concealed each other. The 404 page had been broken for
months and rendered identically whether it answered 200 or 404 — so nothing
looked wrong from a browser, and nothing in the logs distinguished it. Crawlers
saw 200 and were happy. I never visited my own 404 page, because why would I.

The status-code fix did not cause the crash. It made someone look at the page,
which is a different and more useful thing.

Two habits fall out of this. Check your 404 page's status code, not just its
appearance — curl -o /dev/null -w '%{http_code}' https://yoursite/nonsense
takes two seconds and is the only way to see a soft 404. And actually load your
error page in a browser after a routing change, because it is the one page in
your app that renders through a completely different code path from every other
page, and therefore the one page your testing never touches.

A Squarified Treemap by Hand, Because Charting Packages Cannot Drill Down

K M Shahriar Hossain — Sun, 06 Sep 2026 12:15:09 +0000

Helm's storage tool shows your disk as a treemap: every folder a rectangle,
every rectangle sized by how much space it takes. Click one and you are inside
it, looking at its children, with a breadcrumb trail back out. It goes from a
494 GB volume down to a single file.

I drew it by hand. Not because the packages are bad, but because the thing that
makes a treemap useful for disk space is the part they do not expose.

What the packages give you, and what they don't

Search for a Flutter treemap and you will find several that work. Hand them a
list of values, get back a coloured rectangle layout. For a dashboard showing
revenue by region, that is the whole job.

A disk browser needs four things beyond that, and each one reaches into the
layout rather than sitting on top of it:

Hit-testing that returns the node, not a coordinate. A tap has to resolve to which folder, at whatever depth you are currently at.
Navigation as a first-class state. Diving into a rectangle re-lays out the entire canvas from a new root, and the breadcrumb has to be able to climb back.
Labels that adapt. A rectangle 400 px wide gets a name and a size. One 20 px wide gets nothing, because a clipped half-word is worse than blank space.
Layout over a subtree, not a list. The input is not fifty values, it is a tree with a million nodes, and you lay out one level at a time.

Any one of those is a fork of the package. All four means you are writing it
anyway, and you would rather own it than fight an abstraction built for a
different problem.

Squarified, and why it is worth the trouble

The naive treemap slices the rectangle repeatedly along one axis. It is easy and
it produces slivers — long thin shapes that are impossible to read, impossible
to tap, and misleading, because human eyes judge area badly when the aspect
ratio is extreme.

The squarified algorithm keeps rectangles as close to square as it can. The idea
is simple enough to hold in your head: sort children largest first, then add
them one at a time to the current row while doing so improves the worst aspect
ratio in that row. The moment adding one makes the worst ratio worse, close the
row, and start a new one in the remaining space.

That is the entire algorithm. Sort descending, accumulate greedily, close the
row when the worst ratio stops improving, recurse into the space that is left.

Two implementation notes that cost me time:

Sort descending or the greedy step is meaningless. The whole method assumes
you place the biggest item first. Feed it unsorted input and it still produces
a layout — a bad one, with no error to tell you why.

Guard against zero. Empty folders, and the remaining space after the last
row, both produce zero-width or zero-height rectangles, which turn into
divide-by-zero in the ratio computation and NaN in the layout. NaN
propagates silently through a layout pass and you get an empty canvas with no
exception, which is a genuinely unpleasant thing to debug.

Making it fast enough over a real disk

Scanning a 347 GB volume walks several hundred thousand files. Two things keep
that from freezing the UI, and neither is about the treemap itself.

Scan off the main isolate. Walking a filesystem is not CPU-heavy so much as
relentless — hundreds of thousands of stat calls. Done on the main isolate it
blocks the frame loop, and the app appears hung exactly while it is doing the
work the user asked for.

Lay out one level at a time. The tree has a million nodes; the screen shows
a few dozen rectangles. There is no reason to lay out anything but the current
level's children. Diving in is a fresh layout over a smaller subtree, which is
why it stays instant no matter how deep you go — the work is bounded by what is
visible, not by what exists.

The second point is the one that also solves the label problem. Because you only
lay out the visible level, you know each rectangle's real pixel size at paint
time, so deciding whether a name fits is a measurement rather than a guess.

The bit that has nothing to do with drawing

The hardest part of Helm's storage tool is not the treemap. It is making the
numbers agree with the operating system.

macOS reports purgeable space — snapshots and caches the system will reclaim
when it needs to. If you sum file sizes and ignore purgeable, your total
disagrees with About This Mac, and when a user sees two numbers they believe the
one from Apple. Correctly, too: yours is the one that is wrong.

So the categories have to be disjoint buckets that reconcile to the volume's
reported capacity, purgeable included as its own slice rather than quietly
dropped or quietly counted as used. A beautiful visualisation of numbers the
user does not trust is worth nothing, and trust here is a single comparison
against a system dialog they already know.

Was it worth writing?

For a dashboard, no — use a package. For anything where the treemap is the
interface rather than a picture of the data, you will end up writing it, because
drill-down, hit-testing and adaptive labels all live below the API surface that
a general charting package exposes.

The reward is that it is genuinely the fastest way to answer "what is eating my
disk". A list of the largest folders makes you read and compare. A treemap makes
the answer the biggest thing on screen.

Helm is free and MIT, and the treemap is in
lib/tools/storage/ui/widgets/treemap.dart if you want to read it rather than
reimplement it: github.com/devShakib015/helm.

المنصة اللي جاية بعد الموبايل مش خيال علمي

Ahmed ElFirgany — Sun, 06 Sep 2026 09:54:12 +0000

المنصة اللي جاية بعد الموبايل مش خيال علمي — بتتبنى قدام عينينا دلوقتي.

جوجل هتطلق أول نظارة AI ليها في ٢٠٢٦، سامسونج طلعت Galaxy AI Glasses بالفعل، وRayNeo عرضت جيل جديد بالتعاون مع Dolby وBang & Olufsen. تلات شركات عالمية بتتسابق في نفس السنة بالظبط — ده مش تجربة، ده بداية سباق منصة حقيقية.

قضيت ٥ سنين أبني للموبايل. ولسه معتبرش نفسي خلصت، بس المنصة اللي بنيت عليها شغلي عمره كله بقى ليها منافس واقف في الصف جنبها.

السؤال مش هل النظارات هتاخد مكان الموبايل. السؤال: مين من المطورين هيبقى جاهز لما اللحظة دي تيجي؟

إنت متابع المنصة الجاية دي، ولا لسه مركّز بس في اللي إنت فيه؟

الذكاءالاصطناعي #نظاراتذكية #هندسة_الموبايل #Flutter

David Stark: Top High-Paying Roles

David Stark — Sun, 06 Sep 2026 02:24:46 +0000

👋 Hello Architects & Elite Engineers,

The market is shifting. We are seeing a surge in MOBILE roles this week.

We don't do "Easy Apply". Our internal gatekeeper just processed 200+ verified remote jobs from our partner network. To get these jobs, you must pass the architecture audit.

Here are the Top 5 roles worth your time today.** 👇

1. Staff Software Engineer

🏢 Samsara | 💰 Competitive | 📍 Remote

Could you walk us through your experience with this tech stack?

Tech Stack:
.samsara.com/

About the role:

Samsara (NYSE: IOT) sits a...

👉 Apply & View Full Salary

2. Senior Quality Engineer (Montevideo)

🏢 LawnStarter | 💰 Competitive | 📍 Remote

Could you walk us through your experience with this tech stack?

Tech Stack:
This is a remote role for candidates located in Montevideo, Uruguay. <...

👉 Apply & View Full Salary

3. Senior Quality Engineer (São Paulo)

🏢 LawnStarter | 💰 Competitive | 📍 Remote

Could you walk us through your experience with this tech stack?

Tech Stack:
This is a remote role for candidates located in São Paulo, Brazil. </p...

👉 Apply & View Full Salary

4. Senior Quality Engineer (Mexico City)

🏢 LawnStarter | 💰 Competitive | 📍 Remote

Could you walk us through your experience with this tech stack?

Tech Stack:
This is a remote role for candidates located in Mexico City, Mexico.
<p...

👉 Apply & View Full Salary

5. Software engineer

🏢 Sticker Mule | 💰 Competitive | 📍 Remote

Could you walk us through your experience with this tech stack?

Tech Stack:
.stickermule.com

Sticker Mule is building the Internet's most lucrative commerce...

👉 Apply & View Full Salary

🚀 Want more?

👉 View the full board of 50+ New Jobs here

🛑 Stop doing 7-round HR interviews. We hold direct contracts with hiring CTOs for high-ticket roles. Accept the architecture challenge, get your Instant AI Score, and bypass HR completely. 👉 Take the CTO Challenge

Saving a Real File From Flutter Web, Instead of Downloading Another Copy

K M Shahriar Hossain — Sat, 05 Sep 2026 23:32:13 +0000

Build an editor on Flutter Web. The user opens budget.csv, edits it, hits
save. They get budget.csv in their Downloads folder.

They edit again, save again: budget (1).csv.

Again: budget (2).csv.

Their real file — the one on their Desktop that they opened — has never been
touched. By the end of an afternoon they have nine numbered copies and no idea
which is current. This is not a Flutter problem; it is what "saving" has meant on
the web for twenty years. The browser hands you a download, and a download is
always a new file.

The API that changed this

The File System Access API gives a page a real handle to a real file, with
the user's permission, granted through the browser's own picker. With a handle
you can write back to the same file. Not a copy. That one.

It is a genuine capability, gated properly: the user picks the file, the browser
mediates every access, and the permission can be revoked. There is no way for a
page to reach a file the user has not deliberately handed over.

final file = await FileSystemAccess.openFile();
await file.write(bytes);   // the same file, in place

No download. No (1). The file on their Desktop now has their edits.

Why the old way works the way it does

The download-a-copy behaviour is not laziness on anyone's part. For most of the
web's history, a page having write access to your filesystem would have been an
enormous security hole, so the only sanctioned direction was out: the page
produces bytes, the browser saves them somewhere the page cannot see or reach.

That is why <a download> and the blob-URL trick that every Flutter Web file-save
snippet uses cannot ever overwrite. They are not writing a file. They are handing
the browser a payload and asking it to save one, and "save one" means a new one.

Understanding that is what tells you the File System Access API is a genuinely
different mechanism rather than a nicer wrapper over the same thing. The
permission model changed; the API followed.

Coming back after a reload

The second half is what makes it feel like an application rather than a web page.

Handles can be persisted. Store one, and after a page reload — or the next
morning — you can ask for that same file again. The browser will re-prompt for
permission, which is correct and is the point, but the user is confirming access
to a file they already chose rather than hunting through a picker to find it
again.

That single behaviour is the difference between "a web tool I paste things into"
and "the thing I edit my file with".

Handles are stored in IndexedDB — they are structured-cloneable objects, not
strings — so they persist like any other browser data and survive until the user
clears site data. Which means the recovery flow is:

On startup, look for a stored handle.
If there is one, ask whether permission is still granted.
If it is, open silently and show the document.
If it is not, show one button: Reopen budget.csv.

Step four is the honest version of "restore my session". You are not
re-prompting for a file the user must find again; you are asking them to confirm
a file you both already know about.

Directories, not just files

The same API grants handles to whole directories. That unlocks a different class
of application entirely — a project folder, a photo set, a folder of Markdown
notes — where the app can enumerate, read and write within the folder the user
chose, and nothing outside it.

For anything resembling an editor, that is the difference between a single-file
toy and something people keep their work in.

What you must handle

This is where an honest package earns its keep, because the API is not
universally available and pretending otherwise produces a broken app on a third
of browsers.

Support is real but partial. Chrome, Edge and other Chromium browsers have
it. Safari and Firefox largely do not. So the capability check is not optional
housekeeping — it decides which UI you show:

if (await FileSystemAccess.isSupported) {
  // "Save" — writes in place
} else {
  // "Download a copy" — the old behaviour, honestly labelled
}

Label the fallback accurately. A button that says Save and silently produces
budget (3).csv is worse than a button that says Download a copy, because the
first one lies about what just happened.

Permission is per-handle and revocable. A write can fail because the user
revoked access, or the file moved, or the browser dropped the grant. Handle it as
a normal outcome rather than an exception path you never test.

It needs a user gesture. The picker cannot be opened from a timer or an
async continuation far from a tap. Open it directly in the button handler.

Design for the fallback, do not bolt it on

The temptation is to write the good path and add a fallback later. That produces
an app whose Safari experience is an afterthought, and Safari is not a rounding
error.

A structure that works: define one interface with open, save and saveAs.
Implement it twice — once over the File System Access API, once over the classic
picker-and-download. Choose at startup. The rest of your app never branches, and
the difference is confined to which implementation is behind the interface and
what the save button says.

The label matters more than it sounds. If the fallback button says Save and
produces budget (3).csv, the app has lied about what it did. If it says
Download a copy, the user understands the platform limitation immediately and
does not blame the app when their original file is unchanged.

Why this matters more on Flutter Web than elsewhere

Flutter Web is unusually good at the kind of app this unlocks — editors,
spreadsheets, diagram tools, code playgrounds, anything with a document. Those
are exactly the apps where "download another copy" is most obviously wrong.

It is also the gap people cite when they say Flutter Web "isn't ready for real
apps". Not being able to save a file properly is a fair thing to hold against a
platform. It is no longer true, on the browsers that matter, and it is worth
knowing.

A note on security, since people ask

Every time this API comes up someone asks whether a web page can now read their
whole disk. It cannot, and the reasons are worth knowing so you can answer the
question when a user asks you:

Every handle comes from a user gesture through the browser's own picker. A page cannot construct a handle to a path it names.
Access is per-handle. Being granted budget.csv grants nothing about the folder it sits in, or any other file.
The browser blocks sensitive locations — system directories, and in Chromium's case a maintained blocklist that includes things like the user's home root and library folders.
Permission is revocable and is re-confirmed after a reload rather than granted permanently in the background.
It requires a secure context. No HTTPS, no API.

The design is closer to "the user hands your app a file" than to "your app gets
filesystem access", which is the right shape for a capability this significant.

Try it

file_system_access is on pub.dev — MIT, 160/160
pub points. It wraps the picker, the in-place write, the persisted handle and the
capability check.

It returns false from the capability check on browsers that cannot do this,
rather than throwing or half-working — so your fallback is a decision you make at
startup rather than a crash you discover from a Safari user three weeks after
launch.

Scrolling to an Index in a Flutter Lazy List, Without Building Everything Above It

K M Shahriar Hossain — Sat, 05 Sep 2026 23:22:11 +0000

You have a list of a million rows and you want to jump to row 842,013.

ScrollController.jumpTo takes a pixel offset, not an index. To convert one
to the other you need the total height of the 842,012 rows above your target —
and a lazy list has never built them, so it does not know how tall they are.
That is not an oversight. It is the entire point of a lazy list.

Flutter ships no answer. The two packages that did are both dead:

scrollable_positioned_list — archived by Google
scroll_to_index — last published in 2022

Between them they still serve over a million downloads a month, which tells you
how many apps are relying on an unmaintained solution to this.

How the archived approach worked

scrollable_positioned_list built a second complete list, anchored at the
target index, and cross-faded from the old one to the new one.

It works. It is also why jumping felt the way it did: for the duration of the
transition there are two full sets of children alive in the tree, both being
laid out, both painting. On a heavy row widget that is visible — a flash, a
frame drop, sometimes a scrollbar that jumps twice.

And it is why the package was hard to maintain. Two lists that must agree about
scroll position, item extents and which one is currently authoritative is a lot
of state to keep correct across Flutter versions.

Why the obvious workarounds do not hold

Before the real answer, it is worth walking the approaches people try first,
because each fails in a way that teaches something.

Fixed item extent. If every row is exactly 72 pixels, index 842,013 is at
offset 60,624,936 and you are done. SliverFixedExtentList exists precisely for
this and it is genuinely the fastest option. It also stops working the moment one
row wraps to two lines, and "all my rows are identical forever" is a promise most
products break within a month.

Estimate, jump, correct. Guess an average height, jump to the estimate, then
measure where you landed and adjust. This visibly hunts — the list arrives near
the target and then shuffles, sometimes several times. Worse, the correction
happens after paint, so the user sees the wrong content first.

ensureVisible on a GlobalKey. This works beautifully and only for items
that are already built. The element for index 842,013 does not exist, so there is
no context to scroll to. It is the right tool for "scroll to this form field",
and no tool at all for "jump into a list".

Build everything. A million ListTiles is a million elements, a million
render objects, and a frame budget measured in seconds. This is what
shrinkWrap: true quietly does to you in some nestings, which is why it has the
reputation it has.

Each of these is the sensible next idea after the previous one fails. The reason
none of them work is that they are all trying to compute an offset that the
list fundamentally does not know.

The primitive Flutter already has

Viewport can nominate a centre sliver via its center property. It is
there for chat-style lists that grow upwards, and it does something unusual:
content before the centre sliver lays out at negative scroll offset.

That is the whole solution, once you see it.

Split the list in two at the anchor index:

everything before the anchor goes in one sliver, laid out backwards from zero into negative offsets
the anchor and everything after it go in a second sliver, marked as the centre

Now scroll offset zero is the anchor. Not "approximately the anchor once we
have measured our way there" — it is the anchor, by definition, because that is
what nominating a centre sliver means.

Jumping to index 842,013 becomes: rebuild with the anchor set to 842,013, offset
zero. There is nothing to measure, nothing to estimate, and nothing above it to
build. It costs the same as jumping to index 3.

final controller = AnchoredListController();

AnchoredList.builder(
  controller: controller,
  itemCount: 1000000,
  itemBuilder: (context, index) => ListTile(title: Text('Item $index')),
);

controller.jumpToIndex(842013);   // same cost as jumping to item 3

One viewport, one set of children, no cross-fade.

Why negative offsets are not a hack

If nominating a centre sliver and laying content out at negative offsets sounds
like an exotic trick, it is worth knowing it is what Flutter uses for its own
reverse-scrolling lists. CustomScrollView exposes center as public API, and
the framework's chat-style examples rely on exactly this behaviour.

The insight this package contributes is not the primitive. It is noticing that
"the offset origin can be placed anywhere" is the same problem as "jump to an
arbitrary index" — and that once the origin is the target, there is no
arithmetic left to do.

That is why the jump is O(1) rather than merely fast. It is not that the search
got quicker; there is no search.

The second thing this fixes

There is a related problem the same structure solves for free.

You are reading a chat, or a feed, or a log. New items arrive above where you
are looking. In an ordinary ListView every insertion above your position pushes
your content down, because your scroll offset is measured from the top of a list
that just got taller.

With a centre sliver, items above the anchor live at negative offsets. Inserting
one extends the list upwards, into more-negative territory. Your position is
measured from the anchor, and the anchor has not moved — so your content does
not move either.

That is why the package is called anchored_list rather than something about
jumping. Holding your place while things arrive above you is the same mechanism
as jumping instantly, seen from a different angle.

Where this changes what you can build

Two features become straightforward that are usually quietly dropped.

Deep linking into a list. A notification says "someone replied to your
comment", and the comment is 4,000 items down. Ordinarily you either load a
separate detail screen or you build a paginated approximation and hope. With an
anchored list you open the list at that comment, and scrolling up from it works
normally because the items above are real list items, lazily built as the user
reaches them.

Restoring scroll position properly. Saving a pixel offset and restoring it
is unreliable, because content above may have changed length between sessions.
Saving an index and restoring the anchor is exact — the user comes back to the
item they were reading, not to a coordinate that used to contain it.

Both of these usually get cut during estimation because "scroll to an arbitrary
position in a long list" sounds like a week of work. It is a controller call.

What it costs

Honest limitations, because a list package that claims none is hiding some:

Two slivers, not one. If you were relying on a single-sliver structure for something exotic, this changes it.
Scrollbar geometry is estimated. A lazy list genuinely does not know its own total height, so the thumb size is a best guess that improves as more is measured. Every solution to this problem shares that limit, including the archived ones.
The anchor is a rebuild, not an animation. jumpToIndex is instant by design. If you want a visible scroll across a million rows, that is a different feature and a much slower one — and one nobody actually wants, since a five-second animated scroll past 800,000 rows is not a better experience than arriving.
Items above the anchor build as you scroll up, exactly as items below build as you scroll down. Jumping to index 842,013 and immediately flinging upward will build items in that direction — which is correct, but means the work is proportional to how far you scroll, not zero.

On replacing an archived package

If you are migrating from scrollable_positioned_list, the mental model changes
in one way worth flagging. That package thinks in terms of "scroll such that item
N is at alignment 0.0–1.0 within the viewport". This one thinks in terms of "item
N is the origin". For the common case — put item N at the top — they express
the same thing. For "put item N one third down the viewport", you are adjusting
an offset from the anchor rather than passing an alignment.

Try it

anchored_list is on pub.dev — MIT, no
dependencies, all six platforms, 160/160 pub points.

The repository has a demo that jumps around a million-row list while showing the
live child count. That counter is the part worth watching: it stays flat as you
jump from index 3 to 842,013 and back. A flat child count during a jump is the
evidence that nothing above the anchor is being built — and it is the number that
distinguishes this approach from every workaround above, all of which make it
spike.

Talking to Native: FFI, Pigeon, and Knowing Which One You Need

K M Shahriar Hossain — Sat, 05 Sep 2026 23:12:10 +0000

A MethodChannel typo cost us three days and a hotfix release, and the compiler never said a word. That's the whole story of Flutter native interop in one sentence: the easy path is a stringly-typed message bus that fails silently in the field, and almost everyone reaches for it first.

Every Flutter developer's first brush with native code goes the same way. You need something the framework doesn't give you — a battery level, a hardware sensor, a C library your backend team already trusts — and the first search result says MethodChannel. You copy the snippet, wire up a stringly-typed channel name, and it works. Ship it.

Then it grows. Six months later that one channel has fourteen methods, each one a switch on a string, each argument a Map<String, dynamic> you as-cast and pray over. At Shpper we had exactly this: a device channel that had quietly become the single largest source of crash-free-rate regressions in one of our apps. The regression that cost us the three days was a renamed method on the Kotlin side that nobody renamed on the Dart side — green build, green tests, MissingPluginException on real hardware two days after release. Not one of those crashes was catchable by the compiler, because we'd built the boundary out of strings. The lesson I keep relearning: MethodChannel is the default answer and it is usually the wrong one.

This post is the decision framework I wish I'd had earlier: the three ways Flutter talks to native code, what each one actually costs, and how to pick before you write a line of glue.

The three Flutter native interop paths, and what they actually cost

Flutter gives you three real ways to reach native code. They are not interchangeable, and picking the wrong one is where the pain comes from.

dart:ffi — call C (and Rust, and anything with a C ABI) directly, in-process, synchronously. No serialization, no message passing, no platform thread. This is the fastest path and the one people reach for last.
Pigeon — a code generator that turns a schema of Dart abstract classes into type-safe, generated method channels for you. Same transport as raw channels underneath, but the compiler now checks both sides.
Raw MethodChannel / EventChannel — the hand-written message bus between Dart and the platform (Kotlin/Java, Swift/Obj-C). Async, dynamically typed, and manual on both ends.

Here's the mental model I use. FFI is for code — you have a native function and you want to call it. Pigeon is for platform APIs — you need to talk to Android or iOS SDKs and want a typed contract. Raw channels are for the awkward middle: event streams, plugin ecosystems, and things Pigeon can't express yet.

	FFI	Pigeon	Raw MethodChannel
Talks to	C / Rust / C ABI	Kotlin / Swift SDKs	Kotlin / Swift SDKs
Call style	Synchronous	Async (Future)	Async (Future)
Type safety	Compile-time (C types)	Compile-time (generated)	None
Serialization	None (raw memory)	Standard codec	Standard codec
Runs on	Calling thread	Platform thread	Platform thread
Best for	Hot paths, existing C libs	New platform integrations	Streams, edge cases

If you take one thing away: the interesting decision is between FFI and Pigeon. Raw channels are the fallback, not the starting point. Everything below is really about earning the confidence to not hand-write a channel by default.

Where raw MethodChannel bites you in production

The problem with raw channels isn't that they don't work. They work fine on the happy path, which is exactly why they're dangerous — the cost is deferred to the moment you least want it. A MethodChannel is a BasicMessageChannel with a method-call codec bolted on, and that's all the safety you get: a string name and a bag of dynamically-typed arguments.

Look at a typical hand-rolled channel:

const _channel = MethodChannel('com.shpper/device');

Future<int> getBatteryLevel() async {
  final result = await _channel.invokeMethod('getBatteryLevel');
  return result as int; // hope it's really an int
}

And the Kotlin side:

channel.setMethodCallHandler { call, result ->
  when (call.method) {
    "getBatteryLevel" -> result.success(batteryLevel())
    // typo "getBateryLevel" here? compiles fine, fails at runtime
    else -> result.notImplemented()
  }
}

Three failure modes are baked in and none of them are caught by a compiler:

Stringly-typed dispatch. The method name is a string on both sides. Rename it on one side and you get a silent MissingPluginException in the field. Grep is your only "refactoring tool," and grep doesn't know the difference between a channel name and a comment.
Untyped arguments. Everything crosses the boundary as Object?. You cast on the Dart side and cast again in Kotlin. Change an argument's shape — an int that becomes a long, a field that becomes nullable — and nothing warns you until a specific device tries it. Worse, the standard codec silently promotes small integers, so a value that's fine in the emulator can ClassCastException on a payload that happens to exceed 32 bits.
Always async, even when it shouldn't be. Every call is a Future, even reading a constant. That async hop forces await into call sites that are conceptually synchronous, which spreads through your architecture and makes otherwise-pure functions infectious.

Raw channels are the assembly language of Flutter interop. Sometimes you need assembly. You just shouldn't write your whole app in it — and you definitely shouldn't reach for it first for a plain typed request/response API.

dart:ffi for synchronous C and Rust interop

When you actually have native code — an image codec, a crypto primitive, a Rust core you share across platforms — FFI is a different universe. There's no message bus. Dart calls the C function directly and gets the result back on the same thread, synchronously, with zero serialization.

On a project last year we needed to hash and verify a few thousand small records on-device during a sync. Doing it over a method channel meant a round trip per record, and the platform-thread hop killed us — the per-call overhead dominated the actual work. Moving the hot loop to a tiny C function behind FFI took the whole operation from "spinner the user notices" to "done before the frame ends." The win wasn't a faster hash; it was deleting the boundary entirely.

The mechanics: you declare the native signature and the Dart signature, then bind them.

import 'dart:ffi';
import 'package:ffi/ffi.dart';

// C: uint32_t crc32(const uint8_t* data, int len);
typedef _Crc32C = Uint32 Function(Pointer<Uint8>, Int32);
typedef _Crc32Dart = int Function(Pointer<Uint8>, int);

final _lib = DynamicLibrary.open('libhash.so');
final _crc32 = _lib.lookupFunction<_Crc32C, _Crc32Dart>('crc32');

int crc32(List<int> bytes) {
  final ptr = malloc<Uint8>(bytes.length);
  final view = ptr.asTypedList(bytes.length);
  view.setAll(0, bytes);
  try {
    return _crc32(ptr, bytes.length);
  } finally {
    malloc.free(ptr); // you own this memory now
  }
}

Note the two typedefs: one uses native FFI types (Uint32, Int32, Pointer) to describe the C ABI, the other uses plain Dart types (int) for the call site. lookupFunction marries them. Get a width wrong — Int32 where the header says int64_t — and you'll read garbage or corrupt the stack, so this is exactly the place to let ffigen transcribe headers instead of doing it by hand.

That try/finally is the whole game with FFI. The moment you cross into native memory, Dart's garbage collector stops helping you. Every malloc needs a free, and if you throw in between, you leak. My rules after getting this wrong more than once:

Allocate and free in the same function whenever you can. If a pointer has to outlive the call, wrap it in a class with a dispose() and treat it like a file handle — and consider a NativeFinalizer as a backstop so a forgotten dispose() degrades to a late free instead of a permanent leak.
Use package:ffi's malloc/calloc, not raw Pointer gymnastics — they give you .free() and helpers like .toNativeUtf8() for the ever-annoying string marshalling.
Copy at the boundary. asTypedList gives you a view into native memory; if that memory gets freed, the view is a dangling pointer and reading it is undefined behaviour. Copy into a Dart List before you free if the data escapes the function.
Blocking calls block the isolate. FFI is synchronous, so a slow native call freezes your UI. For anything long-running, use Isolate.run or an async FFI callback via NativeCallable.listener so native code can call back into Dart from another thread.

Two things make modern FFI far less painful. ffigen reads a C header and generates all the typedefs and bindings for you, so you're not hand-transcribing signatures and getting integer widths wrong. And flutter_rust_bridge does the same for Rust, generating the FFI glue and handling the memory dance so a Rust core feels like a normal async Dart API — including turning long-running Rust work into proper Dart Futures and Streams. If you have a real algorithmic core to share across platforms, that combination is the strongest option Flutter has.

Pigeon for type-safe platform channels

FFI is great when the thing you're calling is C. But most native work isn't C — it's "please open the iOS share sheet" or "read this value from the Android KeyStore." That means talking to platform SDKs in Swift and Kotlin, and for that, the right tool is Pigeon.

Pigeon isn't a runtime; there's nothing to add to your app's dependency footprint at ship time. It's a code generator you run at build time. You write a schema in Dart — just abstract classes and data classes — and Pigeon emits the channel plumbing for Dart, Kotlin/Java, and Swift/Obj-C. The wire is still a method channel underneath. The difference is the compiler now sees both ends of it.

// pigeons/device_api.dart — this file is the schema, not shipped code
import 'package:pigeon/pigeon.dart';

class DeviceInfo {
  late String model;
  late int batteryLevel;
  late bool isCharging;
}

@HostApi()
abstract class DeviceApi {
  DeviceInfo getDeviceInfo();
  @async
  bool authenticate(String reason);
}

Run dart run pigeon --input pigeons/device_api.dart and you get a generated Dart class you call like any typed API, plus a Kotlin interface and a Swift protocol you implement. Now the compiler is your integration test:

class DevicePlugin : DeviceApi {
  override fun getDeviceInfo(): DeviceInfo {
    return DeviceInfo(
      model = Build.MODEL,
      batteryLevel = currentBattery(),
      isCharging = charging()
    )
  }
  // forget authenticate()? Kotlin won't compile. That's the point.
}

What you get for free:

Rename-safe by construction. Change a method or a field and both platforms fail to compile until you fix them. No more field-day MissingPluginException from a one-character typo.
Real data classes instead of Map<String, dynamic>. The DTO is defined once and generated everywhere, so there's a single source of truth for the shape crossing the boundary.
HostApi and FlutterApi. @HostApi() lets Dart call into native; @FlutterApi() lets native call back into Dart. Both are typed, so bidirectional flows (a native SDK pushing a callback into your Dart layer) stop being a stringly-typed guessing game.

A practical workflow note: check the generated files into version control and regenerate them in CI, then fail the build if the output changed. That turns "someone edited the schema but forgot to regenerate" into a red build instead of a runtime surprise — the same discipline I apply to any generated code.

My default now for any new platform integration is Pigeon first, and I only drop to a raw channel when I hit something Pigeon genuinely can't model. The generated code is boring, which on a boundary this error-prone is the highest praise I can give.

Threading: where the native boundary really lives

The part that trips people up isn't syntax — it's which thread the code runs on. Get this wrong and you'll ship an app that janks or, worse, deadlocks intermittently on some devices and never in the office.

Method/Pigeon channel handlers run on the platform's main thread (the Android main thread, the iOS main queue) by default. Do heavy work there and you block the native UI thread. On Android that's an ANR waiting to happen; on iOS it's a watchdog kill.
Dart async is not a thread. await yields on the single UI isolate. It keeps the UI responsive for I/O-bound work, but a tight CPU loop in Dart still blocks the frame — concurrency and parallelism are not the same thing here.
FFI calls run on the calling thread. Call it from the UI isolate and a slow function freezes your app; there's no free hop to a background thread like channels give you.

So the real rules:

In a native channel handler, if the work is slow, dispatch to a background thread (a Kotlin coroutine on Dispatchers.IO, a DispatchQueue.global()) and post the result back to the channel. Don't do the work inline on the platform thread.
For heavy Dart-side or FFI work, move it off the UI isolate. Isolate.run(() => crc32(bytes)) runs the synchronous FFI call on a separate isolate so the main one keeps rendering. Remember that data crossing isolate boundaries is copied unless it's transferable (like TransferableTypedData), so measure before you assume the isolate hop is free.
For continuous native events (location, sensors, download progress), use an EventChannel — a typed stream — rather than polling with repeated method calls. Polling turns a push problem into an N-round-trips-per-second problem.

The mistake I see most: someone benchmarks a single channel call, sees it's "fast," and assumes it's free. Then they call it 60 times a frame in a scroll listener. The per-call cost is small; the platform-thread contention and codec churn at that frequency are not.

Passing big payloads without killing the codec

Every method channel serializes its arguments through the standard message codec. For small structured data that's fine. For big payloads it is a trap, and it's a trap you fall into precisely when performance matters most.

Two things go wrong at scale. First, a large Map or List is walked and encoded field by field — slow and allocation-heavy, with garbage-collection pressure on both sides. Second, that encode/decode happens on threads you care about, so a fat payload stalls the UI while it's being marshalled.

The fix is to stop sending structure and start sending bytes. The standard codec has a fast path for Uint8List — it's passed as a raw byte buffer, not walked element by element.

// Slow: a 100k-element list gets encoded item by item
final points = await channel.invokeMethod('getPoints'); // List<dynamic>, ouch

// Fast: hand back a packed byte buffer, decode it in Dart
final buffer = await channel.invokeMethod('getPointsBytes'); // Uint8List
final floats = buffer.buffer.asFloat32List();

On the native side, pack your data into a ByteArray/Data and return that. You decode it in Dart with a typed-data view — no per-element codec cost, just a pointer reinterpretation. For a mesh of a few hundred thousand floats, this was the difference between a visible hitch and nothing at all. Mind endianness and struct alignment when you do this: agree on a layout (little-endian, tightly packed) and, if in doubt, use a ByteData with explicit getFloat32(offset, Endian.little) reads rather than a raw view.

And if you're already passing large buffers back and forth constantly, that's a signal you might want FFI instead. FFI shares memory by pointer — zero copy, zero serialization. The codec's byte fast-path is the right answer inside the channel world; FFI is the right answer when the channel world itself is the bottleneck.

Packaging native code so consumers don't need a toolchain

This is the part that turns a working prototype into a shippable plugin, and it's where a lot of FFI projects quietly die. Your C or Rust code has to be built for every target — Android arm64/armeabi-v7a/x86_64, iOS device and simulator, and ideally macOS/Windows/Linux for desktop. If installing your package means "now go set up the NDK and a Rust cross-compiler," nobody will use it, including your future self on a fresh machine.

Flutter's plugin system does have hooks for this. The clean options:

Prebuilt binaries. Build your .so/.a/.xcframework in CI and ship them inside the plugin (or, to keep the package small, download-on-first-build). This is the approach I lean toward — I already build binaries in CI and attach them to GitHub Releases for other parts of the stack, so the pattern is familiar and it keeps consumers toolchain-free. The trade-off is that you're responsible for reproducible, correctly-signed builds.
Native build hooks. Point the Android Gradle/CMake and iOS CocoaPods/podspec at your source so it compiles as part of the app build. Simplest to set up, but now every consumer needs the full native toolchain and eats the compile time on every clean build.
flutter_rust_bridge + cargokit automates the Rust build across all targets and is the least painful route if you're in Rust — it wires the cross-compilation into the standard Flutter build so flutter build just produces the right artifacts.

Whichever you pick, the goal is the same: flutter pub add your_package should just work, with no README section titled "First, install these seven tools." The moment native code needs a manual setup step, adoption falls off a cliff.

A Flutter native interop decision tree you can apply on Monday

Strip away the nuance and the choice is short:

Are you calling native code you already have as C or Rust? Use FFI. Wrap ffigen or flutter_rust_bridge around it, mind the memory (every malloc its free), and push slow calls off the UI isolate. Synchronous, zero-copy, no codec.
Are you integrating with a platform SDK (iOS/Android APIs)? Use Pigeon. Write the schema, generate typed bindings, implement the HostApi on each side, and let the compiler catch your mistakes.
Do you need a continuous stream of native events, or something Pigeon can't model yet? Use a raw EventChannel/MethodChannel — deliberately, knowing you own the type safety by hand and wrapping it thinly so the untyped surface doesn't leak through your app.
Are you moving big payloads? Send Uint8List, not maps. And if you're doing it constantly, reconsider whether the problem is actually an FFI problem.

Notice what's not on this list as a default: hand-writing a MethodChannel for a new typed API. That's the option to talk yourself out of, not into.

Key takeaways

MethodChannel is the well-known answer and usually the wrong one — it's stringly-typed, untyped, always async, and every failure it hides shows up in production instead of at compile time.
Reach for FFI when you're calling actual C or Rust code: synchronous, no serialization, zero-copy — but you own the memory. Every malloc needs its free, views into native memory can dangle, and slow calls belong off the UI isolate.
Reach for Pigeon for platform SDK integrations: you get generated, type-safe channels where the compiler checks both the Dart and native sides, and renames become compile errors instead of field crashes.
Keep raw channels for event streams and the genuine edge cases Pigeon can't express — chosen on purpose, not by default, and wrapped thinly.
Mind the thread: channel handlers run on the platform main thread, FFI runs on the calling isolate, and heavy work belongs on a background thread or a spawned isolate.
Pass large data as Uint8List to hit the codec's fast path, and package your native binaries in CI so consumers never need a toolchain.

The right tool depends entirely on whether you're crossing to code or to a platform API — answer that first, and the rest of the decision makes itself.

Getting Work Off the Main Thread: Isolates Without the Hand-Waving

K M Shahriar Hossain — Sat, 05 Sep 2026 23:02:08 +0000

A designer once handed me an 18 MB JSON export we had to parse, normalize, and diff against our local copy before we could render a preview. On a mid-range Android phone that parse froze the UI for about 900ms. That's not a spinner pause. That's a "did the app just die?" pause, the kind where the user taps three more times and now you have a rage-tap in your logs.

The fix everyone reaches for is "throw it on an isolate," and that's usually correct. The problem is that almost every Dart isolate tutorial stops exactly where it gets interesting, right before message-passing costs bite you and you end up slower than when you started. This is the post I wish I'd had: not "isolates are like threads" hand-waving, but a working model of what an isolate is, what crossing between them actually costs, and how to decide whether spawning one helps or hurts. I've shipped this in production at Shpper and gotten it wrong enough times to have opinions worth the read.

The single-thread myth: what actually blocks a Flutter frame

Dart runs your code on a single thread of execution per isolate. That's the part people repeat. The part they skip: "single-threaded" doesn't mean "does one thing." The event loop juggles thousands of async operations happily, because await yields control back to the loop while I/O happens elsewhere (the OS, the network stack, the disk). Async is about waiting efficiently.

What async/await does nothing for is work. A tight loop parsing 18 MB of JSON doesn't await anything. It just runs, synchronously, holding the thread. And the UI thread has a hard deadline: at 60fps you have roughly 16ms to produce a frame, at 120fps roughly 8ms. Anything synchronous that runs longer than that budget between two frames drops a frame. Run 900ms of parsing and you've dropped dozens of frames in a row. That's the jank.

The mental split I use:

I/O-bound work (network calls, file reads, database queries): stay on the main isolate, use async/await. An isolate buys you nothing here and adds overhead.
CPU-bound work (JSON parsing, encryption, image manipulation, compression, big list transforms): this is what blocks frames. This is what isolates are for.

If you can't point at a hot synchronous loop, you don't have an isolate problem. You have a "put an await in the right place" problem, and reaching for an isolate will just add complexity and latency. A surprising number of "we need concurrency" tickets are actually a blocking jsonDecode or a synchronous file read that should have been the async variant in the first place.

A quick way to tell them apart

Ask one question: does this code ever wait on something outside the CPU? If it waits on a socket, a disk, or a platform channel, it's I/O-bound and await handles it. If it just churns through data in memory, it's CPU-bound and no amount of async will unblock the frame, because there's nothing to yield on. Future(() => heavyWork()) does not help here either: it defers the work to a later microtask, but that work still runs on the same thread and still blocks the same UI. Deferring is not offloading.

Isolate.run vs compute vs a long-lived spawned isolate

There are three tools here and they're not interchangeable. Choosing the wrong one is the difference between a clean win and a regression.

compute is Flutter's original one-shot helper. You hand it a top-level (or static) function and one argument, it spins up an isolate, runs the function, sends the result back, and tears the isolate down.

final parsed = await compute(parseDesignExport, rawJsonString);

Isolate.run (Dart 2.19 and later) is the modern, framework-agnostic version of the same idea. It's what I default to now. It takes a closure instead of a named function, which is a real ergonomic win because you can capture local variables directly instead of packing them into a single argument object.

final parsed = await Isolate.run(() => parseDesignExport(rawJsonString));

Both of these do the same thing conceptually: spawn, run once, return, die. The isolate startup cost is real but modest, on the order of a couple hundred microseconds to low milliseconds depending on platform. For a 900ms parse, that overhead is noise. For a 2ms task, that overhead is the whole point and you shouldn't be spawning at all.

A long-lived spawned isolate (Isolate.spawn plus your own SendPort/ReceivePort plumbing) is what you want when the same worker handles many messages over time. Spawning once and reusing it amortizes the startup cost and, more importantly, lets the worker keep warm state: a loaded ML model, an open database handle, a parser with a primed cache.

The decision rule I use:

One task, run once, then done: Isolate.run.
Same kind of task, many times, and startup or warm state matters: a long-lived spawned isolate.
Legacy Flutter code, or you just want the well-known name: compute (it's fine, it's essentially Isolate.run with a Flutter hat on).

One gotcha that trips people up on all three: the function or closure you hand to an isolate must be able to run in a fresh context. That means no capturing of things tied to the spawning isolate that can't cross the boundary, and any closure captures get copied by the same rules as messages (more on that next). If you see a hard to serialize or Illegal argument in isolate message error, you almost always captured something you shouldn't have, like a BuildContext, a stream controller, or a plugin instance.

The copy tax: what SendPort actually serializes

Here's the cost nobody puts on the label. Isolates don't share memory. When you send an object through a SendPort, Dart doesn't hand the other isolate a reference. It copies the entire object graph, deep, into the receiving isolate's heap. Send a 40 MB parsed tree back and you pay for allocating and copying 40 MB, plus the garbage you just created on both sides.

I learned this the annoying way. I moved my 18 MB parse onto an isolate, the parse itself flew, and then I still had jank. The parse produced a large nested Map/List structure, and copying that back to the main isolate was itself a multi-hundred-millisecond synchronous operation on the receiving side. I'd moved the compute off the main thread but left the copy on it. The profiler showed a fat synchronous block right after the "await" returned, which is the deserialization landing on the UI thread.

Two things fixed it:

Return less. The main isolate rarely needs the full parsed graph. I changed the worker to do the parse and the diff and the normalization, and return only the small delta the UI actually renders. Compute-heavy work belongs where the data already is, so push logic into the worker rather than shuttling raw data out of it.
For byte buffers, use TransferableTypedData. This is the escape hatch. It hands ownership of a byte buffer to the other isolate with effectively zero copy, at the cost of the sending isolate no longer being able to touch it.

import 'dart:isolate';
import 'dart:typed_data';

// On the sending side:
final bytes = Uint8List(20 * 1024 * 1024); // 20 MB
final transferable = TransferableTypedData.fromList([bytes]);
sendPort.send(transferable); // ownership moves; near-zero copy

// On the receiving side:
void handle(TransferableTypedData t) {
  final ByteBuffer buffer = t.materialize();
  final data = buffer.asUint8List();
  // ...use data
}

TransferableTypedData only works for typed data (byte buffers), not arbitrary Dart objects. But a huge amount of heavy work — images, audio, compressed payloads, protobufs — is byte buffers at the boundary anyway. Design your isolate interface so what crosses the wire is bytes or a small summary, never a giant object graph. The rule I keep coming back to: cross the isolate boundary with as little as possible. The message-passing model is the whole cost structure of Dart concurrency, and every megabyte you send is a megabyte you allocate, copy, and later collect.

A worker-pool pattern for streaming and back-pressure

Once you go long-lived, you need real plumbing. A single spawned isolate that you talk to over SendPort/ReceivePort looks like this:

class Worker {
  final SendPort _commands;
  final ReceivePort _responses;
  final _pending = <int, Completer<Object?>>{};
  int _nextId = 0;

  Worker._(this._commands, this._responses) {
    _responses.listen(_onResponse);
  }

  static Future<Worker> spawn() async {
    final init = ReceivePort();
    await Isolate.spawn(_entry, init.sendPort);
    final commands = await init.first as SendPort;
    final responses = ReceivePort();
    commands.send(responses.sendPort);
    return Worker._(commands, responses);
  }

  Future<Object?> run(Object? job) {
    final id = _nextId++;
    final c = Completer<Object?>();
    _pending[id] = c;
    _commands.send((id, job));
    return c.future;
  }

  void _onResponse(dynamic msg) {
    final (int id, Object? result) = msg as (int, Object?);
    _pending.remove(id)!.complete(result);
  }

  static void _entry(SendPort initPort) {
    final commandPort = ReceivePort();
    initPort.send(commandPort.sendPort);
    late SendPort responses;
    commandPort.listen((msg) {
      if (msg is SendPort) {
        responses = msg;
        return;
      }
      final (int id, Object? job) = msg as (int, Object?);
      final result = doWork(job); // your CPU-bound function
      responses.send((id, result));
    });
  }
}

The id correlation is the important detail. Because responses come back over a single port, you tag each job so you can match results to the right Completer. Without it you can't have more than one in-flight request, since you'd have no way to know which response belongs to which caller.

Now the two things people forget:

Back-pressure. A single worker processes jobs serially in its own event loop. If your producer fires jobs faster than the worker drains them, the pending queue grows without bound and you eat memory until you OOM. Cap it. I keep a semaphore on the producer side: don't dispatch job N+K until job N has come back. For genuinely parallel throughput, spawn a pool of N workers (N roughly the number of physical cores) and round-robin or least-loaded dispatch across them. More than that and you're just context-switching for no gain, since the OS still only has so many cores. A pool of 3 to 4 workers is my usual starting point on mobile; measure before going wider.

Streaming. If a job produces incremental output (say, decoding frames or lines of a CSV), have the worker send multiple (id, chunk) messages and a final (id, done) sentinel, and expose it on the main side as a Stream instead of a Future. But remember every chunk is a copy, so chunk coarsely. Sending 10,000 tiny messages will cost you more in message overhead than the work you saved offloading. Batch chunks into reasonably sized payloads and the streaming stays cheap.

Sharing memory the legal way: TransferableTypedData and FFI

"Isolates don't share memory" is true for Dart objects. It is not the whole truth. There are legitimate ways to share a region of memory, and for the heaviest workloads they're the only thing that performs.

TransferableTypedData (above) is move, not share: one isolate has the buffer at a time. Great for pipelines, useless when two isolates need the same data simultaneously.
FFI-allocated native memory is genuinely shared. If you malloc a buffer through dart:ffi, that pointer is just an address. Pass the address (an int) across the port and both isolates can read and write the same bytes. No copy, true sharing.

import 'dart:ffi';
import 'package:ffi/ffi.dart';

// Allocate a shared buffer in native memory:
final Pointer<Uint8> buf = malloc.allocate<Uint8>(1024 * 1024);

// Send just the address across:
sendPort.send(buf.address);

// In the other isolate, reconstruct the pointer:
final Pointer<Uint8> shared = Pointer.fromAddress(addressInt);
final view = shared.asTypedList(1024 * 1024); // reads/writes the same bytes

The catch is that you've now opted out of Dart's memory safety. No GC over that region, manual malloc/free, and if two isolates write the same bytes concurrently you have a genuine data race with no lock to save you. This is C-level power with C-level footguns. I reach for it only when profiling proves the copy is the bottleneck and the buffer is large and long-lived: image pipelines, audio processing, an mmap'd file. For everything else, copy semantics are a feature, not a limitation. They make isolates deadlock-free and race-free by construction, which is most of why they're pleasant to use compared to threads-and-locks concurrency.

Isolates on Flutter web: where the story changes

If you ship Flutter web, unlearn some of the above. On the web, Dart isolates map onto Web Workers, and Web Workers are genuinely separate contexts with hard limits:

Isolate.spawn and Isolate.run are not supported on web the way they are on native. Historically compute on web just ran your function on the main thread and returned a future, giving you exactly zero parallelism. Tooling continues to evolve, but you cannot assume the native behavior holds. Test it, don't trust it.
Web Workers can't touch the DOM, and passing data uses postMessage with structured clone, which is its own copy tax with its own rules about what is and isn't cloneable.
The reliable web escape hatch for real off-main-thread work is often not a Dart isolate at all. It's a hand-written JS Web Worker (or a WASM module) that you talk to over JS interop.

The practical consequence: don't design a single concurrency layer and assume it behaves identically across native and web. I gate the heavy path behind a capability check and fall back to chunked, yielding work on web — process a batch, await Future.delayed(Duration.zero) to let a frame render, then process the next batch:

Future<void> processInChunks(List<Item> items) async {
  const chunk = 200;
  for (var i = 0; i < items.length; i += chunk) {
    for (var j = i; j < i + chunk && j < items.length; j++) {
      process(items[j]);
    }
    await Future.delayed(Duration.zero); // yield so a frame can render
  }
}

It's cooperative multitasking instead of real parallelism, but it keeps the UI breathing, which is the actual goal.

Cancellation, timeouts, and cleaning up a dead worker

Isolates have no built-in cancel(). You can't reach into a running isolate and stop a synchronous loop mid-flight, because it never yields to check for a cancel signal. Three tactics I use, in order of bluntness:

Cooperative cancellation. If the work is a loop over chunks, have the worker check a cancelled flag (set via a message) between chunks. Only works if the work is chunkable and the worker actually returns to its event loop periodically to receive that message.
Kill the isolate. For genuinely uninterruptible work, Isolate.kill(priority: Isolate.immediate) is the hammer. It terminates the isolate, full stop. Any FFI-allocated memory it owned leaks unless you freed it first, and any in-flight Completer on the main side hangs forever unless you complete it with an error yourself. So kill and clean up:

void cancel(Worker w) {
  w._isolate.kill(priority: Isolate.immediate);
  w._responses.close();
  for (final c in w._pending.values) {
    c.completeError(StateError('worker cancelled'));
  }
  w._pending.clear();
}

Timeouts belong on the main side, not inside the worker. Wrap the future: future.timeout(const Duration(seconds: 5)). When it fires, treat the worker as dead, kill it, and respawn a fresh one. Don't try to reuse a worker you just timed out on; you don't know what state it's in.

The recurring lesson: an isolate is a resource, like a socket or a file handle. If you spawn it, you own closing it. I once shipped a bug where a screen spawned a worker per navigation and never killed the old ones, and after twenty navigations the app was carrying twenty warm isolates and their heaps. It didn't crash. It just got mysteriously slower and hungrier over time, which is worse, because nobody files a bug for "slightly worse the longer you use it."

Measuring the break-even point before you reach for an isolate

Isolates are not free, so treat "should this be on an isolate?" as a measurement, not a vibe. My checklist:

Time the synchronous work on the main isolate first. Put a Stopwatch around the exact call. If it's under a frame budget (roughly 8 to 16ms) and doesn't run in a tight loop, leave it on the main thread. You will not notice it and you'll skip all the plumbing.
Estimate the copy cost of the input and the output. Roughly: how many megabytes cross the boundary, in and out? Copying runs on the order of low-GB/s, so a 40 MB round trip is tens of milliseconds of pure copy that lands synchronously on whichever isolate is receiving. If the copy cost approaches the compute cost, an isolate might not help.
Compute the break-even. An isolate is worth it when compute_time > startup + copy_in + copy_out + result_handling. For my 900ms parse returning a tiny diff, easy win. For a 5ms transform on a 30 MB list returning a 30 MB list, an isolate can be a net loss.
Profile in profile mode on a real device, never debug mode and never the simulator. Debug-mode Dart is unoptimized and will lie to you about both the compute and the copy. I've seen a "clearly needs an isolate" call in debug turn out to be a few milliseconds in profile, not worth offloading at all.

A concrete before/after from a real screen: an image-tiling feature was dropping frames on scroll. The naive fix, one Isolate.run per tile, was actually slower: startup plus a full-bitmap copy each way dwarfed the tiling work itself. The fix that stuck was a persistent worker pool of 3 isolates, tiles handed over as TransferableTypedData, results streamed back as bytes. Frame time on the main thread dropped dramatically, and the workers stayed warm across scrolls so we paid startup exactly once instead of per tile.

Key takeaways

Async is for waiting; isolates are for working. If there's no hot synchronous CPU loop, an isolate is the wrong tool — you probably want an await in the right place instead.
The boundary is the cost. SendPort deep-copies object graphs into the receiving isolate's heap. Cross it with as little as possible: return a small summary, not a giant tree, and push logic into the worker.
Pick the right shape. Isolate.run for one-shot work, compute for legacy Flutter code, a long-lived spawned isolate (or a pool sized to your physical cores) when startup, warm state, or throughput matters.
For big byte buffers, skip the copy. TransferableTypedData to move ownership, FFI/native memory to genuinely share — with the memory-safety caveats that implies.
You own the lifecycle. No free cancel, no free cleanup. Add timeouts on the main side, kill and respawn on failure, and never leak a warm worker across navigation.
Web is different. Isolates become Web Workers with their own limits; test the heavy path there and keep a chunked-yielding fallback for when parallelism isn't available.
Measure the break-even. Time the compute, estimate the copy both ways, and profile on a real device in profile mode. Sometimes the honest answer is "keep it on the main thread."

A Free, Practical CI/CD Pipeline for Flutter Web on Firebase Hosting

K M Shahriar Hossain — Sat, 05 Sep 2026 22:52:06 +0000

For about a year, my "deploy process" for my portfolio site was a three-step ritual: flutter build web, cross my fingers, firebase deploy. It mostly worked, which is the dangerous part. Then one evening I shipped a build from a hotel in Abu Dhabi over Wi-Fi that dropped mid-upload, went to dinner, and left a half-deployed, blank-white-screen site live for about four hours. Nobody died. But a recruiter I'd been talking to opened the link during those four hours, and I got to explain why my personal site — the one thing on the internet I fully control — was broken.

That was the push. I moved the whole thing into GitHub Actions the next weekend. The setup below is what I've run since: build once, cache hard, get a live preview URL on every pull request, and ship to production automatically on merge. The headline is that it costs $0/month — GitHub's free Actions minutes and Firebase's free Hosting quota both cover it with room to spare — but the real win isn't the money. It's that I stopped being the single point of failure in my own deploy.

This is a complete, copy-pasteable CI/CD pipeline for Flutter web on Firebase Hosting: a GitHub Actions workflow, service-account authentication, per-PR preview channels, and dependency caching that keeps runs fast and free. Steal it, adapt it, ship.

Why automate deployment for a one-person site

I'll get the pushback out of the way, because I made this argument to myself for months: "It's a portfolio. It's one command. Why build a pipeline?"

Because the command isn't the problem. The human running the command under bad conditions is the problem. Manual deploys fail in a very specific pattern — they fail exactly when you're distracted, tired, on bad Wi-Fi, or rushing to fix something before a meeting. That's precisely when you'll skip flutter analyze, deploy the wrong branch, forget to rebuild after your last edit, or upload a half-finished bundle. CI doesn't get tired. It runs the same steps in the same order every single time, on a clean machine, or it refuses to deploy at all.

The second reason is subtler and, honestly, it changed how I work: a preview URL per pull request turns "trust me, it works" into "click this and see." Once every change has a real, shareable, production-identical link before it merges, you review differently. You catch the layout that breaks at 375px. You notice the font that didn't load because of a CSP header. You send the link to a friend and they spot the typo you'd read past ten times. That feedback loop is worth more than the automation itself.

There's a third reason I underestimated: continuous deployment shrinks your batch size. When shipping is a scary manual ceremony, you batch changes up and deploy rarely, which makes every deploy riskier because more moved at once. When deployment is a merge, you ship tiny changes constantly, and a broken deploy is trivially bisectable to one small PR. Small, frequent, reversible — that's the whole DevOps thesis, and it applies to a portfolio just as much as to a product.

The shape of the pipeline: two triggers, two behaviors

That's the entire mental model:

Pull request → build the app, deploy it to a temporary preview channel, and post the preview URL back into the PR. Production is never touched.
Push to main → build the app and deploy to the live channel.

That split is the whole point. Firebase Hosting preview channels are a genuinely underrated feature: they're full, isolated deployments on a URL like your-site--pr-42-abc123.web.app, serving the exact bundle that would go live, with zero effect on your real domain. You get a staging environment per pull request without running or paying for staging infrastructure. No separate project, no separate config, no cost.

The mechanics matter here. A preview channel is a snapshot of your entire Hosting output served from an auto-generated subdomain. It respects the same firebase.json rewrites, headers, and clean-URL settings as production, which is why it catches config bugs a localhost build never will. If your SPA routing depends on a ** rewrite to /index.html, the preview channel exercises that exact rewrite. That's the difference between "works on my machine" and "works the way it'll actually be served."

Getting the Firebase credentials right, once

The old advice — still all over the internet — is to bake a FIREBASE_TOKEN into your secrets via firebase login:ci. Don't. That token is long-lived, tied to your entire Google account, and grants access to everything you can touch across all your projects. If it leaks from a CI log, you're not rotating one project's key, you're rotating your whole identity. It's the deploy-automation equivalent of using your root password as an API key.

Use a service account scoped to the single project instead. This is the principle of least privilege applied to CI: a machine identity that can deploy Hosting to one project and do nothing else. The Firebase CLI wires the whole thing up for you:

firebase init hosting:github

It walks you through connecting the repo, provisions a service account with the minimum Hosting permissions, drops a starter workflow into .github/workflows/, and stores the JSON key as a repo secret (named something like FIREBASE_SERVICE_ACCOUNT_YOUR_PROJECT_ID). The private key never lands in your repo — it lives only in encrypted GitHub Actions secrets, which are write-only from the UI and masked in logs.

If you'd rather do it by hand, go to the Google Cloud console, create a service account, give it the Firebase Hosting Admin role (that's the least privilege that can actually deploy), download the JSON key, and paste the full JSON into a GitHub Actions secret. Three rules I hold myself to regardless of method:

One service account per project. Blast radius stays small if a key ever leaks. A single shared account across projects is a single key that compromises all of them.
Never echo the secret in a workflow step. GitHub masks known secrets in logs, but it can't mask what you've reformatted, trimmed, or base64-decoded into a new string. I've watched people debug a "malformed JSON" error by printing the key to the log — which permanently burns that key into a public build log. Don't.
Rotate on a leak, not on a schedule you'll ignore. If a key is ever exposed, delete that service-account key in Cloud console and generate a new one. Because it's scoped to one project with one role, rotation is a two-minute job, not an identity crisis.

The GitHub Actions workflow

Here's the core of my .github/workflows/deploy.yml. One job does the build; the deploy step branches on the trigger.

name: Deploy Web

on:
  push:
    branches: [main]
  pull_request:

# Cancel an in-flight run if you push again to the same PR/branch.
# No point building commit N when N+1 already exists.
concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: true

jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: subosito/flutter-action@v2
        with:
          channel: stable
          cache: true   # caches the Flutter SDK across runs

      # Cache pub packages so we don't re-download the world every run.
      - uses: actions/cache@v4
        with:
          path: ~/.pub-cache
          key: pub-${{ runner.os }}-${{ hashFiles('pubspec.lock') }}
          restore-keys: pub-${{ runner.os }}-

      - run: flutter pub get
      - run: flutter analyze
      - run: flutter test
      - run: flutter build web --release

      # PRs get an ephemeral preview channel.
      - name: Deploy preview
        if: github.event_name == 'pull_request'
        uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: ${{ secrets.GITHUB_TOKEN }}
          firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }}
          projectId: your-project-id
          expires: 7d

      # main goes straight to production.
      - name: Deploy live
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: ${{ secrets.GITHUB_TOKEN }}
          firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }}
          projectId: your-project-id
          channelId: live

A few things I'm deliberate about here, learned the boring way:

flutter analyze and flutter test run before the build, and a failure stops everything. A deploy pipeline that skips static analysis is just an automated way to ship bugs faster. This is your quality gate — treat it like one. Steps run sequentially and a non-zero exit halts the job, so a failed analyze means the deploy step is never reached. That ordering is the safety property, not an accident.
channelId: live is the magic word for production. Omit it on PRs and the action auto-generates a throwaway channel named after the PR, then comments the URL on the pull request for you. That comment is the whole feature; you don't build it, you just get it. It uses the built-in GITHUB_TOKEN to post, which is why repoToken is wired in.
expires: 7d garbage-collects preview channels. Firebase caps active channels per site, and stale previews pile up until a deploy silently fails with a quota error weeks later. Let them self-destruct. Seven days is long enough that an open PR keeps a live link and short enough that abandoned branches clean themselves up.
concurrency cancels superseded runs. Push three commits to a PR in quick succession and you don't want three builds racing to comment three different URLs. Build the latest, kill the rest. This also stops two main pushes from deploying out of order.

The `GITHUB_TOKEN` vs. the service account

People conflate these two secrets, so to be explicit: secrets.GITHUB_TOKEN is auto-injected by Actions and only grants permissions within this repo (commenting on the PR). secrets.FIREBASE_SERVICE_ACCOUNT is the one you created and it grants deploy access to Firebase. Different scopes, different owners, both needed. The Firebase one should never appear in any run: step — it's consumed only by the deploy action.

Pinning your Flutter version for reproducible builds

An early version of this pipeline passed CI and then served a broken site, because flutter test was green but I'd never actually built web with the pinned SDK. Pin your Flutter version explicitly once your app grows past a toy. channel: stable is fine for a portfolio, but for anything a team touches, set a concrete version so a stable-channel bump doesn't quietly change your build under you:

- uses: subosito/flutter-action@v2
  with:
    flutter-version: '3.24.3'
    cache: true

Reproducible builds mean the version that's green in CI is the exact version that ships. "It builds on my machine" and "it builds in CI" should never be allowed to diverge — and the way you guarantee that is by removing "whatever stable happens to be today" from the equation. Bump the pinned version deliberately, in its own PR, so you can see the diff a new SDK causes in isolation rather than discovering it tangled into an unrelated change.

Caching Flutter web CI: where the time actually goes

On a cold Flutter web CI run, most of the wall-clock time isn't compiling your code — it's downloading the SDK and resolving pub packages. My uncached runs sat around six to seven minutes; cached, they're closer to two and a half. Two caches do almost all of that work:

The Flutter SDK. subosito/flutter-action@v2 with cache: true stores the SDK keyed on channel and version, so later runs skip the multi-hundred-megabyte download entirely.
The pub cache (~/.pub-cache), keyed on a hash of pubspec.lock. As long as dependencies don't change, restores are near-instant. The restore-keys fallback matters more than it looks: on a partial miss (same OS, changed lock), it reuses most packages instead of starting from zero, so adding one dependency doesn't cost you a full re-resolve.

Why key on `pubspec.lock`, not `pubspec.yaml`

Exactness. pubspec.yaml has version ranges; the lockfile has the resolved versions. You want the cache to invalidate precisely when the actual installed set changes, not when you tweak a caret constraint that resolves to the same thing. Key on the manifest and you'd needlessly rebuild the cache on cosmetic edits; key on the lockfile and the cache tracks reality. (This also means you should commit pubspec.lock for an app — which you should be doing anyway for reproducibility.)

Cache the inputs, rebuild the output

I deliberately do not cache the build/ directory, and this is a hill I'll defend. Flutter web builds aren't reliably incremental across fresh CI runners, and a stale build cache is a far nastier bug than a clean rebuild — it's the kind that ships old JavaScript alongside new HTML and takes you an hour of "but I fixed that" to diagnose. Cache the inputs, rebuild the output. Determinism beats a saved minute every time. The caches above are safe precisely because they're inputs keyed on their own fingerprints; a cached build artifact has no such honest key.

Keeping the pipeline genuinely free

This is the part people get nervous about, so let me be concrete about exactly where the free lines sit and why a site like this never crosses them.

GitHub Actions. Public repos get effectively unlimited minutes. Private repos get a monthly allowance (2,000 minutes at the time I'm writing this). A cached Flutter web build is roughly three minutes, so even on a private repo you'd need to push north of 600 times a month to run dry. If you somehow do, flip the repo public or self-host a runner on a spare machine.
Firebase Hosting. The free Spark quota covers a storage allowance and a monthly data-transfer allowance that a portfolio, docs site, or small app sits comfortably under. Preview channels count against the same quota, which is exactly why expires matters — abandoned previews quietly eat your storage budget.
The service account. Costs nothing. Deployments are just authenticated API calls; there's no per-deploy charge.

One myth worth killing: the Blaze plan is not "the paid plan." I run Blaze so I have headroom to add a Cloud Function or bump limits later, and my hosting bill is still exactly $0. Blaze means "you can pay if you exceed the free tier," not "you pay." Static hosting almost never exceeds it. The free tier isn't a trial that expires — it's a permanent floor, and Blaze just removes the ceiling above it.

If you want a hard guarantee, set a billing budget alert at $1 in Google Cloud. You'll get an email long before anything real happens, and you can sleep. I've had that alert armed for years and it has never fired. For total peace of mind you can pair it with a low daily quota cap on any service you're nervous about — but for pure static Hosting, the budget alert alone is plenty.

Edge cases and gotchas worth knowing

A few things that bit me or that I've watched bite others:

PRs from forks can't see your secrets. GitHub deliberately withholds repo secrets from pull_request runs triggered by forks, so the preview deploy step will fail with an empty credential. For a solo repo where PRs come from your own branches, this never happens. If you accept outside contributions, gate the deploy step behind if: github.event.pull_request.head.repo.full_name == github.repository so external PRs still run analyze/test but skip the deploy that can't authenticate anyway.
base href and hosting path. If you serve from a subpath rather than the domain root, flutter build web --base-href /subpath/ has to match your Hosting rewrite, or you get a blank screen and 404s on your own assets. Preview channels will surface this before production does.
A green flutter test doesn't prove the web build compiles. Tests run on the Dart VM; web is a separate compilation target (dart2js/Wasm). Keeping flutter build web in the pipeline as a required step is what actually guarantees a deployable artifact — don't rely on tests as a proxy for "it builds."
Deploys are atomic, but propagation isn't instant. Firebase swaps the release atomically, so you won't serve a half-uploaded bundle the way my hotel-Wi-Fi disaster did — that alone fixes the original problem. Just don't be surprised if a CDN edge serves the previous version for a few seconds after the workflow goes green.

What I'd add next, and what I'd skip

I keep this pipeline deliberately small, but two extensions have earned their place on larger projects:

A separate analyze/test job that runs on every PR independent of deploy. For a solo site, folding them into one job is fine. For a team, split them so a red test is a clear, fast signal that isn't tangled up with hosting credentials or deploy permissions. It also lets you require the test job as a branch-protection check without granting the check access to deploy secrets.
Lighthouse CI on the preview URL. Since every PR already produces a live, production-identical URL, you can point Lighthouse at it and fail the build on a performance or accessibility regression. Catching a bundle that ballooned 400KB before merge is a lot cheaper than noticing it in production analytics months later.

And what I'd skip: matrix builds across Flutter channels, elaborate multi-environment promotion flows, anything with the word "orchestration" in it. This is a web app going to one place. The pipeline should be boring, legible, and fit on one screen. Every clever thing you add is a thing that breaks at 11pm when you just wanted to fix a typo.

Key takeaways

Automate to remove yourself as the point of failure, not to save keystrokes. Manual deploys fail exactly when you're distracted; CI runs the same clean steps every time or refuses to ship.
Two triggers, two behaviors: pull requests deploy to an ephemeral preview channel; pushes to main deploy to the live channel. That split is the entire design.
Use a per-project service account, never firebase login:ci tokens. Least privilege, small blast radius, and never echo the secret into a log.
Cache the Flutter SDK and ~/.pub-cache keyed on pubspec.lock — that's where the minutes go. Cache inputs, always rebuild build/.
Pin your Flutter version for reproducible builds so a stable bump can't silently change what ships.
Set expires on preview channels so stale previews don't quietly exhaust your Hosting quota.
Blaze is not "the paid plan." Static hosting stays $0; a $1 budget alert is your safety net.
Wire up the PR-preview half first. The live URL per change is the piece that actually changes how you work.

Wrapping up

The whole setup is one YAML file, one service-account secret, and two caches. Once it's in place, my workflow collapses to: open a PR, click the preview URL the bot posts, glance at it on my phone, merge when it looks right, and watch production update itself. No local builds, no manual firebase deploy, no shipping a blank white screen from a hotel lobby ever again.

If you're deploying a Flutter web app by hand today, don't try to build all of this at once. Wire up the PR-preview half first — even before you automate production. Seeing a real, live URL for every change you make is the single piece that actually changes how you work. The automated production deploy is just the reward you give yourself once you trust the preview.

Dropping Below the Widget Layer: Writing a RenderObject From Scratch

K M Shahriar Hossain — Sat, 05 Sep 2026 22:32:02 +0000

A designer on my team once handed me a "simple" gallery: variable-height cards packed like a Pinterest board, tappable, with a staggered fade-in as they landed. I burned two days forcing it out of Wrap, then GridView, then a CustomScrollView with a delegate I bent into a pretzel. Every version was wrong on the last row, janky on scroll, or quietly O(n²). Then I stopped fighting the widget tree and wrote about 120 lines of RenderBox. It laid out correctly on the first try, painted in one pass, and I have not touched it since.

That is the pattern I want to talk about. Widgets and CustomPaint cover the easy 90% of Flutter's rendering story, and most of us live there for entire careers without a scratch. But the real leverage — the stuff the built-ins genuinely cannot express — lives one layer down, in the render tree. This post is about when to write a custom RenderObject in Flutter, and exactly how to do it, without breaking the framework's layout and painting contracts on the way down.

The three trees: widget, element, and render

Flutter runs three trees in parallel, and understanding the split is the whole game. If you have ever wondered what actually happens between calling build() and seeing pixels, this is it.

The widget tree is your configuration. Widgets are immutable, cheap, thrown away and rebuilt constantly. Padding, Row, your StatelessWidget — all just descriptions, closer to a blueprint than a building.
The element tree is the bookkeeping layer. Element instances are long-lived, hold state, decide what to reuse across rebuilds, and connect widgets to their render objects. You rarely touch these directly, but BuildContext is an element under the hood.
The render tree is where the actual work happens: measuring, positioning, painting, and hit-testing. This is RenderObject and its subclasses, chiefly RenderBox (the 2D box protocol) and RenderSliver (the scrollable viewport protocol).

Most developers never leave the widget tree because they don't have to. Row is a widget wrapping a RenderFlex. Padding wraps a RenderPadding. Opacity wraps a RenderOpacity. Every layout primitive you use is a thin widget over a render object someone at Google already wrote. You compose those primitives and the framework does the rest — that is composition doing its job.

The reason to go lower is that composition has a ceiling. When your layout depends on measuring children against each other, when you need real hit-testing on non-rectangular shapes, when intrinsic sizes matter, or when you are redoing the same expensive layout math every frame because the widget layer left you no cheaper path — that is the render tree calling. Not before. I have watched engineers reach for a custom render object the way some people reach for a rewrite: as a way to feel productive while avoiding the boring composition that would have shipped yesterday. Resist that. A custom RenderObject is a scalpel, not a hammer.

When CustomPaint stops being enough

CustomPaint is the escape hatch everyone reaches for first, and for good reason. Custom drawing, a CustomPainter, done. I use it constantly for charts, progress rings, signature pads, and decorative flourishes. If your problem is "draw pixels inside a box whose size is already decided," CustomPaint is the correct tool and you should not write a RenderObject. Don't over-engineer a solved problem.

It stops being enough the moment any of these show up:

Layout that depends on content. A CustomPainter is handed a Size and paints inside it. It cannot say "I want to be exactly as tall as the tallest thing I contain." If your widget's size is a function of what's inside it, you need performLayout, which painters don't have.
Real children. CustomPaint can take a single child, but that is the ceiling. If you need to lay out and paint an arbitrary list of child widgets — position them, size them, let them handle their own gestures — a painter can't hold them. Painters draw; they don't parent.
Hit-testing beyond the bounding box. A GestureDetector around a CustomPaint gives you a rectangle. If you drew a hexagonal button or a pie chart and taps in the dead corners shouldn't count, the painter has no say in hit-testing.
Intrinsic sizes. Ask a CustomPaint "how wide do you want to be given unlimited height?" and it shrugs. RenderBox exposes computeMinIntrinsicWidth and its siblings, which IntrinsicHeight, Table, and text baselines actually query.

When two or more of those are true at once, stop stacking widgets. Write the render object.

Anatomy of a RenderBox: the constraints contract

The heart of Flutter layout is one sentence, and it's worth tattooing somewhere: constraints go down, sizes go up, and the parent sets position.

A parent hands each child a BoxConstraints — min/max width and min/max height. The child must pick a size that satisfies those constraints and report it back. The parent then decides where to place the child. A child never picks its own position, and it never sees its siblings. That decoupling is exactly what makes Flutter layout single-pass and fast: each box is visited once, top-down for constraints and bottom-up for sizes.

A minimal RenderBox implements a handful of methods. The load-bearing one is performLayout:

class RenderSquare extends RenderBox {
  @override
  void performLayout() {
    // Read the constraints the parent gave us, pick a size, report it.
    final double side = constraints.constrainWidth(200);
    size = Size(side, side);
  }

  @override
  void paint(PaintingContext context, Offset offset) {
    final paint = Paint()..color = const Color(0xFF2962FF);
    context.canvas.drawRect(offset & size, paint);
  }
}

Two rules trip up everyone the first time:

You must set size inside performLayout, and it must satisfy constraints. Return a size outside the given min/max and the framework asserts in debug and misbehaves in release. constraints.constrain(desiredSize) clamps for you, so lean on it.
You must not read size from anywhere except during and after layout. Reading size in your own performLayout before you've assigned it is a classic own-goal, and the assert message that catches it (RenderBox was not laid out) is one you will learn to recognize.

If your box takes children, you don't subclass RenderBox raw — you mix in ContainerRenderObjectMixin and RenderBoxContainerDefaultsMixin, and you attach a ParentData object to each child to stash its offset. The parent data is where "the parent sets position" physically lives.

class FlowParentData extends ContainerBoxParentData<RenderBox> {}

ContainerBoxParentData already carries an offset field. That offset is the child's position relative to the parent, written by the parent during layout and read back during paint and hit-test. This is the spine of everything that follows.

Building a real one: a custom masonry layout

Let me build the thing that sent me down here in the first place — a masonry / column-flow layout. The rule: N columns of fixed width, and each child drops into whichever column is currently shortest. The built-ins can't express this because GridView assumes uniform cell heights and Wrap flows in rows, not balanced columns.

Here's the render object. It's the whole point of the post, so read it slowly.

class RenderMasonry extends RenderBox
    with
        ContainerRenderObjectMixin<RenderBox, FlowParentData>,
        RenderBoxContainerDefaultsMixin<RenderBox, FlowParentData> {
  RenderMasonry({required int columns, required double gap})
      : _columns = columns,
        _gap = gap;

  int _columns;
  set columns(int value) {
    if (_columns == value) return;
    _columns = value;
    markNeedsLayout();
  }

  double _gap;
  set gap(double value) {
    if (_gap == value) return;
    _gap = value;
    markNeedsLayout();
  }

  @override
  void setupParentData(RenderBox child) {
    if (child.parentData is! FlowParentData) {
      child.parentData = FlowParentData();
    }
  }

  @override
  void performLayout() {
    final double totalGap = _gap * (_columns - 1);
    final double columnWidth =
        (constraints.maxWidth - totalGap) / _columns;

    // Track the running height of each column.
    final columnHeights = List<double>.filled(_columns, 0.0);

    final childConstraints = BoxConstraints(
      minWidth: columnWidth,
      maxWidth: columnWidth,
    );

    RenderBox? child = firstChild;
    while (child != null) {
      child.layout(childConstraints, parentUsesSize: true);

      // Find the shortest column.
      int target = 0;
      for (int i = 1; i < _columns; i++) {
        if (columnHeights[i] < columnHeights[target]) target = i;
      }

      final double dx = target * (columnWidth + _gap);
      final double dy = columnHeights[target];
      (child.parentData as FlowParentData).offset = Offset(dx, dy);

      columnHeights[target] += child.size.height + _gap;
      child = childAfter(child);
    }

    final double tallest =
        columnHeights.reduce((a, b) => a > b ? a : b);
    size = constraints.constrain(
      Size(constraints.maxWidth, tallest),
    );
  }

  @override
  void paint(PaintingContext context, Offset offset) {
    defaultPaint(context, offset);
  }

  @override
  bool hitTestChildren(BoxHitTestResult result, {required Offset position}) {
    return defaultHitTestChildren(result, position: position);
  }
}

A few things worth pointing at, because they're the difference between "works" and "works and doesn't fight the framework":

child.layout(childConstraints, parentUsesSize: true) is how the parent measures a child. parentUsesSize: true tells the framework that my layout depends on the child's resulting size, so if that child relays out, I need to relay out too. Get this flag wrong and you get stale layouts that only fix themselves on the next unrelated rebuild — a genuinely nasty bug to chase, because it looks intermittent.
I set tight width constraints (minWidth == maxWidth) so each card fills its column exactly, but I leave height unconstrained, so cards size themselves to their content. That asymmetry is the whole "masonry" effect in one line.
defaultPaint and defaultHitTestChildren come from the mixins and do the right thing: they walk children, apply each one's parent-data offset, and paint/hit-test in order. Don't reinvent them.

The widget wrapper

The widget is boring on purpose — it's a MultiChildRenderObjectWidget that creates and updates the render object:

class Masonry extends MultiChildRenderObjectWidget {
  const Masonry({
    super.key,
    this.columns = 2,
    this.gap = 8,
    required super.children,
  });

  final int columns;
  final double gap;

  @override
  RenderMasonry createRenderObject(BuildContext context) =>
      RenderMasonry(columns: columns, gap: gap);

  @override
  void updateRenderObject(BuildContext context, RenderMasonry ro) {
    ro
      ..columns = columns
      ..gap = gap;
  }
}

Note that the setters call markNeedsLayout(). updateRenderObject fires on every rebuild, but the equality guards inside the setters make sure we only actually relay out when a value truly changed. That's the render tree's version of a rebuild optimization, and it matters more here because layout is expensive. Skipping those guards is the most common performance regression I see in home-grown render objects — every parent rebuild silently marks the whole subtree dirty.

Painting with the layer system and PaintingContext

Naive painting means drawing straight onto context.canvas. That's fine for opaque shapes. But the moment you need clipping, opacity, transforms, or repaint isolation, you should go through PaintingContext, because that's what talks to Flutter's layer system and, ultimately, the compositor thread.

The distinction that matters in practice: context.canvas draws into the current layer, while methods like context.pushClipRect, context.pushOpacity, and context.pushLayer create new composited layers the GPU can handle cheaply. If you want a subtree to repaint independently of its parent, you push it into its own layer. This is exactly why RepaintBoundary exists — it's a render object that forces a fresh layer so a repaint on one side doesn't smear across the whole screen and re-rasterize everything.

If I wanted my masonry cards clipped to rounded corners without wrapping each one in a ClipRRect widget, I'd do it in paint:

@override
void paint(PaintingContext context, Offset offset) {
  RenderBox? child = firstChild;
  while (child != null) {
    final childOffset =
        offset + (child.parentData as FlowParentData).offset;
    context.pushClipRRect(
      needsCompositing,
      childOffset,
      Offset.zero & child.size,
      RRect.fromRectAndRadius(
        Offset.zero & child.size,
        const Radius.circular(12),
      ),
      (ctx, off) => ctx.paintChild(child!, off),
    );
    child = childAfter(child);
  }
}

Two things I learned the slow way here. First, needsCompositing is a real signal — pass it through, don't hardcode true, because forcing compositing everywhere allocates layers you didn't need and quietly costs you memory and frame time. Second, context.paintChild is not optional sugar. It's how the framework knows whether a child needs its own layer and wires the tree together correctly. Calling child.paint directly bypasses that machinery and will bite you when the child is itself a RepaintBoundary or needs compositing.

Hit-testing, gestures, and routing taps to children

A render object that lays out and paints but doesn't hit-test is a picture, not a widget. Taps have to find their way to your children, and Flutter walks the render tree in reverse paint order to route them.

For the common case, the mixin default is correct, but it helps to see the shape of the contract you're implementing:

@override
bool hitTest(BoxHitTestResult result, {required Offset position}) {
  if (size.contains(position)) {
    if (hitTestChildren(result, position: position) || hitTestSelf(position)) {
      result.add(BoxHitTestEntry(this, position));
      return true;
    }
  }
  return false;
}

The contract: return true if the point hit you or a descendant, and if so, add yourself to the result. defaultHitTestChildren handles the child walk, translating the position by each child's parent-data offset — the same offset you wrote during layout, now read in reverse. This is why getting the offset right in performLayout pays off three times: layout, paint, and hit-test all lean on it.

For non-rectangular shapes, override hitTestSelf and do the geometry yourself. A pie-chart segment, for instance, would test the angle and radius of position against the wedge before accepting the tap — that is the whole reason you dropped below GestureDetector's rectangle in the first place.

Semantics: don't ship a render object screen readers can't see

Don't skip semantics. A custom render object is invisible to screen readers unless you describe it. For a container that just positions children — like the masonry above — the children carry their own semantics and you get accessibility for free. But if you draw interactive things yourself, implement describeSemanticsConfiguration and, where the visual order differs from child order, override visitChildrenForSemantics.

On one client project we shipped a custom chart that was completely opaque to accessibility tooling until we added semantics — a real bug, not a nice-to-have, and in some markets a legal compliance requirement. Treat semantics as part of "done," not a stretch goal.

Two framework invariants you must not break

The framework enforces a strict separation of phases, and it does not forgive violations:

Never lay out during paint, and never paint during layout. The phases are separate for a reason — the compositor and the layout pipeline run on different assumptions. If you find yourself calling child.layout inside paint, you've made a mistake the framework can't recover from cleanly, and you'll usually see it as an assertion or a corrupted frame.
markNeedsLayout vs markNeedsPaint. If only appearance changed (a color, a shadow), call markNeedsPaint — cheap, paint-only. If size or position could change, call markNeedsLayout, which also implies a repaint. Calling markNeedsLayout for a color change works but relayouts the world for no reason. Calling markNeedsPaint when geometry actually changed gives you a stale, broken layout. Pick correctly every time; this single decision is most of what separates a smooth render object from a janky one.

RenderBox vs. Sliver: know which door you need

Here's the trap I fell into on that first gallery: I reached for a custom RenderBox when I actually needed a custom sliver.

The distinction is about scrolling. A RenderBox works in the 2D box protocol — it's laid out once against BoxConstraints and it's fully realized in memory. A RenderSliver works in the viewport protocol: it's laid out against SliverConstraints that tell it how much has scrolled past, how much viewport is left, and in which direction. Slivers can lay out lazily — only building the children currently near the visible region — which is why an infinite ListView doesn't build a million widgets and blow your memory budget.

Rule of thumb:

If your custom layout lives inside a scroll view and could contain thousands of items, you probably want a custom sliver (RenderSliverMultiBoxAdaptor territory, driven by a SliverChildBuilderDelegate) so off-screen children aren't built.
If your layout is a bounded, fully-visible region — a card, a widget, a fixed gallery of a few dozen items — a RenderBox is right and far simpler.

My masonry above is a RenderBox. That's fine for a screen's worth of cards. If it needed to scroll through ten thousand images without building them all, I'd have to rewrite it as a sliver adaptor that only lays out the visible window — and lazy masonry is genuinely one of the harder objects to write, because column heights depend on children you haven't measured yet. The honest advice: don't reach for it until a RenderBox version has actually shown you a performance problem. Premature slivers are their own tar pit.

A checklist for shipping a RenderObject you won't regret

Before you consider it done, walk this list:

Every setter guards for equality and calls the correct markNeedsLayout or markNeedsPaint. Layout for geometry, paint for appearance.
performLayout sets size, and the size satisfies constraints. Run in debug; the asserts are your friend here, not your enemy.
Children are laid out with the right parentUsesSize flag. true if your size or child positions depend on their sizes.
Paint uses PaintingContext helpers and paintChild, passes needsCompositing honestly, and never touches child.paint directly.
Hit-testing routes to children via the parent-data offsets, and non-rectangular shapes override hitTestSelf.
Semantics are described for anything interactive you draw yourself.
Intrinsics are implemented (computeMinIntrinsicWidth and friends) if a parent like IntrinsicHeight or Table might ever wrap you; otherwise they throw at runtime.
You wrote a golden test. Render objects are close to pure functions of constraints and children — they're unusually easy to pin down with matchesGoldenFile, and layout regressions are otherwise invisible until a designer notices in review.

Key takeaways

Stay in widgets for anything you can compose, and use CustomPaint for pure drawing inside a size that is already decided.
Drop to RenderBox only when layout depends on content, when you need to parent and position arbitrary children, when hit-testing must be non-rectangular, or when intrinsic sizes matter.
Respect the contract: constraints go down, sizes come up, the parent sets position. Set size, satisfy constraints, and never lay out in paint or paint in layout.
Pick the right dirty flag: markNeedsLayout for geometry, markNeedsPaint for appearance — and guard your setters so rebuilds don't relayout the world.
Use the framework's helpers — defaultPaint, defaultHitTestChildren, paintChild, needsCompositing — instead of reinventing them badly.
Reach for a sliver only when the layout scrolls and could hold thousands of lazily-built children; otherwise a RenderBox is simpler and correct.
Ship it accessible and tested: describe semantics for interactive drawing, and lock the layout down with a golden test.

Dropping below the widget layer is not a flex, it's a tool with a narrow, sharp use case. The masonry object that started all this is still running in production, unchanged, doing in 120 lines what three layers of widget hacks couldn't. That's the trade: a steeper wall to climb, and a much shorter one to maintain once you're over it.

DEV Community: flutter

Offline-First Flutter Architecture

What It Actually Takes to Run a Cross-Border Marketplace: Six Years of Shpper

You are not building one app

The hard problem is trust, and it is not a feature

Money makes everything irreversible

Cross-border is a category of its own

What being CTO of this actually means

The stack, briefly

Your Flutter 404 Page Is Probably Crashing, and Your Server Is Probably Lying About It

Bug one: the status code was a lie

Bug two: the page was crashing the whole time

The fix that does not exist, and the one that also fails

Why it survived so long

A Squarified Treemap by Hand, Because Charting Packages Cannot Drill Down

What the packages give you, and what they don't

Squarified, and why it is worth the trouble

Making it fast enough over a real disk

The bit that has nothing to do with drawing

Was it worth writing?

المنصة اللي جاية بعد الموبايل مش خيال علمي

الذكاءالاصطناعي #نظاراتذكية #هندسة_الموبايل #Flutter

David Stark: Top High-Paying Roles

👋 Hello Architects & Elite Engineers,

1. Staff Software Engineer

2. Senior Quality Engineer (Montevideo)

3. Senior Quality Engineer (São Paulo)

4. Senior Quality Engineer (Mexico City)

5. Software engineer

🚀 Want more?

Saving a Real File From Flutter Web, Instead of Downloading Another Copy

The API that changed this

Why the old way works the way it does

Coming back after a reload

Directories, not just files

What you must handle

Design for the fallback, do not bolt it on

Why this matters more on Flutter Web than elsewhere

A note on security, since people ask

Try it

Scrolling to an Index in a Flutter Lazy List, Without Building Everything Above It

How the archived approach worked

Why the obvious workarounds do not hold

The primitive Flutter already has

Why negative offsets are not a hack

The second thing this fixes

Where this changes what you can build

What it costs

On replacing an archived package

Try it

Talking to Native: FFI, Pigeon, and Knowing Which One You Need

The three Flutter native interop paths, and what they actually cost

Where raw MethodChannel bites you in production

dart:ffi for synchronous C and Rust interop

Pigeon for type-safe platform channels

Threading: where the native boundary really lives

Passing big payloads without killing the codec

Packaging native code so consumers don't need a toolchain

A Flutter native interop decision tree you can apply on Monday

Key takeaways

Getting Work Off the Main Thread: Isolates Without the Hand-Waving

The single-thread myth: what actually blocks a Flutter frame

A quick way to tell them apart

Isolate.run vs compute vs a long-lived spawned isolate

The copy tax: what SendPort actually serializes

A worker-pool pattern for streaming and back-pressure

Sharing memory the legal way: TransferableTypedData and FFI

Isolates on Flutter web: where the story changes

Cancellation, timeouts, and cleaning up a dead worker

Measuring the break-even point before you reach for an isolate

Key takeaways

A Free, Practical CI/CD Pipeline for Flutter Web on Firebase Hosting

Why automate deployment for a one-person site

The shape of the pipeline: two triggers, two behaviors

Getting the Firebase credentials right, once

The GitHub Actions workflow

The GITHUB_TOKEN vs. the service account

Pinning your Flutter version for reproducible builds

Caching Flutter web CI: where the time actually goes

Why key on pubspec.lock, not pubspec.yaml

The `GITHUB_TOKEN` vs. the service account

Why key on `pubspec.lock`, not `pubspec.yaml`