If you ship both a web app and a mobile app, sooner or later someone asks whether the chat stack you picked for React will carry over to React Native. The honest answer is: partly. The networking and data layers usually transfer, the UI layer almost never does. This post walks through the chat library landscape on both platforms as it looks in 2026, what has changed since we first wrote this comparison in early 2024, and what actually moves between the two.
If you are new to the split between the two frameworks, our overview of React vs React Native covers why “it is all just React” breaks down exactly at the rendering layer, which is where chat UI lives.
Three kinds of chat library
Most confusion in this space comes from comparing tools that sit at different layers. It helps to sort everything into three buckets:
- Transport libraries. Socket.IO, plain WebSockets, XMPP clients, MQTT. They move messages and nothing else. You build storage, history, presence, moderation, and every pixel of UI yourself.
- UI kits. Prebuilt message lists, bubbles, composers, and typing indicators. React Native Gifted Chat is the classic example. They render a conversation but do not talk to any backend.
- Full SDKs. Hosted or self-hosted backends with client libraries and usually their own UI components. CometChat, Sendbird, and Stream are the big commercial names; open source options exist too.
The 2024 version of this article compared Socket.IO, CometChat, Sendbird, and Gifted Chat as if they were interchangeable. They are not, and picking the wrong layer costs more than picking the wrong vendor within a layer.
The React web side
On web, the transport route is still very viable. Socket.IO remains actively maintained and pairs naturally with a Node backend. You get reconnection handling, rooms, and fallbacks for free, and everything else is your problem. Teams pick this when chat is a small feature inside a larger product and they already run their own realtime infrastructure.
For full SDKs, the commercial trio all ship dedicated React packages:
- Stream publishes stream-chat-react on top of its stream-chat JS client. Both saw releases within days of this writing, and Stream has been the most aggressive of the three about shipping AI-adjacent components.
- Sendbird offers UIKit for React plus a lower level JS SDK. Mature, enterprise leaning, priced accordingly.
- CometChat ships a React UI kit and JS SDK with a similar shape: drop-in conversation views backed by their hosted service.
What web notably lacks is a dominant standalone UI kit. There is no web equivalent of Gifted Chat with the same mindshare. In practice, web teams either use the UI components bundled with their SDK vendor or build the message list themselves, which on web is a manageable job because DOM scrolling and text input are less hostile than their mobile counterparts.
The React Native side
React Native inverts that picture. Here the standalone UI kit is the famous piece, and the hard part is the platform itself: inverted lists, keyboard avoidance, and input accessory views are genuinely painful to get right on both iOS and Android.
React Native Gifted Chat deserves a status update, since it anchored the 2024 comparison. The library is still available and still receives occasional releases, but the maintainers have signalled maintenance mode, and much of the active development energy has moved to community forks. It remains a reasonable choice for a simple chat screen you plan to own and style yourself. For a product where chat is core, plan for the possibility that you become the maintainer of your fork.
The commercial SDKs all treat React Native as a first-class target:
- Stream maintains stream-chat-react-native with frequent releases and Expo support, sharing its stream-chat client with the web SDK.
- Sendbird has UIKit for React Native alongside its JS SDK.
- CometChat ships a React Native UI kit backed by the same APIs as its web offering.
On the open source and self-hosted end, Ethora provides chat and AI agent components for both React and React Native on top of an XMPP backend you can run yourself. Disclosure: this site is run by the team that builds Ethora, so weigh that mention accordingly. Self-hosting matters mainly if you are in healthcare, finance, or another environment where message data cannot live on a third-party cloud.
For a deeper feature-by-feature look at the mobile options, see our React Native chat SDK comparison.
What actually transfers between platforms
| Layer | Transfers from web to React Native? | Notes |
|---|---|---|
| Transport client (Socket.IO, WebSocket, XMPP) | Mostly yes | Same JS client usually works; background behavior and reconnection differ on mobile |
| Vendor core SDK (stream-chat, Sendbird JS, CometChat JS) | Yes | Shared clients are the strongest argument for the commercial SDKs |
| State and business logic (hooks, stores, message normalization) | Yes | Keep this in shared packages from day one |
| UI components | No | DOM and native views do not mix; every vendor ships separate UI kits per platform |
| Push notifications | No | Web push and APNs/FCM are entirely different integrations |
The pattern that works in monorepos: one shared package holding the chat client, message types, and hooks, then thin platform-specific UI packages on top. Both Stream and Sendbird are effectively built this way internally, which is why their web and mobile SDKs feel consistent.
How to choose in 2026
- Chat is a minor feature, web only. Socket.IO plus a hand-rolled message list is still fine.
- Chat is a minor feature, both platforms. A commercial SDK earns its subscription quickly, because you get two maintained UI kits and one shared client instead of building keyboard handling twice.
- Chat is the product. Budget for either a serious commercial tier or real engineering ownership of an open source stack. Pay attention to per-user pricing curves; they are gentle at prototype scale and steep at consumer scale.
- Regulated data. Shortlist self-hostable options first and treat hosted vendors as the exception you justify, not the default.
The biggest change since 2024 is not any single library. It is that AI features, agents, translation, and summarization moved from novelty to checklist items, and vendors now compete on how well their message primitives accommodate streaming bot responses. Whatever you pick, check how it renders a message that is still being generated. That question did not exist when we first published this comparison, and today it separates the stacks that were designed recently from the ones that were patched.