DEV Community: CometChat

Transcription & closed captions for calls

CometChat — Sun, 20 Sep 2026 06:21:37 +0000

Transcription and live closed captions for voice and video calling are now available across all five CometChat Calls SDK platforms: Android, iOS, JavaScript, React Native, and Flutter.

Why this matters

Calls often need to remain useful after they end.

Transcripts can help teams review conversations, maintain records, support compliance workflows, or make call content easier to access later. Live closed captions also make conversations more accessible by allowing users to follow along in real time.

Instead of integrating a separate transcription or captioning provider alongside your calling stack, these capabilities are available through the same CometChat Calls SDK you're already using.

Key Features and Capabilities

Programmatic start and stop

Use startTranscription() and stopTranscription() to control transcription directly from your application logic, without relying on in-call UI controls.

Auto-start transcription

Configure transcription to start automatically when a call session begins, without requiring users to enable it manually.

Live closed captions

Display captions during the call, allowing participants to follow the conversation in real time.

Control panel visibility

Choose whether transcription and caption controls appear in your in-call UI based on the experience you want to provide.

Transcript retrieval from call logs

Once a call ends, retrieve the completed transcript through call logs without setting up a separate transcript storage workflow.

How the Integration Works

Transcription and caption controls are out of box and can be enabled by the user.

This gives you flexibility over how the feature is implemented.

Minimum SDK Versions

Transcription and Closed Captions require the following minimum Calls SDK versions:

Android

Calls SDK v5.0.4+

iOS

Calls SDK v5.0.4+

JavaScript

Calls SDK v5.0.5+

React Native

Calls SDK v5.0.5+

Flutter

Calls SDK v5.0.7+

Check your current Calls SDK version before implementing the feature. Transcription and Closed Captions are not available in versions below these thresholds.

Documentation

Android: https://www.cometchat.com/docs/calls/android/transcription

iOS: https://www.cometchat.com/docs/calls/ios/transcription

JavaScript: https://www.cometchat.com/docs/calls/javascript/transcription

React Native: https://www.cometchat.com/docs/calls/react-native/transcription

Flutter: https://www.cometchat.com/docs/calls/flutter/transcription

A Guide to Developing HIPAA Compliant Chat for Telemedicine Apps

CometChat — Sun, 20 Sep 2026 06:16:37 +0000

Violating HIPAA is easier than it should be. One doctor-patient message through non-secure chat is enough to put you in violation and HIPAA's civil penalties run from $50,000 per violation up to $1.5 million a year for repeat offenses. That's enough to close a clinic.

HIPAA compliant chat for a telemedicine app is patient communication - text, voice, video, file sharing - that meets HIPAA's Security Rule: encrypted in transit and at rest, access-controlled, audit-logged, and covered by a Business Associate Agreement (BAA) with every vendor that touches protected health information (PHI). Miss one of those, and none of it is compliant. This guide covers what HIPAA requires, the features that matter for telemedicine, and how to build it without turning compliance into a second product you maintain forever.

What is HIPAA, and how does it apply to chat?

HIPAA - the Health Insurance Portability and Accountability Act, enacted in 1996 is the US federal law that keeps private health information secure. It sets the rules for how healthcare organizations store, manage, and grant access to patient data.

Chat is squarely in scope. Sensitive information created inside a care relationship - images, file attachments, even IP addresses - moves easily through private messages and group threads. Less-secure chat apps ship with weak encryption, thin authentication, and few controls. That's exactly the gap HIPAA exists to close.

Are you subject to HIPAA?

Two roles matter. Covered entities provide treatment, payment, or healthcare operations - hospitals, doctors, pharmacies, insurers. Business associates are the services that transmit, store, or receive PHI on a covered entity's behalf - which, since a 2013 expansion, includes cloud vendors and chat software providers serving healthcare.

If you're building a telemedicine app that handles PHI, you're a business associate. So is your chat provider. Both are on the hook.

What counts as PHI in a telemedicine app?

PHI is any information that identifies a patient and relates to their health, care, or payment for care. In a chat context that's broad:

Medical records, from an MRI scan to blood test results
Billing records and payment methods
Conversations between patient and doctor, or between clinicians
Any message, note, image, voicemail, or video created inside the care relationship plus metadata that ties a person to a treatment

Assume more PHI than you'd expect, and protect accordingly.

What HIPAA actually requires from your chat

The Security Rule splits into administrative, physical, and technical safeguards. For messaging, these are the ones you implement in code and contracts:

Requirement	What HIPAA expects	What it looks like in practice
Encryption	PHI protected in transit and at rest	AES-256 at rest, TLS 1.2 in transit
Access controls	Only authorized users reach PHI	Role-based permissions, MFA, SSO
Audit controls	A record of who accessed what, when	Logs of message and data access
Integrity	PHI can't be improperly altered or destroyed	Message integrity, retention controls
Transmission security	PHI is safe as it moves across networks	Encrypted channels for chat, calls, files
BAA	Contract making the vendor liable for PHI	A signed BAA with every processor

