flutter_chat_ui: a backend-agnostic chat UI for Flutter, assessed

What flutter_chat_ui actually takes off your plate

Building a chat screen in Flutter is not hard in the first week and is tedious in the third. Message bubbles, grouping, timestamps, avatars, input field behaviour, scroll anchoring when new messages arrive, and the small state machine around sending and failing all have to be written and then rewritten per platform. flutter_chat_ui is a UI package that supplies those surfaces so you do not write them.

The intended audience is narrow and specific. The README describes it as "an open-source chat UI package for Flutter applications" and lists real-time messengers, generative AI agents and LLM-based assistants, support platforms, and beyond as the adaptable targets. The AI framing is not decoration: there is a dedicated flyer_chat_text_stream_message package for streamed text with markdown and a fade-in animation, which is the shape an LLM response takes when it arrives token by token. If you are building a chat screen on top of an existing API, this is aimed at you. If you want a chat product with accounts, delivery guarantees and a database, this is not it, and the README does not pretend otherwise.

The monorepo split: core, UI, and swappable message widgets

The repository is a Melos-managed monorepo, and the layout matters more than the marketing copy. Under packages/ the README names three foundational pieces: flutter_chat_ui (the main UI package), flutter_chat_core (models, controllers, theming and utilities shared across the ecosystem), and cross_cache (a cross-platform image caching solution covering IO and Web).

Message rendering is then split into optional packages: flyer_chat_text_message, flyer_chat_text_stream_message, flyer_chat_image_message, flyer_chat_file_message and flyer_chat_system_message. The README calls these "opinionated packages for rendering different message types" and adds that you can build your own. That is the real architectural claim: the UI package does not hardcode what a text message looks like, it delegates to a widget you choose or write. The practical consequence is a dependency list you assemble yourself. A chat screen that only shows text and images does not have to pull in the file or system message packages.

The data flow is the part the README leaves to the linked documentation. It states that the package is backend-agnostic and that you connect it to any backend service, and it points to flyer.chat/docs/flutter/introduction for controllers and more complex scenarios. What is visible in the repository is the boundary: models and controllers live in flutter_chat_core, rendering lives in flutter_chat_ui. Your transport sits outside both. Nothing in the README describes retries, delivery receipts or persistence, so treat those as yours to implement.

Installing flutter_chat_ui and rendering a first chat screen

The README gives one installation step: add the packages to your pubspec.yaml. Note that it lists both flutter_chat_core and flutter_chat_ui at ^2.0.0, so the core package is an explicit dependency rather than something the UI package pulls in silently for you.

dependencies:
  flutter_chat_core: ^2.0.0
  flutter_chat_ui: ^2.0.0

After that, run flutter pub get. The README then says to "import and use the Chat widget" and stops there, deferring controllers, message types and customization to flyer.chat/docs/flutter/introduction. That is the honest limit of what the repository tells you: the widget name is Chat, and the rest of the API surface lives in the docs site.

For a working reference, the README points at the example application in the repository at examples/flyer_chat, describing it as comprehensive and covering various features and customizations. If you are evaluating the package, reading that example is a faster route than guessing at the constructor from the package name. The repository also ships analysis_options.yaml at the top level, which tells you the maintainers run a shared lint configuration across the monorepo; expect the example to be lint-clean and therefore a reasonable template.

Where the package stops and you have to start

Backend-agnostic is a two-sided phrase. It means no vendor lock-in and it means no batteries. The README does not document message persistence, delivery state, reconnection, push notifications, moderation, or read receipts. Every one of those is a decision you make and a component you write or buy elsewhere.

There is a second, quieter limitation in the packaging. Because message types ship as separate packages, the default experience of installing flutter_chat_ui is thinner than the feature list suggests. A reader skimming the features section sees markdown support and fade-in streaming, but those live in flyer_chat_text_message and flyer_chat_text_stream_message respectively, and you have to add them. This is a deliberate trade-off rather than an oversight, and for a team with a fixed set of message types it is the right one. For a team that wants a chat screen working in an afternoon, it is one more assembly step.

The third constraint is Flutter itself. This is a Dart package for Flutter applications, so it does not help a React Native, native iOS or web-only codebase. The README lists iOS, Android, Web, macOS, Windows and Linux as supported platforms, which is broad, but the requirement to be inside a Flutter project is absolute.

How it compares to wiring your own chat widgets

The realistic alternative is not another package, it is building the chat layer yourself on top of Flutter's ListView and TextField. That approach gives you total control over scroll physics, bubble geometry and input behaviour, and it costs you the weeks spent on edge cases: keyboard insets, message grouping, and image loading that behaves the same on Web and on IO.

cross_cache is the concrete point of difference here. The README describes it as providing a cross-platform image caching solution covering IO and Web. Anyone who has shipped a Flutter chat app knows that image caching is where platform divergence shows up first, because the web target has no filesystem to cache into. A hand-rolled solution typically either ignores Web or grows a conditional import tree. Having that solved inside the dependency graph is a real argument for the package.

The other difference is the message-type package split. Rolling your own means one widget that tries to handle everything. flutter_chat_ui means a registry of small widgets, each replaceable, which is a better fit for products where one message type needs heavy customization and the rest do not.

Maintenance, licensing and the cost of upgrades

The repository is not archived. The last push was on 2026-04-18, and the most recent release listed is v2.11.0 from 2025-12-06, following v2.10.0 on the same day and v2.9.0 on 2025-07-26. That release cadence is uneven rather than constant: two releases landed within an hour of each other in December 2025, then nothing in the release list for roughly four months before the April push.

The upgrade cost is shaped by the monorepo split. Because flutter_chat_core and flutter_chat_ui are separate published packages, a major bump in core is a change you have to absorb in your own pubspec.yaml, and the README's own installation snippet pins both at ^2.0.0. If you also depend on the optional message widget packages, an upgrade can mean coordinating versions across five or six entries rather than one. Budget for reading the changelogs of each package you import, not just the UI one.

Licensing is Apache-2.0, stated in the README and present as a LICENSE file at the repository root. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices. What that means for your product is a question for your own counsel; the factual point is that the package is free to use under Apache 2.0 and the repository carries the licence text.

Editorial conclusion

Adopt flutter_chat_ui if you already own a message transport and want the rendering, theming and message-type widgets handled for you; skip it if you need a server, storage or moderation layer, because the package ships none of those and the README points to flyer.chat for anything beyond installation. Before you start, verify three things: that flutter_chat_core and flutter_chat_ui resolve at the same major version in your pubspec.yaml, that the example application under examples/flyer_chat compiles against your Flutter channel, and that the optional widget packages you intend to use (text, text stream, image, file, system) are the ones you actually add, since they are separate dependencies rather than bundled defaults.

Frequently asked questions

Official sources

1. flyerhq/flutter_chat_ui on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases