Rocket.Chat.ReactNative: the mobile client behind Rocket.Chat, reviewed for self-hosters

What Rocket.Chat.ReactNative actually is, and who it is for

This repository is the official mobile client for Rocket.Chat, the self-hostable team chat server. The package name is rocket-chat-reactnative and the current version in package.json is 4.77.0, with the most recent tagged release being 4.76.0 on 2026-08-31. The licence is MIT. The last push to the default develop branch was on 2026-09-28, so the codebase is moving, but the thing you get here is an application, not a service you can point users at.

That framing matters because a lot of people arrive at this repository expecting a chat product. It is not. It is the iOS and Android front end that talks to a Rocket.Chat server you or someone else operates. If you have no server, cloning this gets you a build that has nothing to log into. The audience is therefore narrow and specific: teams already running Rocket.Chat who want the vendor's own mobile experience, and organisations that want to ship a branded mobile client on top of a Rocket.Chat backend. The android-whitelabel script exists precisely for the second group.

The description on the repository reads "The Secure CommsOS™ for mission-critical operations", which is marketing copy rather than a technical claim, and nothing here lets you verify or refute it. Treat it as positioning, not a specification.

How the app is put together: React Native, WatermelonDB and the supported-versions file

The dependency list in package.json tells you most of the architecture. It is a React Native application written in TypeScript, with @nozbe/watermelondb as the local database layer. That is the piece that makes offline reading and queued sending possible: messages live in a local store on the device and sync with the server rather than being fetched fresh on every screen open. @react-native-community/netinfo is present alongside it, which is what a client uses to know when connectivity returns and a sync should be attempted.

The rest of the dependency list is the usual mobile surface area: camera roll access, clipboard, a date picker, a slider, cookies, async storage, vector icons. @bugsnag/react-native handles crash reporting, and the repository ships a bugsnag:upload-android script for uploading Android symbol files. There is a .rnstorybook directory and storybook:start script, so components can be developed in isolation outside the app shell.

One file worth knowing about is app-supportedversions.json at the repository root. The CI call graph shows a fetch-supported-versions action feeding both the Android and iOS build workflows, which means the build process reads that file to decide which server versions the client is expected to work against. If you are running an older Rocket.Chat server, that file is the first place to check before you file a compatibility bug. The README does not explain the file's contents or the compatibility policy behind it, which is a genuine gap.

Installing dependencies and running the app for the first time

The repository uses pnpm, pinned in package.json as [email protected]. There is a postinstall hook that runs patch-package, so dependency installation is expected to apply the patches in the patches/ directory. The README does not contain setup instructions; the commands below are the script names declared in the scripts block of package.json, which is the authoritative source in this repository. They are run through the package manager.

Install dependencies, then start the Metro bundler:

pnpm install
pnpm start

With Metro running, launch a platform target. The android script pins the application id, and the ios script runs the standard React Native build:

pnpm android
pnpm ios

For iOS, CocoaPods are managed through Bundler rather than called directly, which is why the pod-install script is written the way it is:

pnpm pod-install

If you are producing a branded build rather than the stock chat.rocket.android app, the android-whitelabel script accepts an application id as its argument:

pnpm android-whitelabel

What you should see is a login screen pointing at a server address, not a working chat session. The app has no bundled server and no demo mode documented in the repository's README, so the first real use is entering the URL of a Rocket.Chat instance you control and authenticating against it. Until that happens, the app is a shell.

The CI pipeline is the most opinionated part of this repository

The README is not about the app at all. It is a map of the GitHub Actions workflows, and it is unusually detailed for a mobile client. Four entrypoint workflows exist: build-pr.yml on pull_request, build-develop.yml on push to develop, prettier.yml on pushes to most branches, and organize_translations.yml when a locale JSON file changes.

The interesting design decision is the e2e-shards preflight gate. Rather than running the full Maestro end-to-end suite on every pull request, a preflight job decides whether the diff impacts any Maestro flow. If it does, the four E2E workflows (Android and iOS builds, Android and iOS Maestro runs) execute and a required check called e2e-result must pass. If the diff is a confident zero, the entire E2E stage is skipped and no approval is requested. This is a real trade-off: it saves a large amount of CI time on documentation and dependency-bump pull requests, at the cost of a diff-classification step that can be wrong. The README does not describe how the impact analysis is computed or what happens when it misclassifies a change, which is the obvious question to ask before relying on it.

