CometChat Android Jetpack Compose UI Kit v6 is a complete architectural overhaul of the Android UI Kit, rebuilt from the ground up for Kotlin-first, Compose-native development — with a layered architecture, centralized state management, and a modular design that makes integrations faster, testing simpler, and long-term maintenance genuinely manageable.
The entire UI layer runs on native Jetpack Compose composables built with Material 3.
The result is a UI kit that works the way modern Android development expects.
What are we launching?
We're launching CometChat Android Jetpack Compose UI Kit v6 — a production-ready, Kotlin-first UI kit for integrating fully-featured chat into Android applications.
The UI kit is built entirely on Jetpack Compose with Material 3, requires Android 9.0 (API 28) or higher, and supports Gradle 8.0+ with Kotlin DSL.
Three chat experiences, ready to build:
Conversation List + Message View. Sequential navigation
A conversation list as the entry point, tap a conversation to open a full-screen message view. Best for apps where users manage multiple active threads.
One-to-one / group chat
A single chat window with no sidebar. Loads a specific user or group chat directly. Best for customer support flows, direct messages, or notification-driven entry points.
Tab-based chat.
Bottom navigation with dedicated tabs for Chats, Calls, Users, and Settings. Best for full-featured messenger-style applications.
Why does this matter to me as a developer?
As Android applications grow in complexity, the architecture holding them together matters more. Chat integrations need to scale alongside the rest of the app, and that means clean separation of concerns, testable business logic, and customization that doesn't require touching library internals.
V6 is designed around exactly these requirements.
Business logic lives in focused use case classes, keeping ViewModels lean and readable. Data access is abstracted behind interface-driven repository and DataSource layers, so the SDK sits cleanly within a stack rather than being called directly from UI code. Every layer has a single responsibility, which means each one can be tested, replaced, or extended independently.
The result is an integration that fits naturally alongside the patterns Android teams already use; clean, predictable, and built to grow with your application.
Key features and capabilities
Layered architecture
Each layer has a single responsibility. Business logic is separated from data access. Data access is separated from SDK calls. This makes the entire integration easier to reason about, easier to test, and easier to modify when requirements change.
Kotlin-first development
The entire UI kit is written in Kotlin. No Java interop required. The code is more concise, null safety is enforced at the language level, and boilerplate is dramatically reduced compared to v5.
Centralized state management
V6 replaces multiple scattered MutableLiveData instances with a single StateFlow<UIState> using sealed classes. Every UI state change flows through one path. Debugging is simpler. Race conditions are eliminated. UI updates are predictable.
Flexible dependency injection via factory pattern
Dependencies are injected via factory pattern instead of being hardcoded. This means components can be replaced by swapping an interface implementation — no subclassing required. Customizing behavior, mocking for tests, and configuring for different environments all become straightforward.
Pure unit testing support
Business logic in Use Case classes can be tested without the Android framework. Configuration flags like enableListeners = false allow isolated unit tests. Test execution is faster. Coverage is higher. Confidence in releases goes up.
Repository pattern with interface-driven data layer
The DataSource and Repository layers use interfaces throughout. Mocking during testing is trivial. Swapping data sources — for example, migrating SDK versions or changing caching strategies — doesn't require touching business logic.
Shared core module
A reusable core module supports both Jetpack Compose and XML-based UI. Shared code lives in one place. Behavior is consistent across implementations. Feature delivery across UI frameworks is faster.
Extensibility via interface injection
Components can be replaced via interface injection instead of subclassing. Customization doesn't mean forking internal classes — it means providing your own implementation of a well-defined interface.
What's interesting about the architecture behind this?
The design principle behind v6 is that a UI kit should integrate with the way teams build Android applications — not force teams to build around the way a UI kit is structured.
The layered architecture (ViewModel → UseCase → Repository → DataSource → SDK) mirrors how well-structured Android applications are already organized. When a developer adds V6 to an existing project, the integration points are clear because each layer maps to a recognizable pattern.
The decision to use StateFlow<UIState> with sealed classes instead of scattered LiveData reflects how state management has evolved in the Android ecosystem. Compose is declarative. State should be too. A single source of truth for UI state removes an entire category of bugs.
The factory-based dependency injection means components are customized by providing your own implementation of a well-defined interface. Interface injection exposes a stable contract, so library internals can evolve without breaking your integration.
All UI components are native Compose composables built with Material 3. There are no hybrid XML/Compose components. The integration is idiomatic from the composable level up.
Reference links
Documentation: Getting Started with Jetpack Compose UI Kit
Architecture overview: Architecture & Data Flow
Sample app: Android Sample App on GitHub
Figma design file: CometChat UI Kit for Android
Changelog: GitHub Releases
Nivedita Bharathy
Product Marketing Specialist , CometChat