Rock: a plugin-driven React Native toolkit with a remote build cache
Modular toolkit for teams building React Native apps
At a glance
- What is it?
- Rock is Callstack's modular TypeScript toolkit for React Native teams, built around a plugin architecture, a remote build cache for native artifacts and a CLI that migrates Community CLI projects, with brownfield support for adding React Native to an existing app. It suits a team that has outgrown the Community CLI, and it does not suit a new project, for which the documentation itself recommends Expo.
- Who is it for?
- Rock is worth adopting for a React Native team whose builds have got slow and whose tooling has outgrown the Community CLI, because the remote build cache reuses native artifacts across machines and CI, because the plugin architecture means the platform, bundler and cache provider choices are configuration rather than forks, and because the migration path is a single command. It is the wrong choice for a new project, which the documentation itself says should start with Expo.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The plugin architecture is the product, and the cache is the payoff
Rock is a modular toolkit for teams building React Native apps, from Callstack, and the project documentation states the goal plainly: to improve build times and developer experience while fitting into your existing workflows and infrastructure.
The key features are five. The remote build cache reuses native artifacts, and the specific artifacts named are APK, AAB, APP and IPA, across machines and CI, with the claim that it can save up to 96% of build time. Built-in integrations exist for GitHub, S3 and R2, or you can bring your own storage. Brownfield support lets you add React Native to an existing iOS or Android app through the Brownfield plugins. The architecture is plugin-driven, which lets you customise platforms, bundlers, cache providers and more. And the CLI is a familiar one that helps you develop, run and build, with a migration path from Community CLI in minutes.
The order of that list is the argument. A build cache is the feature with a measurable number attached to it, but a cache is only useful if the thing producing the artifacts is configurable, and that is what the plugin architecture is for. The cache provider being a plugin is what lets the same build setup work against GitHub Actions, against S3, or against an internal artifact store, without the build configuration changing.
The other feature worth separating out is the brownfield path. Most React Native tooling assumes the app is a React Native app. Rock Brownfield is for the case where you have a native iOS or Android application and you want React Native inside it, which is a different integration problem with different tooling, and it is shipped as its own plugin set rather than as a flag.
One command creates, migrates or integrates, depending on where you start
The install section branches three ways, and the branching is the point.
For a new project, the readme opens with a caution: for new projects, it recommends starting with Expo, for the best developer experience and similar remote caching capabilities. The reasoning is stated in one clause, that Rock is designed for teams who have outgrown the Community CLI. So the tool's own documentation places it second in the decision order, after Expo for new work.
Given that, the command to create a fresh React Native app with Rock is:
npm create rockMigrating an existing Community CLI project uses the same command, run in the project root. The CLI detects what it is looking at and takes the appropriate path, which is why a single invocation covers both cases and why the migration is described as taking minutes.
The third case is adding React Native to an existing native app, which also starts with npm create rock, and then an interactive prompt asks which plugins you want to start with, offering brownfield-ios and brownfield-android. The prompt in the readme is shown with the two options marked.
That last detail matters for planning. The brownfield path is not a flag you set, it is a set of plugins you opt into, so integrating Rock into an existing native codebase is a piece of work with its own shape. The detailed instructions are on the Integrating with Native Apps page of the documentation site.
The repository is a pnpm workspace with a changesets release pipeline
The tree shows a monorepo with the usual parts of one: apps/ for the applications, packages/ for the published libraries, website/ for the documentation site, templates/ for project templates, scripts/ for tooling, a .changeset/ directory for version management, and a .verdaccio/ directory for a local package registry.
The root package.json is named workspace-root, is private, and uses pnpm as its package manager at version 10.11.0, with pnpm-workspace.yaml and pnpm-lock.yaml in the tree. The scripts are the ones you would expect from a monorepo of this shape. Build runs pnpm -r run build, test is vitest run, e2e is pnpm -r run e2e, lint is eslint ., typecheck is tsc --noEmit, and validate chains typecheck, lint and test together.
Two of the scripts are unusual and worth knowing about. link-packages runs node ./scripts/linkPackages.mjs, which is how the workspace packages get linked locally during development, and watch and dev both run the packages in parallel with --parallel --stream, so you see the output of every package interleaved.
The release machinery is a separate concern from the build. There is a .changeset/ directory and the @changesets/cli in the dev dependencies, and the version and publish scripts are shell scripts rather than npm scripts: ./scripts/changeset-version.sh, ./scripts/npm-publish.sh, and a set of verdaccio scripts for verdaccio-init, verdaccio-publish and verdaccio-reset. That last set is for testing the published packages against a local registry before they go out, which is a sign of a release process that takes packaging seriously.
The tooling is modern and consistent: TypeScript 5.9.2, eslint 9 with the flat config at eslint.config.js, prettier, vitest 3 with the coverage provider, and @clack/prompts for the interactive prompts, which is what the plugin selection prompt in the readme is built with.
Cross-platform means iOS and Android today, and a promise about the rest
The cross-platform-ready feature is worded carefully: iOS and Android by default, and designed to extend to TVs, macOS and Windows, coming soon.
The distinction between default and coming soon is the useful one. Rock is not a cross-platform framework in the sense of compiling your app to a dozen targets. It is a build and development toolkit that currently handles the two mobile platforms and has an architectural plan for the others. A team shipping a console or desktop version alongside a mobile app would be depending on that plan rather than on the code.
The same care shows in the release history. The tags are v0.13.1 from 2026-05-12, v0.14.0 from 2026-07-02 and v0.14.1 from 2026-07-10, with a v0.14.0-latest tag as a rolling build. The last push to the repository was on 2026-10-14, and the repository is not archived.
So the project is being worked on, and the published version line has not moved past 0.14.1 since July. For a toolkit that a team wires into their build pipeline, a version below 1.0 is the thing to factor into the decision, and the fact that there is a rolling latest tag suggests the project expects people to work against the current main rather than only the published versions.
The licence on the root package.json is MIT, and the project documentation says Rock is an open source project and will always remain free to use. The metadata for the repository itself records the licence as not classified, so the root package licence and the licensing of the individual published packages are worth confirming separately if your organisation needs it.
Where Rock is the wrong tool
The first limit is stated by the project itself. For a new project, use Expo. The project documentation recommends it for the best developer experience and for similar remote caching capabilities, and says plainly that Rock is designed for teams who have outgrown the Community CLI. If your problem is that you have never set up a React Native project, this is a tool for the second stage, not the first.
The second limit is what a build cache is worth. The saving depends on reusing native artifacts, and native artifacts are the expensive part of a React Native build. If your builds are fast because your project is small, or if your CI already caches the expensive steps, the 96% figure has nothing to bite on and you have taken on a cache provider, a storage backend and a cache invalidation problem for no gain. The cache also has to be shared between developer machines and CI, which is an infrastructure commitment rather than a configuration change.
The third is the pre-1.0 version line and the gap between the published tag and the branch. A toolkit that replaces your build tooling is not something you pin and forget, and Rock at 0.14.x with a rolling latest tag means your build can change under you in a way your application dependencies would not.
The fourth is the brownfield path specifically. Adding React Native to an existing native app is a substantial integration with its own documentation, and the project documentation routes you to a separate documentation section for it rather than presenting it as a switch. A team with an existing native app is signing up for a project, not a config change.
The fifth is what a plugin architecture costs. The flexibility of customising platforms, bundlers and cache providers is real, and it is also the surface area you own when something in the chain does not do what you expected, because a plugin you can swap is a plugin you can also misconfigure.
Editorial conclusion
Rock is worth adopting for a React Native team whose builds have got slow and whose tooling has outgrown the Community CLI, because the remote build cache reuses native artifacts across machines and CI, because the plugin architecture means the platform, bundler and cache provider choices are configuration rather than forks, and because the migration path is a single command. It is the wrong choice for a new project, which the documentation itself says should start with Expo. Before you adopt it, check the three things the documentation is explicit about: that the cache is where the build-time saving comes from and needs storage and a cache provider set up before it pays off, with built-in integrations for GitHub, S3 and R2 or your own storage; that the platform support is iOS and Android by default with TVs, macOS and Windows marked as coming soon, so do not plan a console release on it; and that brownfield integration ships as separate brownfield-ios and brownfield-android plugins you pick interactively, so the effort of integrating with an existing native project is a separate piece of work from adopting Rock at all.
Frequently asked questions
How do I install Rock for a new or existing React Native project?
Run npm create rock. The same command creates a fresh project, migrates an existing Community CLI project when run in the project root, and adds React Native to an existing native app through the brownfield plugins, where it prompts for which plugins to start with.
What does the Rock remote build cache store and which providers does it support?
The cache reuses native artifacts, named as APK, AAB, APP and IPA, across machines and CI, and the documentation claims a saving of up to 96% of build time. Built-in integrations cover GitHub, S3 and R2, and you can bring your own storage.
Should a new React Native project use Rock?
The project documentation says no. For new projects it recommends starting with Expo for the best developer experience and similar remote caching capabilities, and describes Rock as designed for teams who have outgrown the Community CLI.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/callstackincubator-rock)Was this useful?