I replaced 4 discontinued Flutter packages. Here's what I learned.

When the Flutter team announced they were discontinuing six first-party
packages (flutter_markdown, palette_generator, flutter_adaptive_scaffold,
flutter_image, ios_platform_images, css_colors), they left the community a
single sentence: "we encourage members of the community to coordinate on
establishing forks."

Six packages. Millions of combined downloads. And no plan.

What I did about it

I didn't set out to maintain replacements. I set out to fix my own problem —
I needed markdown rendering after flutter_markdown died. But once I shipped
one replacement and watched the issue threads fill up with "so what do we use
now?", the pattern became obvious: every discontinued package leaves behind
a large, orphaned user base with nowhere to go.

So I built the Prism family — 15 pure-Flutter packages, no platform channels,
all six platforms. Four of them replace discontinued packages directly:

What I learned

1. The issue threads are a product roadmap.
When flutter_markdown was discontinued, the old backlog was full of
years-old feature requests with hundreds of reactions. The top one —
maxLines/overflow truncation — had 59 upvotes and was never implemented.
I shipped it in my first replacement release. That's not feature planning,
that's just listening.

2. Maintainability beats features.
When palette_generator died, Flutter's own team pointed people at
material_color_utilities — the pro-grade color science library bundled
with Flutter. Instead of copying the old code, I built my replacement on
that foundation. The existing community forks copied first; the ones
built on better foundations are the ones that keep working.

3. Testing discontinued-package replacements is hard — but not optional.
The old packages were battle-tested by years of production use. My
replacements start from zero. For prism_image, that meant spinning up a
real local HTTP server in the test suite and verifying retry behavior
against actual failures — not mocked promises. Two tests are still skipped
pending on-device verification, and I say so publicly rather than pretend
the coverage is complete.

4. Open source feedback loops are fast — when you're responsive.
A maintainer on one of my other PRs suggested a better approach I hadn't
considered (parsing data from a URL instead of hardcoding it). Implementing
his suggestion within a day turned a "requested changes" review into
approval-ready. Responsiveness is the cheapest credibility there is.

What's next

The family now includes AI tooling too — a lean streaming client for LLM
chat completions that works with OpenAI, Ollama, Groq, DeepSeek and any
OpenAI-compatible endpoint, with typed events instead of heavyweight
frameworks. It pairs with prism_markdown for live-rendering AI responses.

If you're one of the developers displaced by the discontinuation wave:
the migration guides are in each package's README, and issues are open —
they're the fastest way these packages improve.

All 15 packages are MIT licensed and linked from
my profile.