cometchat-uikit-flutter: chat and calling components for Flutter

What the package is

The CometChat UIKit for Flutter provides pre-built user interface components to add chat, voice, and video calling features to a Flutter application quickly.

That is the whole product, and the interesting word in it is pre-built. A chat interface is one of those things that looks simple in a design and turns out to be a large amount of work in practice: the message list, the composer, the typing indicator, the read receipts, the attachment handling, the presence indicators, the call screens, the call history, the group versus one-to-one distinction, and the notification behaviour. None of it is hard on its own, and all of it together is a product.

So the package is a way of not building it. The application supplies the identity and the service configuration, and the kit supplies the screens, the state management, and the wiring to the service.

And the three capabilities it names map onto three separate use cases. Text chat is the one everybody needs. Voice and video calling are the ones that are hard, because they involve call setup, media, and a call interface, and because a call screen has to deal with the states a call goes through rather than just rendering a list.

The topics the repository carries name the same ground: calling, chat, conference, messaging, video and voice, alongside the framework itself and the general category of an application.

The licence is MIT, the default branch is a version branch rather than the usual main, and the release history shows a steady major line with three releases across the last quarter of 2026. That last detail is the one to note: the package is versioned on a major that the documentation is also versioned on, which is the arrangement that lets a UI kit change its interface without breaking every application that uses it.

The repository structure, and the skills directory

The readme opens with a table of the four directories in the repository, and the table is more informative than a typical directory listing because it says what each one is for.

The first is the package itself, described as the open source UIKit package, with a note that its own readme covers the local setup, the structure, and the tests. The second is a skills directory inside that package, described as skills for consumers and contributors. The third is a sample application demonstrating how the kit is used. And the fourth is a second sample application, described as an artificial intelligence powered sample app with CometChat AI agents.

The skills directory is the interesting one, because it is a new kind of entry in a component library. A skill is a document that tells a coding assistant how a library should be used, and shipping one inside the package means the guidance travels with the code rather than living in a separate site that goes out of date. And the wording covers both audiences, consumers and contributors, which suggests two different bodies of knowledge: how to use the kit in an application, and how to work on the kit itself.

The second sample application, with its artificial intelligence agents, is the other new thing in the repository. It exists because a chat kit is easiest to demonstrate with something to chat with, and an agent that replies is more interesting than a canned response. It also signals where the vendor thinks the product is going, which is useful to know before you build on it.

The top level of the repository then holds the things a Dart package repository holds: a changelog, a licence file, the readme, a static analysis options file, the package configuration, and directories for the examples, the images, the packages, and the skills.

The static analysis options file is worth noticing. It is the Dart equivalent of a linter configuration, and having one in the repository means the code is checked against a declared set of rules rather than against whatever the author's editor happened to have enabled.

The prerequisites, and the version floors

The prerequisites section is short, and every line of it is a decision you have to make before anything works.

There is a Flutter SDK floor and a Dart SDK floor, and they are specific numbers rather than vague minimums. There is a mobile platform floor for both of the two platforms the kit runs on. And there is an account requirement: a CometChat account with an app identifier and an auth key.

The account requirement is the one that changes the nature of the project. This is not a self-hosted component library. The kit is the interface, and the service behind it is a hosted product with a dashboard, a region, and a credential. So the dependency list is not only a list of toolchains, it is a list of things you need from a vendor.

The readme handles that honestly in the getting started section. The first step is to sign up and create a new app. The second is to note the app identifier, the region, and the auth key from the dashboard. The third is to clone the repository. And the fourth is that on first launch you enter those three values on a credentials screen in the application.

So the region is part of the identity of the setup. It tells the kit which of the service's regions to talk to, and getting it wrong produces a connection failure rather than a clear error, which is why the instructions tell you to write it down at the start rather than to discover it later.

And the credentials screen is a deliberate design decision for a kit that runs in development. A sample application that asks for a key on first launch is one that a new contributor can open and use without anybody having to edit a configuration file, and the fact that the readme mentions it as the fourth step of the setup suggests the screen is the first thing a user meets.

The version floors are the other half of the story, and they tell you what the project is built against. Recent toolchain versions as a hard requirement is a sign of a component that is actively maintained and is not trying to support old applications.

Running the sample before you install anything

The getting started section puts the sample application first, and that ordering is the right one for a kit.

git clone https://github.com/cometchat/cometchat-uikit-flutter.git
cd cometchat-uikit-flutter/examples/sample_app
flutter pub get
flutter run

You clone, you change into the example directory, you fetch the dependencies, and you run it. There is no step where you create a project, paste in a dependency, and work out how the components are meant to be composed, because the example is already a project that does exactly that.

That is worth a paragraph on its own, because a component library is only as good as its examples, and the failure mode is a readme that shows a snippet of a widget and leaves the reader to work out the surrounding application. Here the readme points at a directory in the repository that is a working application.

And the installation section is then one small step, because the reader has already seen the thing working. You add the package to your project's dependency list, with a version constraint.

dependencies:
  cometchat_chat_uikit: ^6.2.0

And then you fetch the dependencies again, which is the same command you ran in the example, and the constraint is a caret on the current major. So the version you put in your project is the same major you just ran, and the documentation link in the readme is versioned by major as well, which is the pattern that lets a kit ship interface changes in a new major without breaking the applications on the old one.

The naming of the package is the last small thing worth noticing, and it is a common convention in the Dart ecosystem. The organisation and the product name are joined with a low dash, and the name of the product is in the middle, which is a scheme that makes it possible to publish several related packages under one organisation without them colliding in search.

The readme then points at the official documentation for detailed setup and usage guides, and the help section says where to go for each kind of question: issues in this repository for bugs and features in the kit itself, and the documentation, the support portal, or real-time support through the dashboard for anything about the account, the billing, or the integration.

Editorial conclusion

cometchat-uikit-flutter fits a Flutter team that needs messaging and calling in its product and would rather use a vendor's components than design a messenger itself. It does not fit a project that wants to own the chat experience end to end, and it does not fit somebody who needs the service itself rather than the interface to it. Verify first that your Flutter and Dart versions are at or above the stated floors, because the package tracks recent toolchain releases, that the account you create gives you the region and credentials the app asks for on first launch, and that the major version of the package you add matches the major version of the documentation you read, since the documentation is versioned by major.

Frequently asked questions

Official sources

1. cometchat/cometchat-uikit-flutter on GitHub
2. License: MIT
3. Project website
4. README
5. Releases