Two things people get wrong here.

The BAA is the one that gets skipped. A covered entity or business associate must have a signed, executed BAA with every service provider that touches PHI. If a vendor handles PHI and won't sign one, you cannot use them for a compliant workflow - no matter how good their encryption is. The Department of Health and Human Services publishes a sample BAA if you need a starting point.

There is no official HIPAA certification. No government body stamps a product 'HIPAA approved.' Compliance is a shared responsibility between you and your vendors, established through safeguards and BAAs - not a certificate. Anyone selling you a 'HIPAA certificate' is selling you a PDF. (SOC 2 and HITRUST are real certifications, and they overlap heavily with HIPAA's safeguards, being SOC 2 compliant puts you most of the way there.)

One myth worth retiring: HIPAA does not require PHI to stay on US servers. There's no data-residency rule in the law. Safeguards and a BAA are what matter though some providers still prefer US-based data centers for their own policy reasons.

Must-have vs. nice-to-have chat features for telemedicine

Requirements get you compliant. Features get you adopted. Here's the split for a telemedicine chat client.

Non-negotiable, across text and video:

Enterprise-grade encryption. All data, in transit or at rest, encrypted at AES-256 or higher.
Strong authentication. MFA plus unique credentials before anyone reaches PHI.
Automatic logoff. Doctors set devices down mid-shift. Auto-logoff keeps an unattended screen from becoming a breach.

Nice-to-have, and worth it for adoption:

Notifications and reminders. Pre- and post-care reminders cut no-shows and improve follow-through.
Rich media. Audio, video, and images together make a virtual visit feel closer to an in-person one.
Secure file sharing. Lab results and diagnostic scans move between doctor and patient without leaving the compliant channel.

For text chat, add saved history, presence, typing indicators, and multi-device sync. For video, add screen sharing, group calls (when you need a specialist), and secure recording. All of it inside the same compliant infrastructure because HIPAA covers every channel, not just the text box.

How to build HIPAA compliant chat into a telemedicine app

Building it in-house is a real option and it's a serious engineering lift plus a compliance posture you now own forever. The faster path uses infrastructure already built for it.

Run a risk assessment first. Find the security and privacy gaps before you write code. A HIPAA compliance checklist speeds this up.
Sign the BAA. Before a single message carries PHI, get the BAA in place. CometChat signs BAAs covering chat, voice, video, and notifications, so you're not chasing a separate agreement per channel.
Turn on the technical safeguards. Encryption in transit and at rest; role-based access for patients, clinicians, and care teams; MFA; and SSO. CometChat ships these rather than leaving you to assemble them.
Integrate the SDK or UI Kit. Drop in pre-built UI Kits for React, React Native, Flutter, iOS, or Android, or go lower-level with the SDKs. We've also published step-by-step tutorials for iOS and Android telehealth apps.
Confirm audit logging covers PHI access, across every channel. You need a record of who accessed what for both security and any future audit and it has to include voice, video, and files, not just text.

If you're mapping the bigger picture, our guide to telemedicine app development covers the full build, and the telehealth trends piece has the industry numbers.

Is CometChat HIPAA compliant?

Yes. CometChat is HIPAA-compliant and signs BAAs to protect PHI, and is independently certified for SOC 2 and HITRUST. It uses AES-256 and TLS 1.2 encryption, role-based access with MFA and SSO, and secure audit logs - across chat, voice, video, and notifications. Infrastructure runs on a 35+ location edge network with a 99.999% uptime SLA.

That last part matters more than it sounds. Compliance that falls over under load isn't compliance - it's a demo. Patient communication has to hold when the clinic is busy, not just when you're showing it to a stakeholder. CometChat gives you text, voice, and video ready to integrate into a telemedicine app, with the must-have and nice-to-have features already there. See the healthcare solution for the full picture.

Frequently asked questions

Is there an official HIPAA certification? No. Unlike SOC 2 or ISO 27001, HIPAA has no certifying body. Compliance is a shared responsibility between covered entities and their vendors, established through safeguards and BAAs - not a certificate.
Do I need a BAA for a telemedicine chat feature? Yes, if the chat vendor stores, processes, or transmits PHI. Without a signed BAA, using that vendor for patient communication is itself a HIPAA violation, regardless of how strong the encryption is.
Does HIPAA require end-to-end encryption specifically? Not by that name. The Security Rule requires PHI to be encrypted in transit and at rest using recognized standards - AES-256 at rest and TLS 1.2 in transit are the common bar. The rule cares about the protection, not the label.
Does HIPAA apply to video visits and voice calls, not just text? Yes. Any channel carrying PHI is in scope - voice, video, file sharing, notifications, all of it. Keeping every channel inside one compliant platform is simpler than securing each separately.
Does PHI have to stay on US servers? No. HIPAA has no data-residency requirement. Proper safeguards and a signed BAA are what keep PHI protected, wherever it's stored.
Can I build HIPAA compliant chat myself? You can, and it's a large, ongoing commitment - you own the encryption, access controls, audit logging, and compliance posture forever. Most telemedicine teams use compliant infrastructure so their engineers can build the care experience instead of maintaining a messaging stack.

Get started

Chat looks simple right up until PHI touches it. If you're building a telemedicine app and want the compliance groundwork handled before it becomes a second product to maintain, that's what CometChat is built for. Sign up and start building, or talk to our team first.

CometChat Cards

CometChat — Thu, 03 Sep 2026 08:15:47 +0000

Most of what people send each other in a chat isn't really a sentence. Someone shares an event, and the date, location, and RSVP link should travel together. A group admin posts an announcement that deserves more than a wall of text. A friend drops a link that needs a clear next step attached, not just a bare URL. In a 1:1 or group conversation, all of that gets squeezed into plain text, because there's never been a way to send something more structured than a message bubble.

CometChat Cards fixes that. A card carries a block and renders natively, as images, buttons, and layouts, right inside the same 1:1 or group chat window a text message would appear in.

Why does this matter to me as a developer building chat experiences?

Every custom message type you've ever built for a chat app followed the same path: design the payload, write a renderer for it, wire up the actions, repeat for the next one. It doesn't scale past the first few designs, and every platform you support means doing it again.

CometChat Cards take that off your plate. Design a card once, visually, in the CometChat Dashboard, and every UI Kit that supports the format renders it the same way, no custom parsing required.

Key features and capabilities

Card Builder, a visual editor in the Dashboard.
Build cards from 20 elements across four groups: content (text, markdown, image, icon, avatar, badge, chip, code block), layout (row, column, grid, accordion, tabs, divider, spacer), interactive (button, icon button, link), and data (table, progress bar). Four elements, button, icon button, link, and chip, can carry an action, and there are nine kinds to choose from: open a URL, start a chat with a user or group, send a message, copy to clipboard, download a file, initiate a call, hit an API, or run a custom callback in your app.
Nine starter components.
Product Card, Order Confirmation, Order Tracking, Event Card, Announcement, Quick Reply Buttons, Feedback, Data Table, and Carousel come pre-assembled, so you're editing instead of building from a blank canvas.
Variables
Insert placeholders like {{user.name}} anywhere in a card's text or URL fields, and CometChat fills them in per recipient when the card sends.
Built into every UI Kit.
Card messages are rendered automatically across all CometChat UI Kits. When a card message appears in a conversation, the UI Kit detects it and displays the appropriate card interface without any additional setup.
No wiring required
Card messages are handled internally by the UI Kit, so they work out of the box in CometChatMessageList and other standard conversation views across all supported platforms.
Fallback text
Every card includes fallback text. If the card JSON is malformed or a client doesn't support cards yet, the UI Kit falls back to that text instead of showing nothing, so the message still says something.

Where this shows up

CometChat already builds for these industries. Card Builder's starter components map onto what's already happening in each one's 1:1 and group chats:

Marketplace
A buyer and seller are already negotiating a listing in 1:1 chat. A Product Card carries the photo, price, and condition inline instead of the buyer switching to a listing page, and an Order Confirmation card closes the loop once they agree.
On-demand services
Customer and provider are coordinating a job in real time. An Order Tracking card shows live status and ETA right in the thread, the same conversation where they're already discussing pickup details or a delivery photo.
Education
A teacher posts to a class group chat. An Announcement or Event Card carries a session time, a join link, and an RSVP button, instead of the group scrolling past three separate messages to piece it together.
Gaming
A clan or guild group chat gets patch notes, a Data Table of leaderboard standings, or a Carousel of upcoming tournaments, laid out the way a status update actually reads instead of a wall of patch numbers.
Marketplace
A buyer and seller are already negotiating a listing in 1:1 chat. A Product Card carries the photo, price, and condition inline instead of the buyer switching to a listing page, and an Order Confirmation card closes the loop once they agree.
On-demand services.
Customer and provider are coordinating a job in real time. An Order Tracking card shows live status and ETA right in the thread, the same conversation where they're already discussing pickup details or a delivery photo.
Education
A teacher posts to a class group chat. An Announcement or Event Card carries a session time, a join link, and an RSVP button, instead of the group scrolling past three separate messages to piece it together.
Gaming
A clan or guild group chat gets patch notes, a Data Table of leaderboard standings, or a Carousel of upcoming tournaments, laid out the way a status update actually reads instead of a wall of patch numbers.
Healthcare
A patient and provider are messaging 1:1. An Event Card carries an appointment time with a reschedule button attached, or a Feedback card collects a quick check-in after a visit, without either side leaving the thread.
Dating
Two matches are talking. Quick Reply Buttons turn a common question into a tap instead of a typed reply, and a Carousel can surface shared interests or icebreaker prompts inline.
Community and social.
A group admin drops an Event Card for a meetup with an RSVP action, or an Announcement card for a rule change, so it reads as distinct from the conversation instead of getting lost in it.
SaaS businesses
A workspace or support channel gets a Data Table showing open ticket status, or an Announcement card for a new feature, sent to a group the same way any other message would be, just structured.

Reference links

Card Bubble component docs

CometChat Card Builder overview

Elements and actions reference

Card messages in the JavaScript SDK

AI agents for chat

CometChat — Wed, 02 Sep 2026 08:56:46 +0000

CometChat’s iOS UI Kit iOS UI Kit (v5+) now supports AI agent chat. Integrate AI agents into your iOS app to provide intelligent conversational experiences with chat history, contextual responses.

Why this matters to iOS developers

An AI agent isn't a different kind of chat screen — it's the same one-on-one messaging UI you've already built, pointed at a different kind of user. Every time a platform lacks that primitive, you end up building a parallel "AI chat" screen: its own message list, its own way of remembering past sessions, its own resume logic. That's a second UI to maintain for a conversation that should behave like any other thread.

The iOS UI Kit closes that gap. CometChatMessageHeader, CometChatMessageList, and CometChatMessageComposer handle an agent conversation exactly like a human one. You detect the agent, route to the same components, and configure a few agent-specific behaviors — history, streaming, tools on top.

Scope: AI agents respond in one-on-one conversations today , the agent is a user, and you chat with it on the same 1:1 screen.

Key features and capabilities

Agent detection without new data models.

There's no separate "isAgent" flag to fetch and store. CometChatSDK already carries a role on every User; the UI Kit convention is to check that string for "agentic" and branch your navigation accordingly.

Chat history browsing.

CometChatAIAssistanceChatHistory lists a user's past AI conversations. It exposes onNewChatButtonClicked to start fresh and onMessageClicked to resume a previous one — both handed back to your view controller so you control navigation.

Streaming responses, tunable.

messageList.set(streamingSpeed: 50) sets how many characters per second an AI response renders at, rather than dumping the full message at once.

Suggested messages

messageComposer.set(suggestedMessages: [...]) surfaces quick-start prompts in the composer so a new conversation doesn't open on a blank field.

Custom AI tools.

messageComposer.set(aiAssistantTools:) takes a closure keyed to the current message, returning an array of AITool(name:description:) — so the tools you expose to the agent can change based on where the conversation is, not just what's globally available.

Bubble styling

AIAssistantBubbleStyle covers backgroundColor, borderWidth, borderColor, textColor, textFont, and cornerRadius, set globally via CometChatAIAssistantBubble.style or per instance.

Empty state and font control.

messageList.set(emptyStateView:) swaps in your own view for the zero-message state. And since iOS UI Kits inherit font size from the OS accessibility settings by default, textFont (or global CometChatTypography) is there if you need to override that.

What's interesting about the tech

The chat history feature doesn't invent a separate "session" concept to track past AI conversations. Resuming a past thread works by calling set(parentMessage:) on both CometChatMessageList and CometChatMessageComposer — the same parent-message plumbing the UI Kit already uses for threaded replies. Click a message in CometChatAIAssistanceChatHistory, and that message becomes the parent for a new view controller instance; the list and composer thread the conversation from there. No new persistence layer, no separate resume API — the AI history browser is a UI over a messaging primitive that already existed.

Reference links

AI Agent Integration guide

Launching Gaming Chat SDK by CometChat on Product Hunt today

CometChat — Thu, 02 Jul 2026 09:39:07 +0000

Focus on building the game. We'll handle the chat. CometChat's Unreal SDK lets players talk to each other right inside the game, mid-match: 1:1 and group messaging, presence, moderation, and 40+ real-time delegates for messages, typing, and reactions. Full Blueprint and C++ support, so it fits your visual graph or your codebase. Ships with a chat panel and toggle button for your HUD, or build your own UI on CometChat's subsystem. Currently in beta, for Windows, macOS, iOS, and Android.

Feel free to check it out and upvote!
[https://www.producthunt.com/products/cometchat?launch=gaming-chat-sdk-by-cometchat]

On-Premises vs. Cloud Deployment for Enterprise Chat: How to Choose

CometChat — Thu, 02 Jul 2026 09:23:36 +0000

Most deployment decisions for enterprise chat get made the wrong way. Either the security team defaults to on-premises because that's what they know, or the engineering team defaults to cloud because that's what's faster. Neither instinct is wrong; they're just answering different questions.

The actual question is: what does your organization specifically need to control, and what are you willing to trade to get it? CometChat supports both deployment models (and the hybrid ground in between), which means this isn't a pitch for one over the other. It's a breakdown of how to figure out which one fits.

What You're Actually Deciding

On-premises and cloud aren't really about technology preference. They're about where responsibility sits.

With on-premises deployment, your infrastructure team owns everything: the servers, the network, the uptime, the patches, the scaling events at 3am when something unexpected happens. With cloud deployment, a vendor's infrastructure handles that layer, and your team operates on top of it.

Both can be secure. Both can be compliant. The difference is who carries the operational weight, and whether your specific requirements can be met by shared infrastructure at all.

The Case for On-Premises

On-premises deployment earns its place in specific situations. If any of these describe your organization, the case is real, not just a security-team default.

You're in a genuinely air-gapped environment. Defense contractors, government agencies, and certain financial institutions operate in environments where internet connectivity to external systems is either prohibited or impossible. For these organizations, cloud isn't a tradeoff; it's off the table. On-premises isn't a choice so much as a constraint.

Data residency requirements are legally binding, not just preferred. Some industries and regions have regulations that specify exactly where data must physically reside. "Our vendor's data center is in the EU" is different from "this data never leaves our infrastructure." If your legal team needs the second version, only on-premises gives you that.

Your security model requires controlling the encryption keys. Many cloud deployments encrypt data at rest and in transit, but the vendor holds the keys. If your compliance posture requires that your team, and only your team, controls the encryption keys for message content, on-premises is the only architecture that delivers that without compromise.

You've been burned by shared infrastructure before. Multi-tenant cloud environments are well-architected, but noisy-neighbor problems (where heavy usage from another tenant on shared infrastructure degrades your service), unexpected outages, and security incidents that originate in adjacent tenants are real risks. Organizations that have experienced these firsthand often have strong reasons to want dedicated infrastructure.

The total cost of ownership math works in your favor. On-premises requires significant upfront investment: hardware, networking, the engineering headcount to run it. But at sufficient scale, owning your infrastructure can be cheaper than paying per-user or per-message fees indefinitely. If your chat deployment is large and long-lived, run the numbers before assuming cloud is cheaper.

The Case for Cloud Deployment

Cloud deployment is the right call for most organizations, not because it's the default, but because the operational tradeoffs favor it in most situations.

You want to move fast without building an ops team. Running real-time messaging infrastructure at scale is not trivial. CometChat's cloud infrastructure already handles connection management, geographic distribution, failover, and message delivery guarantees in production. Your engineering team gets to focus on your product instead.

Your compliance requirements are standard. HIPAA, SOC 2, GDPR, ISO 27001: cloud deployments from reputable providers support all of these. If your compliance needs fit within what established certifications cover, shared infrastructure is a reasonable choice. The vendor's security investment is often more substantial than what most organizations can replicate on their own.

You need to scale unpredictably. Cloud infrastructure handles traffic spikes without requiring you to have provisioned for the peak in advance. If your usage patterns are variable (seasonal surges, rapid user growth, event-driven spikes), elasticity is worth a lot.

Geographic distribution matters for your users. Delivering low-latency messaging to users across multiple regions requires infrastructure in those regions. Building that yourself is a significant investment. Cloud providers have already done it.

You'd rather pay for uptime than engineer it. On-premises high availability requires redundant hardware, failover configuration, and the expertise to maintain it. Cloud providers build this in. If reliability is critical but you don't want to own the infrastructure that delivers it, cloud is the straightforward answer.

The Middle Ground: Private Cloud and Hybrid Deployments
The on-premises vs. cloud framing misses a third option that's increasingly common for enterprises with complex requirements.

Private cloud gives you dedicated infrastructure (not shared with other tenants) hosted in a cloud provider's data center but provisioned exclusively for your organization. You get geographic flexibility and managed infrastructure without the multi-tenant exposure. For organizations that need data residency in specific regions but don't want to run their own hardware, this is often the right fit.

Hybrid deployment combines on-premises and cloud infrastructure for different parts of the system. A common pattern: sensitive message content and user data stored on-premises, while cloud infrastructure handles connection management and delivery. This lets organizations meet strict data requirements without giving up the operational advantages of cloud for the parts that don't require the same level of control.

Neither option is a compromise; they're architectures designed for organizations whose requirements are more complex than a single deployment model can address.

How to Actually Make the Decision

Skip the philosophical debate and answer these directly:

**Do any of your requirements prohibit external infrastructure? **Air-gap requirements, certain government security clearances, and specific regulatory mandates can make this a binary answer. If yes, on-premises is the path.

Who needs to control the encryption keys? If the answer is "us, exclusively," that rules out most standard cloud deployments.

What's your compliance audit going to ask for? Talk to your legal and compliance team before your engineering team. The requirements they're working against will determine whether a vendor's certifications are sufficient or whether you need something more.

What's your actual engineering capacity? On-premises is not set-and-forget. It requires ongoing maintenance, patch management, capacity planning, and incident response. Be honest about whether you have that capacity before committing to it.

**What does the five-year cost look like? **Calculate cloud costs at your projected scale over five years, then compare against on-premises hardware, networking, and headcount. The answer sometimes surprises people in both directions.

What happens when it breaks at 3am? On-premises means your team responds. Cloud means the vendor's team responds (within their SLA). Your preference here is legitimate data.

Where CometChat Fits In

CometChat supports all three deployment models: cloud, on-premises, and private cloud/hybrid, because organizations with different requirements need actual options, not a recommendation that whatever we run happens to be best.

For cloud deployments, CometChat's managed infrastructure handles the real-time messaging layer, geographic distribution, and uptime. Your team builds the product; the infrastructure runs.

For on-premises deployments, CometChat provides the software to run entirely within your data centers. Your team controls the encryption keys, message data stays within your infrastructure, and the deployment can be configured to meet air-gap requirements. The SDKs and APIs are consistent across deployment models, so your development team works against the same interface regardless of where the backend runs.

For organizations that need something in between, private cloud and hybrid configurations are available on enterprise plans: dedicated infrastructure in specific regions, or split architectures where different components live in different environments based on their sensitivity.

Compliance certifications (HIPAA, SOC 2 Type II, ISO 27001, GDPR) cover CometChat's managed cloud infrastructure. For on-premises deployments, your environment will require its own audit, though CometChat's architecture and documentation are designed to support that process.

If you know which deployment model you need, the documentation is a reasonable starting point. If you're still working through the decision, we're worth talking to; this is a choice organizations get wrong more often than they should, and getting it right before you've built on top of the wrong architecture is considerably easier than after.

React UI Kit v7

CometChat — Wed, 24 Jun 2026 06:53:08 +0000

Chat UI looks like a small part of an app right up until you start shaping it to fit. You need to recompose a component, swap one region for your own, match your brand down to the fonts, and keep all of it working when you move to server-side rendering. Each of those is reasonable on its own. Together they are where chat UI work actually lives.

CometChat React UI Kit v7 is built for that part of the job.

Why does this matter to React developers?

Customizing chat UI is where the real work shows up: a custom empty state, a bubble that renders your own message type, a layout that fits your app rather than a default. v7 is built so those are configuration, not custom code you maintain forever.

Components compose from named sub-parts, so you can swap one region without forking the whole thing. Message rendering runs through plugins, so adding a custom message type is a defined interface rather than a patch. Theming is CSS custom properties, so your brand is a set of variables instead of a stylesheet you maintain against someone else's internals.

And each component handles its own data fetching, real-time listeners, and state. You drop it into your layout and move on.

Key features and capabilities

Four frameworks, one package. The same @cometchat/chat-uikit-react package covers React.js (Vite or Create React App), Next.js (App Router with client-side rendering), React Router (SPA, v6+), and Astro (React islands via the client:only directive). Each gets its own step-by-step integration guide.

Compound components.

Components are built from namespace sub-components (Root, View, EmptyState, and others), so you compose only the parts you need and replace a single region without rebuilding the component around it.

Plugin-based message rendering

Message display runs through the CometChatMessagePlugin interface. Twelve plugins ship by default, covering text, image, video, file, audio, polls, stickers, collaborative documents and whiteboards, group and call system messages, and deleted-message placeholders, with no setup. Add your own by passing them to the plugins prop on CometChatProvider.

Theming with CSS custom properties.

Colors, fonts, and dark mode are driven by --cometchat-* variables, with built-in light and dark themes you can override at the variable level.

19 languages built in.

Localization ships with 19 supported languages and customizable translation keys.

Optional voice and video calling

Add calling by installing @cometchat/calls-sdk-javascript. It is a peer dependency you opt into, not weight you carry by default.

SSR-safe and tree-shakable

No browser-only APIs at module scope, which is what lets it work cleanly with the Next.js App Router. The build is ESM-first with dual ESM and CJS output, so unused components drop out of your bundle.

What's interesting about the tech

The piece worth understanding is how messages actually get on screen. Every message in the UI is rendered by a plugin. Not most messages, every message. When the UI Kit needs to render one, it asks the plugin registry to find a match: the registry scans plugins in order and picks the first whose messageTypes includes the message's type and whose messageCategories includes its category. Deleted messages are special-cased to the Delete plugin. First match wins, so plugin order matters, and a message with no matching plugin simply is not displayed.

That last part sounds like a footnote and is not. It makes rendering a closed, predictable system rather than a pile of conditionals, and it means your custom plugins append after the defaults, so the built-ins keep priority for their own types unless you deliberately take one over. Supporting a new message type becomes implementing an interface, not hunting through render logic.

The SSR rule is the other quiet decision. Keeping browser APIs out of module scope is the difference between a kit that imports cleanly into a server component and one that throws at build time. It is the kind of constraint you only appreciate after it has cost you a weekend somewhere else.

Reference links

Overview and getting started:

https://www.cometchat.com/docs/ui-kit/react/v7/overview

Plugins

https://www.cometchat.com/docs/ui-kit/react/v7/plugins/overview

CometChat Campaigns

CometChat — Wed, 24 Jun 2026 06:49:08 +0000

Most teams building outbound messaging end up in the same place eventually: a notification stack spread across too many tools, a custom dashboard stitched together with glue code, and an engineering ticket required every time ops wants to send a campaign. The stack works until it doesn't, and when it breaks, nobody agrees on where to look first.

CometChat Campaigns is the omnichannel notification platform built into CometChat. It runs on the same infrastructure as CometChat Chat, shares the same user identity system, and lets product, marketing, and operations teams reach users across every channel without building or maintaining the plumbing themselves.

Why this matters to product managers and marketers

Every campaign your team wants to send should not require a conversation with engineering first. It usually does, because the tools that handle delivery are not the same tools that understand your users. Someone has to map IDs, configure the right endpoint, and make sure the right segment gets the right message at the right time. That work lands on a sprint. The campaign waits.

Campaigns changes that relationship. Marketing and ops teams can build, schedule, and send directly from the CometChat dashboard, without raising a ticket or waiting on a release cycle. Audience targeting, message templates, A/B testing, and delivery scheduling are all available without writing a line of code.

And because Campaigns runs on the same platform as CometChat Chat, the user data your product already has is the user data your campaigns run on. No exports, no imports, no sync jobs keeping two systems loosely in agreement. When a buyer goes quiet in a marketplace conversation, Campaigns can trigger a re-engagement nudge based on that signal directly. When a user is mid-conversation, push gets suppressed automatically. That kind of context-aware delivery is what most teams are trying to approximate by stitching tools together. Here it is the default behavior.

Key features and capabilities

Omnichannel delivery from a single endpoint.

In-app, push, SMS, and email are all reachable through one API call. Channel sequencing handles fallback logic automatically: in-app first (no opt-in required), then push, then SMS. Volume shifts to the cheapest effective channel without custom routing code.

No-code campaign builder.

Marketing and ops teams can design, schedule, and send campaigns from the CometChat dashboard without raising an engineering request. Message templates with variable substitution handle personalization at scale. Audience targeting lets teams segment by behavior, attributes, or custom events.

A/B testing built in

Test message variants across channels and let delivery data decide what ships. No separate testing tool, no manual result aggregation.

Cross-channel analytics in one view.

Open rates, click-through rates, A/B outcomes, and individual user notification history are all visible in the same dashboard. You can see which channel is doing the work and which is generating spend without benefit, without exporting to a separate tool.

Multi-tenant architecture, inherited from CometChat Chat.

Per-tenant notification configs, templates, and analytics with full data isolation. One instance serves multiple brands or communities without rebuilding anything for each one.

Compliance included from day one.

HIPAA, GDPR, SOC 2, and ISO 27001 support is part of the platform. Audit logs and moderation policy apply consistently across Chat and Campaigns from a single configuration.

Integration options

Four ways to connect, depending on where you are:

Unified API

One endpoint to trigger notifications across all channels. Connects to any backend workflow, billing system, or CRM without rebuilding your stack.

UI Kits

Pre-built in-app message center components for iOS, Android, Flutter, and JavaScript. Drop in and theme to match your product.

SDKs

. iOS, Android, Flutter, React Native, and JavaScript, for teams that want native control over the in-app notification experience.

Webhooks

Trigger campaigns from existing internal systems without re-platforming.

What is worth understanding about the architecture

The no-code builder is genuinely operator-first. When customization is needed, UI kits share the same theming system as CometChat Chat, so custom UX does not mean starting from scratch or abandoning the dashboard.

Channel sequencing defaults to in-app first for a specific reason: in-app requires no opt-in, which makes it the highest-reach channel by default. Push requires opt-in. SMS costs money per message. The sequencing logic exhausts the free, high-reach channel before touching paid ones, and it does this automatically. Notification fatigue has a way of becoming a product problem before it shows up in the metrics. Channel intelligence is the structural answer, not a campaign calendar review.

Pricing does not penalize growth. There is no MAU-based billing and no overage charges at peak concurrent connections. The cost structure stays predictable as volume scales.

To learn more

Notification Fatigue Is a Product Problem, Not a Marketing One

CometChat — Thu, 04 Jun 2026 07:51:39 +0000

There's a moment every growth team eventually hits: open rates drop, unsubscribes climb, and someone in the room suggests the copy needs work. So the copy gets rewritten. The subject line gets A/B tested. The send time shifts from 10am to 10:14am because someone read a study.

And nothing really changes.

That's because notification fatigue isn't a messaging problem. It's a sequencing problem, a channel problem, and at its root - a product architecture problem. By the time your metrics move, the damage is already done.

The Damage Happens Before You Can See It

Here's what notification fatigue actually looks like operationally: a user gets a push. They don't open it. Three hours later, they get an SMS for the same thing. Then a WhatsApp message. Then another push.

None of this registers as an error in your analytics. Delivery was successful. The campaign ‘ran.’ But somewhere between the second and third message, the user decided your notifications aren't worth reading anymore. They turned them off or just started ignoring them, which is functionally the same thing but harder to measure.

The open rate dip you'll notice next week is a lagging indicator of a decision your product forced them to make days ago. You can't fix that with better copy. You needed to never send those three messages in the first place.

Volume Is the Wrong Variable to Optimize

Most messaging systems are built around volume. More touchpoints, more conversions that's the assumption. And it works, briefly, right until users start treating your notifications the way most people treat car alarms: background noise that implies nothing urgent.

The teams that get this right aren't sending fewer messages because they're conservative. They're sending the right message on the right channel because they've built sequencing logic that accounts for what the user already did.

If a user opened your in-app message, they don't need the SMS. If the push converted, the WhatsApp follow-up is friction, not reinforcement. Sequencing isn't about timing delays between blasts, it's about making each next message contingent on whether the last one worked.

This is a technical decision, not a creative one. And it belongs in your messaging infrastructure, not in a campaign brief.

Channel Intelligence Matters More Than Channel Coverage

There's a version of ‘omnichannel’ that means: we send everything, everywhere, always. It's expensive, it's annoying, and it produces the kind of engagement numbers that look fine until your retention metrics tell a different story.

The more useful version of omnichannel is channel sequencing with fallback logic: start on your highest-signal, lowest-cost channel (in-app notifications, if the user is active), and only escalate to SMS or WhatsApp if the previous touchpoint went unanswered. You reserve the expensive, interruptive channels for the moments that actually need them not as a default.

This does two things. It keeps your cost-per-message reasonable at scale. And it keeps users from associating your brand with interruption.

The second effect is harder to model but more consequential. A user who trusts that your SMS means something important will open it. A user who's been trained by three months of redundant blasts will see your sender name and feel mild irritation. That's not a recoverable state.

Why This Is a Product Problem

Marketing teams are usually the ones blamed for notification fatigue. But marketing teams are operating within the constraints of whatever messaging infrastructure the product team built. If the infrastructure doesn't support behavior-triggered sequencing - if it can't check whether a message was viewed before firing the next one, then even a thoughtful messaging strategy gets flattened into: send everything, measure what we can, iterate.

The fix isn't a better campaign strategy. It's messaging infrastructure that treats user behavior as a first-class input: one that can sequence across channels, check delivery and view status before escalating, and apply rules that match the actual logic of your engagement goals.

When that infrastructure exists, ‘notification fatigue’ stops being a recurring agenda item. It stops being something you manage after the fact. Your system just doesn't do the thing that causes it.

What CometChat Campaigns Gets Right

CometChat Campaigns is built around this exact problem. You define your audience, your channels, and your sequence logic and the platform handles escalation based on what actually happened: was it delivered, was it viewed, was it clicked?

You start in-app. If the user doesn't engage, you fall back to push. If still nothing, you can escalate to SMS or WhatsApp. Each step is conditional, not automatic. The user who already converted never sees the follow-up. The user who missed it does.

It's a small architectural shift from broadcast to conditional delivery and it's the difference between a notification system that earns attention and one that trains users to ignore it.

Notification fatigue isn't inevitable. It's what happens when volume substitutes for intelligence. The teams who solve it aren't better marketers. They're building on infrastructure that treats the next message as a function of what the last one accomplished and that's a product decision worth making early.

Launching CometChat Campaigns on Product Hunt today!

CometChat — Wed, 03 Jun 2026 10:00:53 +0000

One dashboard to build, customize, and send omnichannel notifications to your users. Marketing offers, feature announcements, support alerts, operational broadcasts. Design your templates, pick your audience, and deliver across in-app, push, SMS, and email. A/B test variants, schedule sends, and track performance end to end. Marketers, ops, support, developers. Everyone on your team can run campaigns from day one.

https://www.producthunt.com/products/cometchat-campaigns?launch=cometchat-campaigns

It would be great if you could take a moment to go and upvote!!

Launching Chat Skills for AI Agents on Product Hunt today

CometChat — Wed, 27 May 2026 08:13:56 +0000

This helps you add fully functional chat to your React app using AI agent skills. Drop in a skill file and your agent handles the full integration: installation, environment setup, SSR-safe rendering, and the correct init and login flow. One file per framework. Works seamlessly with Cursor, Kiro, VS Code Copilot, Claude, and Codex. Go from zero to a working chat in minutes, built on CometChat's proven foundation and ready for real projects from day one.

https://www.producthunt.com/products/cometchat-skills?launch=calling-skills-for-ai-agents

It'll be great if you could check it out and upvote!

Launching Voice and Video Calling by CometChat on Product Hunt today!

CometChat — Wed, 20 May 2026 07:51:01 +0000

CometChat Calling gives you HD voice and video, built to ship fast and scale high. Recording, screen sharing, call logs, raise hand, and picture-in-picture out of the box. Integrate via SDKs, or drop a CometChat Skills file into your coding agent and let it handle the setup. Handles high-concurrency calls, with HIPAA, GDPR, SOC 2, and ISO 27001 compliance built in.

producthunt.com