flutter_chat_ui: a Flutter chat widget where you supply the backend

The problem it removes is the message list, not the chat

A Flutter app that needs chat usually reaches the same point: someone writes a ListView with reversed ordering, keyboard insets, scroll-to-bottom on new messages, day separators, read receipts, typing indicators, and a bubble layout that has to survive long text, images and files. None of that is the product. Flyer Chat exists to hand that layer over as a package. The README describes it as an open-source chat UI package for Flutter applications, designed for performance, customization, and ease of integration, and the feature list starts with backend-agnostic: connect to any backend service. That first bullet is the honest description of scope. The package renders messages you already have and calls back when the user sends one. It is aimed at teams that have a server, a socket or an HTTP client, and no appetite for rebuilding bubble geometry. The second audience named in the README is generative AI agents and LLM-based assistants, which is a different shape of problem: there the message list is short, the text arrives token by token, and the rendering layer is most of the work.

Three core packages and five optional ones

The repository is a monorepo managed by Melos, and the README splits it into core packages and optional message widget packages. flutter_chat_ui is the main UI package. flutter_chat_core holds core models, controllers, theming, and utilities used across the ecosystem. cross_cache provides a cross-platform (IO and Web) image caching solution, which matters because Flutter's image cache behaves differently on web. The optional half is opinionated: flyer_chat_text_message renders text with markdown support, flyer_chat_text_stream_message renders streamed text messages with markdown and fade-in animation support, and separate packages cover image, file and system messages. This is the design decision worth understanding. Message types are not an enum inside one widget that you extend with a switch statement. They are packages you depend on, each rendering one kind of content. If your product sends a map pin or a payment receipt, the README's position is that you build your own, and the modular bullet states you can change any part of the UI or swap it with your own custom implementation. The cost is more entries in pubspec.yaml and more versions to keep aligned. The benefit is that an app which only shows text and files never compiles the image message package.

What the core package actually owns

The README names the contents of flutter_chat_core precisely: models, controllers, theming and utilities. That sentence is the clearest statement of the architecture available in the supplied material. The UI package consumes models and controllers from core and renders them. Themable defaults live in core, so a custom message package can inherit the same colours and typography as the built-in ones instead of hardcoding its own. The builder functions mentioned under customization are the escape hatch: rather than forking a message widget, you supply a function that returns your own widget for a given slot. Because the details of those builders and controller APIs are not in the README, the honest position is that the flyer.chat documentation is where you check them. What can be said from the repository layout is that the split is deliberate and consistent: shared state and types in core, rendering in the UI package, one package per message kind.

Getting it into a project

Installation is two lines in pubspec.yaml, both pinned to ^2.0.0 in the README example: flutter_chat_core and flutter_chat_ui. The README then says to import and use the Chat widget. That is the entire getting-started path it gives. Everything past that point, including different message types, controllers, and more complex scenarios, is deferred to the full documentation at flyer.chat/docs/flutter/introduction, and the README points at an example application under examples/flyer_chat in the repository for features and customizations in action. If you want streamed assistant output, the package list says you add flyer_chat_text_stream_message as well; if you render files, flyer_chat_file_message. There is no server component to install, no API key, and no config file in the README. The absence is the point: the only configuration surface is Dart dependencies and the widget's own parameters.

Backend-agnostic is a cost as well as a feature

The README lists backend-agnostic first among the features, and it is worth reading that as a boundary rather than a benefit. Nothing in the supplied material describes message persistence, delivery guarantees, ordering across devices, presence, push notifications or moderation. Those are the parts of a chat product that break in production, and this package does not address them. The consequence is a specific failure mode: a team adopts flutter_chat_ui expecting a chat SDK, wires the Chat widget to a naive in-memory list, and discovers that reconnection, duplicate sends and message ordering are all unimplemented. The same boundary applies to generative AI use. The streamed text package handles the fade-in and markdown rendering of a stream, but the stream itself, its cancellation, and its error states come from your code. A second limitation is version coupling. The README pins both core and UI at ^2.0.0, which signals that the two move together. In a monorepo with five optional message packages, a core release can require matching bumps across several dependencies, and the release history shows several releases landing in a short window. Budget for that rather than treating the dependency list as static.

Compared with building on a general widget set

The alternative most Flutter teams actually weigh is not another chat package but a general-purpose widget library plus custom code, or a full chat-as-a-service SDK that bundles the backend and ships its own Flutter UI. The difference in approach is where the boundary sits. A service-backed SDK owns the message store and typically gives you a prebuilt UI you theme but do not restructure, which is faster to start and harder to bend when your product needs a message type the vendor did not anticipate. Building on a general widget set gives you total control and leaves the reversed list, keyboard handling and day separators as your problem. flutter_chat_ui sits between them by taking a position on rendering and no position on transport. That is a real trade, not a strictly better one. If your backend already exists and your message model is stable, the middle position saves the most work. If you have no backend yet, the package removes the part you were least worried about.

Licence, maintenance and what to check before committing

The project is licensed under the Apache License, Version 2.0, with a LICENSE file at the repository root. Apache-2.0 is a permissive licence that includes an express patent grant, which is generally friendlier to corporate adoption than a bare MIT grant, but the terms are the terms and this is not legal advice; if your organisation has a licence review process, run the LICENSE file through it. Maintenance signals visible in the supplied material: the repository is not archived, the most recent push is dated 2026-04-18, and the latest listed release is v2.11.0 from 2025-12-06, following v2.10.0 the same day and v2.9.0 in July 2025. Two releases on one day suggests a fix shipped immediately after a release, which is normal and not alarming, but it does mean you should read the changelog between minor versions rather than assuming a patch-level bump. Upgrade cost is concentrated in the dependency graph rather than in migration scripts: because message types are separate packages, a core change can require coordinated version bumps across flutter_chat_ui and whichever flyer_chat_* packages you use. Before adopting, confirm three things against the flyer.chat documentation: the controller API for loading and appending messages, the builder signature for a custom message type if you need one, and whether flyer_chat_text_stream_message matches how your model delivers partial tokens.

Editorial conclusion

Adopt it if you already have a transport, a message store and a reason to own the rendering layer, and check the flyer.chat/docs/flutter/introduction pages for controllers and message types before writing your own. Do not adopt it expecting a chat backend: the README lists backend-agnostic as a feature, which means persistence, delivery, presence and push are yours. Verify first that the optional message packages you need (flyer_chat_text_stream_message for streamed LLM output, flyer_chat_file_message, flyer_chat_image_message) match your message model, because the core package only defines the models and controllers.

Official sources

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