#Introduction

Rock is a modular toolkit for teams building React Native apps at scale. It includes a CLI and a Remote Build Cache to speed up builds, adopt React Native incrementally, and keep your stack flexible.

#Who should use Rock

Rock is built for two kinds of teams:

• Existing React Native teams using Community CLI that need more scale: save up to 96% of build time with the Remote Build Cache, and if you need it, structure large apps with microfrontends and super‑app patterns (Re.Pack or Metro Module Federation).
• iOS/Android native teams planning to incorporate React Native without disrupting existing workflows: Rock Brownfield lets you add your whole React Native app like any other dependency.

Both types of teams will benefit from Rock's cross‑platform reach: iOS and Android by default, with a flexible architecture that extends to TVs, macOS, Windows, and HarmonyOS (coming soon).

#Why We Exist

On a daily basis at Callstack, we're serving clients that usually have large teams, building complex apps for years, accumulating tech debt, becoming slower and slower to iterate, where time is wasted on waiting for builds and onboarding web engineers into intricacies of mobile platforms. According to the React Native Framework RFC, almost all of these companies are building their own frameworks based on the Community CLI—they just don't open source them to make them available for everyone, and for good reasons.

As maintainers of the Community CLI, we have quite the exposure to how this tool is used (and misused) in various projects. When we evaluated how our clients use it and what our developers are challenged with, we noticed that these companies encounter similar challenges that they address uniquely:

• High build times with no reuse across CI jobs and dev team
• Months just to integrate a third-party cloud vendor
• A mixed tech stack that makes adding React Native quite a challenge

We also have clients who:

• Ship their products to 10+ platforms
• Have brownfield setups, embedding React Native in their native apps

Using anything other than the Community CLI is not an option for them currently.

We exist to serve all these needs.

#Our Principles

We build the framework with a clear focus: to serve large teams and complex apps. These projects require flexibility, the ability to host everything on their own, deploy to as many platforms as possible, and decrease onboarding time. That's why our engineering design choices focus on:

• Modular design—add your supported platforms and plugins, and integrate existing tools; you can build around our framework
• Self-hosting—use your own infrastructure without relying on third-party cloud vendors; whether you're using GitHub Actions or Amazon S3 and BitBucket, we got you covered.
• Incremental adoption—easily migrate from Community CLI or an existing native app.

#The CLI

We've created a new CLI from scratch with a focus on seamless migration from the Community CLI. Most projects can replace their local build and run experience with our CLI in under 10 minutes.

Its core part is modular configuration mechanism allowing for customizing the capabilities to your needs through a system of plugins and replaceable parts of the build chain, such as: bundler, platforms, remote cache provider, or helpers exposed through variety of npm packages.

#Key Features

The CLI handles all essential build and deployment tasks:

• Building and running APK/APP files on devices and simulators
• Creating builds for different variants and configurations
• Generating signed IPA and AAB archives for app stores
• Re-signing archives with fresh JS bundles
• Generating native project hashes for caching

#Command Changes from Community CLI

We've updated command names:

• run-android → run:android
• build-android → build:android
• run-ios → run:ios
• build-ios → build:ios

For a complete list of new commands, visit the CLI page.

#Flag Changes

We've standardized flag naming across platforms:

Android:

• --mode → --variant
• --appId → --app-id
• --appIdSuffix → --app-id-suffix

iOS:

• --mode → --configuration
• --buildFolder → --build-folder

#Removed Flags

We've simplified the interface by removing redundant flags:

• --interactive/-i – CLI now prompts for input when needed
• --list-devices – Device selection is now automatic when no devices are connected

#The Remote Cache

The Remote Cache is an optional but powerful feature that speeds up your development workflow. It acts as a centralized storage for native app builds that can be retrieved either manually or through our CLI. The cache can be hosted on various platforms:

• GitHub Actions
• Amazon S3
• Cloudflare R2
• Custom providers

#How It Works

1. For each build, we calculate a unique hash (fingerprint) that represents your project's native state
2. This hash remains stable across builds unless you:
   • Modify native files
   • Change dependencies with native code
   • Update scripts in package.json
3. When you make JavaScript-only changes, the hash stays the same
4. The CLI checks for matching builds in:
   • Local cache (.rock/ directory)
   • Remote storage
   • Falls back to local build if no match is found

#GitHub Actions Integration

We provide a set of reusable GitHub Actions that handle:

• Build hash calculation
• iOS/Android builds for:
  • Developers (simulator/emulator builds – APK, APP)
  • Testers (device builds – APK, IPA)
• Artifact management (upload/download)
• Code signing:
  • iOS: certificates and provisioning profiles (IPA)
  • Android: keystore (AAB)
• Automatic re-signing of builds with fresh JS bundles on PR updates

Learn more about GitHub Actions configuration.

Need React or React Native expertise you can count on?

Let's talkLet's talk