Three manual approval gates are documented. android_build and ios_build fire when the reusable workflows are called with trigger == pr. A separate upload_android environment gate fires after the Android build completes. And approve_e2e_testing fires on a pull request whose diff impacts at least one Maestro flow. Anyone evaluating this project for a fork should note that these gates are configured in GitHub environments, so a self-hosted CI setup will not inherit them.

Where this client is the wrong tool

The clearest limitation is the one stated above: there is no server here. If you want a chat system and not a mobile front end for one, this repository is the wrong starting point entirely. Nothing in the repository suggests a hosted or managed offering bundled with the client.

A second limit is platform. The topics list android, ios, react-native and chat. There is no desktop target and no web target in this repository. The React Native app is the mobile client; if your users live in a browser or on a desktop, this is not the codebase for them.

The third limitation is the shape of the release process. The CI is built around store builds and manual environment approvals, and the version in package.json (4.77.0) is ahead of the most recent tagged release (4.76.0). That is normal for a develop branch, but it means anyone building from develop is building unreleased code. The README documents the workflow triggers but does not document a rollback procedure for a bad store build, and it does not explain how the version bump and tag process works. If you are forking this to ship your own app, you are signing up to reverse-engineer the release process from the workflow files.

Finally, the README's own scope is a limitation for adopters. It answers the question "which workflow runs when" and nothing else: no setup instructions, no architecture notes, no compatibility policy for app-supportedversions.json. The repository has separate CONTRIBUTING.md, AGENTS.md and CLAUDE.md files, so some of that may live elsewhere, but the entry point does not route you there.

How it compares with building your own client or using a web wrapper

The realistic alternative is not another open source mobile chat client. It is wrapping the Rocket.Chat web interface in a WebView shell, or writing a thin native client against the Rocket.Chat API yourself.

The difference in approach is substantial. A WebView wrapper reuses the server's own front end, so it inherits every feature the server ships on the day the server ships it, with no mobile release cycle in between. It also inherits every web-only assumption: no local database, no background sync, no native push integration, and a UI that was not laid out for a phone. Rocket.Chat.ReactNative goes the other way. It maintains a native component tree and a WatermelonDB store, which is why it needs the supported-versions file and why a server upgrade can require a client upgrade. You are trading release coupling for a genuinely native experience.

Writing your own client is the third option and the most expensive. You would be reimplementing the offline store, the sync logic, the push handling, the crash reporting wiring and the store submission pipeline that this repository already has. The MIT licence means you are permitted to fork and modify it instead, which is almost always the cheaper path if you want a custom client.

There is no comparison to make here against a different chat product, because the client only speaks to Rocket.Chat. Swapping backends is not a configuration change in this repository.

Licence, maintenance and the cost of staying current

The licence is MIT, which is permissive and imposes no copyleft obligation on your fork. That said, this is not legal advice and you should read LICENSE yourself, particularly if you plan to ship a modified client to an app store under your own brand. The repository also contains a SECURITY.md and a .snyk configuration with a snyk-protect script, which suggests a security scanning step exists in the project's own process.

On maintenance: the last push to develop was on 2026-09-28, and the release cadence visible in the tags is roughly monthly, with 4.74.0 on 2026-07-01, 4.75.0 on 2026-08-03 and 4.76.0 on 2026-08-31. The project is not archived. The upgrade cost for a fork is the part people underestimate. Because the client reads app-supportedversions.json and the CI gates store builds behind manual approvals, keeping a fork current means merging upstream changes regularly, re-applying anything in the patches/ directory that patch-package manages, and re-running the Maestro suites on both platforms. The e2e-changed script and the e2e-shards preflight exist to make that cheaper, but they only help if your fork retains the same CI structure. A fork that drops the sharding logic pays the full E2E cost on every pull request.

Editorial conclusion

Adopt Rocket.Chat.ReactNative if you already run a Rocket.Chat server and want the vendor's own mobile client, or if you are forking it to ship a whitelabel app under package id chat.rocket.android or a custom --appId. Do not adopt it as a standalone chat product: without a server it has nothing to connect to, and the repository is a client application, not a hosted service. Before you commit, verify the Rocket.Chat server version your deployment runs against the supported versions the build reads from app-supportedversions.json, and confirm whether your release process can absorb the manual approval gates on android_build, ios_build and approve_e2e_testing.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. RocketChat/Rocket.Chat.ReactNative on GitHub