Tech
How Foresight Mobile Took Over Maintenance of Google's flutter_markdown Package
February 18, 2026
In February 2025, I raised a GitHub issue. I didn't expect much to come of it. Eight months later, Foresight Mobile was the official maintainer of one of Flutter's most critical packages, with 140,000+ weekly downloads, a perfect pub.dev score, and a dependency listed inside Google's own experimental AI toolkit.
This is how that happened, what we actually found when we got inside the codebase, and why it matters for anyone building AI-driven Flutter apps right now.
First, some context that I think gets misrepresented in community discussions.
Google didn't abandon flutter_markdown because they're abandoning Flutter. The Flutter core team is executing a deliberate strategic pivot. In 2025 they poured engineering resource into the Impeller graphics engine rewrite, WebAssembly compilation, and Dart macro systems. These are foundational bets that affect every Flutter developer on the planet.
That focus came at a cost: peripheral packages, however widely used, fell outside their immediate purview. flutter_markdown was one of them. The original package had accumulated years of open issues covering everything from RTL text support to LaTeX rendering, table formatting, and SelectionArea compatibility. The core team made the call to deprecate it and look for community maintainers.
It's the right move, by the way. A 55,000-package ecosystem cannot be maintained by one company. The healthiest open-source projects eventually decentralise, and Flutter is doing exactly that.
On 18 February 2025, Ander Dobo from Google's Flutter team responded to my GitHub issue on the main Flutter repo (flutter/flutter #162966). I'd expressed that Foresight Mobile was well-placed to take the package on. We'd been a Flutter-focused agency for around six years at that point, and it felt like the right time to give something back to a framework that had been central to our business since 2017.
Google's approach wasn't to hand over the original package. They wanted us to create a fork under our own verified publisher, publish it independently, and then they'd update the original package's README to point to ours. Clean separation. Sensible.
By 26 February, we had the repo live and had already shipped our first fix: a blockquote formatting bug that had been sitting open in the original package. I invited Ander as a collaborator and asked Google to explicitly deprecate the original with a pointer to ours.
Then came Google's formal criteria. On 12 March, Ander set out what they needed before they'd officially designate flutter_markdown_plus as the replacement:
The CI situation is worth being honest about. We got automated testing and linting running without much trouble. The golden tests were a different story. We tried xcfb_run in GitHub Actions and couldn't get them to pass reliably, as they depended on some Google-specific infrastructure. We made the call to disable them temporarily rather than ship flaky tests. They're still on the roadmap. It's not a decision I love, but it was the pragmatic one.
On 30 May, Google officially marked flutter_markdown as discontinued on pub.dev. flutter_markdown_plus was the replacement.
The "plus" in the name isn't marketing. There are real differences.
Custom builder conflicts. The original package had a recurring issue with developers using custom widget builders alongside anchor tags. The internal logic would clash with the framework's default gesture recognisers. We refactored the link handler logic so it only manages _linkHandlers when a custom builder isn't present. Sounds minor. In practice it was blocking a significant number of real-world use cases.
Table rendering. Markdown tables in Flutter have always been awkward to style. We introduced tableHeadCellsPadding and tableHeadCellsDecoration to MarkdownStyleSheet, added automatic clipping to respect rounded borders when tableBorder specifies a border radius, and added horizontal scrolling for tables that overflow their container.
LaTeX support. This was the most-requested feature we heard about when we took over. The original package had no native LaTeX support. We forked an existing (but abandoned) LaTeX plugin, updated it to work with the renamed package, published it separately as flutter_markdown_plus_latex, and added it to the test app. It renders both inline equations and block-level LaTeX using flutter_math_fork.
Null pointer exceptions in custom block builders. These were patched through community contributions shortly after we took over. Community involvement has been one of the things I've found most satisfying about this project. People showed up with PRs almost immediately.
In our experience, the validation that matters most is what other developers do with your work when you're not watching.
When Google shipped genui, their experimental Generative UI toolkit for Flutter, published under labs.flutter.dev (the verified publisher they reserve for cutting-edge experimental packages), they needed a Markdown renderer. They listed flutter_markdown_plus as a transitive dependency.
Let me put that plainly: Google deprecated their own package, we took it over, and then Google's own AI team adopted our version as a dependency in their flagship new toolkit.
genui is significant beyond the flattery of that fact. It represents where Flutter development is heading. Rather than hard-coding static screens, genui lets apps generate their own user interfaces in real-time based on AI output. The user asks a question, the AI responds with structured JSON, and the app assembles native Flutter widgets dynamically, from a pre-approved catalogue of components, rather than rendering a wall of text.
That architectural pattern means Markdown rendering isn't just for documentation any more. It's the fallback layer for every AI-driven Flutter app: the thing that displays standard LLM text output when the agent decides prose is the right response, and the parser that has to cope with partially streamed tokens arriving in fragments at 60fps.
flutter_markdown_plus isn't the only package that's made this move. The flutter_gen_ai_chat_ui toolkit explicitly migrated to us from the legacy Google package, citing streaming animation failures with the original. The mobileraker 3D printing app migrated for "improved functionality and sustained maintenance." Google's own flutter_ai_toolkit replaced the legacy package at version 0.10.0.
This is the part of the story that I think most Flutter developers haven't fully considered yet.
LLMs produce Markdown. Not because someone decided it would be nice, but because it's computationally efficient. A # character costs one token. The equivalent HTML <h1> costs several. At scale, across millions of API calls, that matters. Industry analysis suggests clean Markdown processing reduces token usage by 20-30% compared to HTML parsing, and improves retrieval accuracy in RAG systems by up to 35%.
What that means practically: every Flutter app integrating an LLM needs a Markdown renderer that can handle streaming. Not complete documents delivered at once, but individual tokens arriving via Server-Sent Events, building an incomplete string that the parser has to interpret before the sentence is even finished.
This is harder than it sounds. Incomplete Markdown breaks most naive implementations. An unclosed code fence, a half-formed table, an asterisk without its pair. The widget tree has to rebuild constantly, at 60fps, without flickering or layout jumps. When we look at the issues that migrated from Google's repo, a significant proportion of them are exactly this class of problem.
From what we've seen, most developers underestimate how central the Markdown renderer becomes once you integrate an AI backend. It's not a utility. It's the interface layer between your LLM and your users.
LaTeX support is solid but the companion package needs better documentation. We're working on that.
The golden tests in CI are the bigger open item. We want them running in GitHub Actions before we consider the project fully stabilised. If you've successfully run Flutter golden tests in a GitHub Actions environment and have opinions on the right approach, we'd genuinely like to hear them. Raise an issue or a discussion on the GitHub repo.
Feature-wise, the 80-issue backlog from Google's original repo covers a substantial surface area: RTL support, VoiceOver accessibility, footnote handling, shrinkWrap improvements, image error builders. We'll work through them based on community demand. Star the repo and open issues if there's something specific you're waiting on.
If you're integrating an LLM into a Flutter app and you haven't yet thought carefully about your Markdown rendering layer, think about it now. The choice of package affects streaming performance, text selection behaviour, table rendering, LaTeX support, and custom widget injection.
flutter_markdown_plus is the active, maintained option. The original is deprecated. The migration from one to the other is a single dependency change in your pubspec.yaml:
dependencies:
flutter_markdown_plus: ^1.0.7
For LaTeX support, add the companion:
dependencies:
flutter_markdown_plus: ^1.0.7
flutter_markdown_plus_latex: ^1.0.4
The pub.dev page has full documentation, and the GitHub repo has an example app that covers the common integration patterns including streaming text, custom builders, and SelectionArea wrapping.
We took this on because we thought it was the right thing to do for the Flutter community. Seven months in, with Google's own AI toolkit listing us as a dependency, I think it was the right call.
Gareth Reese is founder and CTO of Foresight Mobile, a Flutter app development agency based in Manchester, UK. He has been building mobile apps since 2003 and has been an early Flutter adopter since 2017.
