diff --git a/.github/workflows/CI.yaml b/.github/workflows/CI.yaml
new file mode 100644
index 000000000..9a40957e3
--- /dev/null
+++ b/.github/workflows/CI.yaml
@@ -0,0 +1,42 @@
+name: CI
+
+on:
+ pull_request:
+ branches: [master]
+
+# Least privilege: CI only reads the repository contents.
+permissions:
+ contents: read
+
+# Cancel superseded runs when a PR is updated, to save CI minutes.
+concurrency:
+ group: ci-${{ github.workflow }}-${{ github.ref }}
+ cancel-in-progress: true
+
+jobs:
+ # Required status check for merging into master (branch protection matches
+ # on the job name "check").
+ check:
+ name: check
+ runs-on: ubuntu-latest
+ timeout-minutes: 15
+ steps:
+ - name: Checkout
+ uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+ with:
+ persist-credentials: false
+
+ - name: Setup Node.js
+ uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
+ with:
+ node-version: 20.19.0
+ cache: npm
+
+ - name: Install dependencies
+ run: npm ci
+
+ - name: Lint
+ run: npm run tslint
+
+ - name: Build
+ run: npm run build:tests
diff --git a/README.md b/README.md
index e3fa7c564..36cff66d1 100644
--- a/README.md
+++ b/README.md
@@ -1,407 +1,349 @@
-#### [Sign up With Revopush](https://app.revopush.org/register) to use CodePush SDK
+# Revopush React Native SDK
-# React Native SDK for Revopush (CodePush compatible service)
+
-This plugin provides client-side integration for the [CodePush service](https://revopush.org/), allowing you to easily add a dynamic update experience to your React Native app(s).
+### Next-generation OTA updates for React Native and Expo
-
+[Revopush](https://revopush.org/) delivers JavaScript and asset updates directly to your users without waiting for a new App Store or Google Play release. Revopush 2.x replaces full-bundle downloads with automatic byte-level diffs, while keeping the familiar CodePush API and workflows.
-* [How does it work?](#how-does-it-work)
-* [Supported React Native Platforms](#supported-react-native-platforms)
-* [Supported Components](#supported-components)
-* [Getting Started](#getting-started)
- * [iOS Setup](docs/setup-ios.md)
- * [Android Setup](docs/setup-android.md)
-* [Plugin Usage](#plugin-usage)
-* [Releasing Updates](#releasing-updates)
-* [Migrate from Appcenter to Revopush](#migrate-from-appcenter)
-* [Continuous Integration / Delivery](#continuous-integration--delivery)
-* [Multi-Deployment Testing](#multi-deployment-testing)
- * [Android](docs/multi-deployment-testing-android.md)
- * [iOS](docs/multi-deployment-testing-ios.md)
-* [Dynamic Deployment Assignment](#dynamic-deployment-assignment)
-* [API Reference](#api-reference)
- * [JavaScript API](docs/api-js.md)
- * [Objective-C API Reference (iOS)](docs/api-ios.md)
- * [Java API Reference (Android)](docs/api-android.md)
-* [Store Guideline Compliance](#store-guideline-compliance)
-* [Debugging / Troubleshooting](#debugging--troubleshooting)
-* [TypeScript Consumption](#typescript-consumption)
+| **100x smaller payloads** | **Diffs from the first OTA** | **CodePush compatible** |
+|---|---|---|
+| Download only what changed. Actual savings depend on the update. | Create a native base release and the first OTA on top of it can already be a diff. | Migrate existing apps without rebuilding your release workflow from scratch. |
-
+[Dashboard](https://app.revopush.org) · [Documentation](https://docs.revopush.org/) · [How binary diff updates work](https://revopush.org/react-native-ota-payloads-binary-diffs)
-## How does it work?
+## Proven at global scale
-A React Native app is composed of JavaScript files and any accompanying [images](https://reactnative.dev/docs/image), which are bundled together by the [metro bundler](https://github.com/facebook/metro) and distributed as part of a platform-specific binary (i.e. an `.ipa` or `.apk` file). Once the app is released, updating either the JavaScript code (e.g. making bug fixes, adding new features) or image assets, requires you to recompile and redistribute the entire binary, which of course, includes any review time associated with the store(s) you are publishing to.
+| **1B+ requests processed** | **300M+ SDK installations** | **99.9% historical SLA** | **SOC 2 compliant** |
+|---|---|---|---|
+| Production traffic handled by the Revopush platform. | A mature delivery footprint across real-world applications. | A consistent track record of service availability. | Independently assessed security controls for production workloads. |
-The CodePush plugin helps get product improvements in front of your end users instantly, by keeping your JavaScript and images synchronized with updates you release to the CodePush server. This way, your app gets the benefits of an offline mobile experience, as well as the "web-like" agility of side-loading updates as soon as they are available. It's a win-win!
+Revopush runs on a geo-distributed architecture designed to deliver releases with low latency in every region, so teams can ship updates quickly to users anywhere in the world.
-In order to ensure that your end users always have a functioning version of your app, the CodePush plugin maintains a copy of the previous update, so that in the event that you accidentally push an update which includes a crash, it can automatically roll back. This way, you can rest assured that your newfound release agility won't result in users becoming blocked before you have a chance to roll back on the server. It's a win-win-win!
+## Contents
-*Note: Any product changes which touch native code (e.g. modifying your `AppDelegate.m`/`MainActivity.java` file, adding a new plugin) cannot be distributed via CodePush, and therefore, must be updated via the appropriate store(s).*
+- [Proven at global scale](#proven-at-global-scale)
+- [What is Revopush?](#what-is-revopush)
+- [How it works](#how-it-works)
+- [Supported versions](#supported-versions)
+- [Getting Started](#getting-started)
+ - [Set up with an AI agent](#set-up-with-an-ai-agent)
+ - [Manual React Native setup](#manual-react-native-setup)
+- [Expo Support](#expo-support)
+- [Plugin Usage](#plugin-usage)
+- [Releasing Updates](#releasing-updates)
+- [Advanced Workflows](#advanced-workflows)
+- [API Reference](#api-reference)
+- [Store Guideline Compliance](#store-guideline-compliance)
+- [Troubleshooting](#troubleshooting)
-## Supported React Native platforms
+## What is Revopush?
-- iOS (7+)
-- Android (4.1+) on TLS 1.2 compatible devices
+Revopush is a hosted OTA platform for React Native and Expo. It combines a dashboard, CLI, global delivery service, and client SDK so teams can publish, target, monitor, promote, and roll back JavaScript and asset updates.
-We try our best to maintain backwards compatibility of our plugin with previous versions of React Native, but due to the nature of the platform, and the existence of breaking changes between releases, it is possible that you need to use a specific version of the CodePush plugin in order to support the exact version of React Native you are using. The following table outlines which CodePush plugin versions officially support the respective React Native versions:
+- Compatible with the CodePush JavaScript API and established deployment workflows
+- Supports modern React Native, including the New Architecture
+- Supports Expo projects through the official config plugin
+- Includes rollback controls for reverting a problematic release
+- Provides extended analytics by individual release and across the entire application
+- Supports percentage-based rollouts, from a controlled user cohort to 100%
+- Integrates with popular CI/CD platforms including GitHub Actions, Bitrise, and CircleCI
+- Supports multiple deployments and code signing
-| React Native version(s) | Supporting CodePush version(s) |
-|-------------------------|------------------------------------------------------------------------------------------------------|
-| *(Requires [react-native-maps](https://github.com/lelandrichardson/react-native-maps) `>=O.3.2`)* | `image` |
-| `ProgressViewIOS` | `progressImage`, `trackImage` |
-| `TabBarIOS.Item` | `icon`, `selectedIcon` |
-| `ToolbarAndroid`
*(React Native 0.21.0+)* | `actions[].icon`, `logo`, `overflowIcon` |
-| `Video` | `source` |
+## Supported versions
-The following list represents the set of components (and props) that don't currently support their assets being updated via CodePush, due to their dependency on static images and videos (i.e. using the `{ uri: "foo" }` syntax):
+Use the Revopush 2.x SDK for all new integrations:
-| Component | Prop(s) |
-|-------------|----------------------------------------------------------------------|
-| `SliderIOS` | `maximumTrackImage`, `minimumTrackImage`, `thumbImage`, `trackImage` |
-| `Video` | `source` |
-
-As new core components are released, which support referencing assets, we'll update this list to ensure users know what exactly they can expect to update using CodePush.
-
-*Note: CodePush only works with Video components when using `require` in the source prop. For example:*
-
-```javascript
-
-```
+| Project | Supported version | Revopush SDK |
+|---|---:|---:|
+| React Native | `< 0.76` | Not supported; upgrade React Native or use the [legacy Microsoft client](https://github.com/microsoft/react-native-code-push) |
+| React Native | `0.76–0.82` | `@revopush/react-native-code-push@2.5.1` |
+| React Native | `0.83+` | `@revopush/react-native-code-push@2.6.x` |
+| Expo | `52–54` | SDK `2.5.1` + Expo plugin `1.0.1` |
+| Expo | `55+` | SDK `2.6.0` + Expo plugin `1.1.0` |
## Getting Started
-After you've created an account on [Revopush](https://app.revopush.org/register), you can start CodePush-ifying your React Native app by running the following command from within your app's root directory:
+### Set up with an AI agent
-```shell
-npm install --save @revopush/react-native-code-push
-```
-
-As with all other React Native plugins, the integration experience is different for iOS and Android, so perform the following setup steps depending on which platform(s) you are targeting. Note, if you are targeting both platforms it is recommended to create separate CodePush applications for each platform.
+The fastest way to integrate Revopush is with the official [Revopush agent skills](https://github.com/revopush/skills). They help an AI coding agent detect your project type and apply the React Native or Expo integration.
-*NOTE: This guide assumes you have used the `@react-native-community/cli init` command to initialize your React Native project.*
+For Codex, Cursor, Gemini CLI, and other agents that support the portable skills format:
-Then continue with installing the native module
- * [iOS Setup](docs/setup-ios.md)
- * [Android Setup](docs/setup-android.md)
-
-## Plugin Usage
+```bash
+npx skills@latest add revopush/skills
+```
-With the CodePush plugin downloaded and linked, and your app asking CodePush where to get the right JS bundle from, the only thing left is to add the necessary code to your app to control the following policies:
+For Claude Code:
-1. When (and how often) to check for an update? (for example app start, in response to clicking a button in a settings page, periodically at some fixed interval)
+```text
+/plugin marketplace add revopush/skills
+/plugin install revopush
+```
-2. When an update is available, how to present it to the end user?
+Then ask your agent:
-The simplest way to do this is to "CodePush-ify" your app's root component. To do so, you can choose one of the following two options:
+> Set up Revopush OTA updates in my React Native app. Detect my React Native or Expo version, install the compatible Revopush 2.x SDK, configure iOS and Android, wrap the root component with `codePush()`, and use deployment key placeholders that I can replace.
-* **Option 1: Wrap your root component with the `codePush` higher-order component:**
+The agent configures the codebase, but you still need to [create a Revopush account](https://app.revopush.org/register), create your applications and deployments, and provide the iOS and Android deployment keys from the dashboard.
- * For class component
+### Manual React Native setup
- ```javascript
- import codePush from "@revopush/react-native-code-push";
+1. [Create an account](https://app.revopush.org/register), then create separate applications for iOS and Android. Each application includes Staging and Production deployments with their own keys.
+2. Install the SDK version that matches your React Native version:
- class MyApp extends Component {
- }
+ ```bash
+ # React Native 0.76–0.82
+ npm install --save @revopush/react-native-code-push@2.5.1
- MyApp = codePush(MyApp);
- ```
+ # React Native 0.83+
+ npm install --save @revopush/react-native-code-push@2.6.0
+ ```
- * For functional component
+3. Complete the native setup for [iOS](docs/setup-ios.md) and [Android](docs/setup-android.md). Use `https://api.revopush.org` as the server URL and configure a different deployment key for each platform.
+4. Wrap your root component with `codePush()` as shown in [Plugin Usage](#plugin-usage).
+5. Install the [Revopush CLI](#releasing-updates) and publish a test update from a release build.
- ```javascript
- import codePush from "@revopush/react-native-code-push";
+For the current end-to-end flow and modern native templates, see the [full setup guide](https://docs.revopush.org/intro/getting-started).
- let MyApp: () => React$Node = () => {
- }
+## Expo Support
- MyApp = codePush(MyApp);
- ```
+Revopush supports Expo SDK 52 and newer through the official [`@revopush/expo-code-push-plugin`](https://github.com/revopush/expo-code-push-plugin). The plugin applies the required native changes during prebuild.
-* **Option 2: Use the [ES7 decorator](https://github.com/wycats/javascript-decorators) syntax:**
+Revopush does **not** work in Expo Go because it requires native code. Use a development/native build, EAS Build, or your own native build pipeline.
- *NOTE: Decorators are not yet supported in Babel 6.x pending proposal update.* You may need to enable it by installing and using [babel-preset-react-native-stage-0](https://github.com/skevy/babel-preset-react-native-stage-0#babel-preset-react-native-stage-0).
+Install the SDK and config plugin as a matched pair:
- * For class component
+```bash
+# Expo SDK 52–54
+npx expo install @revopush/react-native-code-push@2.5.1 @revopush/expo-code-push-plugin@1.0.1
- ```javascript
- import codePush from "@revopush/react-native-code-push";
+# Expo SDK 55+
+npx expo install @revopush/react-native-code-push@2.6.0 @revopush/expo-code-push-plugin@1.1.0
+```
- @codePush
- class MyApp extends Component {
+Add the plugin to the `plugins` array in `app.json` or `app.config.js`:
+
+```json
+[
+ "@revopush/expo-code-push-plugin",
+ {
+ "ios": {
+ "CodePushDeploymentKey": "YOUR_IOS_DEPLOYMENT_KEY",
+ "CodePushServerUrl": "https://api.revopush.org"
+ },
+ "android": {
+ "CodePushDeploymentKey": "YOUR_ANDROID_DEPLOYMENT_KEY",
+ "CodePushServerUrl": "https://api.revopush.org"
}
- ```
+ }
+]
+```
- * For functional component
+Generate the native projects:
- ```javascript
- import codePush from "@revopush/react-native-code-push";
+```bash
+npx expo prebuild --clean
+```
- const MyApp: () => React$Node = () => {
- }
+Wrap the Expo Router root layout in `app/_layout.tsx`:
- export default codePush(MyApp);
- ```
+```tsx
+import codePush from "@revopush/react-native-code-push";
-By default, CodePush will check for updates on every app start. If an update is available, it will be silently downloaded, and installed the next time the app is restarted (either explicitly by the end user or by the OS), which ensures the least invasive experience for your end users. If an available update is mandatory, then it will be installed immediately, ensuring that the end user gets it as soon as possible.
+function RootLayout() {
+ // ...
+}
-If you would like your app to discover updates more quickly, you can also choose to sync up with the CodePush server every time the app resumes from the background.
+export default codePush(RootLayout);
+```
-* For class component
+Deployment keys are written into the native projects during prebuild. Run `npx expo prebuild --clean` again whenever you change the Revopush plugin configuration. See the [complete Expo guide](https://docs.revopush.org/intro/expo) for release builds, iOS deployment targets, and troubleshooting.
- ```javascript
- let codePushOptions = { checkFrequency: codePush.CheckFrequency.ON_APP_RESUME };
+## Plugin Usage
- class MyApp extends Component {
- }
+For most apps, wrap the root component with the `codePush()` higher-order component:
- MyApp = codePush(codePushOptions)(MyApp);
- ```
+```tsx
+import codePush from "@revopush/react-native-code-push";
-* For functional component
+function App() {
+ // ...
+}
- ```javascript
- let codePushOptions = { checkFrequency: codePush.CheckFrequency.ON_APP_RESUME };
+export default codePush(App);
+```
- let MyApp: () => React$Node = () => {
- }
+By default, the SDK checks on app start, downloads an available update silently, and installs non-mandatory updates on the next restart. Mandatory updates use the immediate install mode by default.
- MyApp = codePush(codePushOptions)(MyApp);
- ```
+For a custom update UI or schedule, switch to manual checks and call `sync()` yourself:
-Alternatively, if you want fine-grained control over when the check happens (like a button press or timer interval), you can call [`CodePush.sync()`](docs/api-js.md#codepushsync) at any time with your desired `SyncOptions`, and optionally turn off CodePush's automatic checking by specifying a manual `checkFrequency`:
+```tsx
+import codePush from "@revopush/react-native-code-push";
-```javascript
-let codePushOptions = { checkFrequency: codePush.CheckFrequency.MANUAL };
+const options = {
+ checkFrequency: codePush.CheckFrequency.MANUAL,
+};
-class MyApp extends Component {
- onButtonPress() {
- codePush.sync({
- updateDialog: true,
- installMode: codePush.InstallMode.IMMEDIATE
- });
- }
+async function checkForUpdates() {
+ await codePush.sync({
+ installMode: codePush.InstallMode.ON_NEXT_RESTART,
+ });
+}
- render() {
- return (
-
-
- Check for updates
-
-
- )
- }
+function App() {
+ // Call checkForUpdates() from your own UI or lifecycle logic.
}
-MyApp = codePush(codePushOptions)(MyApp);
+export default codePush(options)(App);
```
-If you would like to display an update confirmation dialog (an "active install"), configure when an available update is installed (like force an immediate restart) or customize the update experience in any other way, refer to the [`codePush()`](docs/api-js.md#codepush) API reference for information on how to tweak this default behavior.
-
-*NOTE: If you are using [Redux](http://redux.js.org) and [Redux Saga](https://redux-saga.js.org/), you can alternatively use the [react-native-code-push-saga](http://github.com/lostintangent/react-native-code-push-saga) module, which allows you to customize when `sync` is called in a perhaps simpler/more idiomatic way.*
+See the [JavaScript API reference](docs/api-js.md) for update dialogs, progress callbacks, install modes, `checkForUpdate()`, and fully manual update handling.
## Releasing Updates
-Once your app is configured and distributed to your users, and you have made some JS or asset changes, it's time to release them. The recommended way to release them is using the `release-react` command in the App Center CLI, which will bundle your JavaScript files, asset files, and release the update to the CodePush server.
+Install the current Revopush CLI and authenticate:
-```shell
+```bash
npm install -g @revopush/code-push-cli
+revopush login
+revopush -v
```
-*NOTE: Before you can start releasing updates, please log into Revopush by running the `revopush login` command.*
+### Enable diffs from the first OTA
-In its most basic form, this command only requires application name and platform (ios/android) .
+For each store binary that should serve as a diff baseline, create a native base release from its IPA, APK, or AAB:
-```shell
-revopush release-react
-revopush release-react MyApp android -d Production
-release-react MyApp ios
+```bash
+revopush release-native ios ./path/to/app.ipa
+revopush release-native android ./path/to/app.apk
+revopush release-native android ./path/to/app.aab
```
-The `release-react` command enables such a simple workflow because it provides many sensible defaults (like generating a release bundle, assuming your app's entry file on iOS is either `index.ios.js` or `index.js`). However, all of these defaults can be customized to allow incremental flexibility as necessary, which makes it a good fit for most scenarios.
-
-```shell
-# Release a mandatory update with a changelog
-revopush release-react MyApp ios -m --description "Modified the header color"
-
-# Release an update for an app that uses a non-standard entry file name, and also capture
-# the sourcemap file generated by react-native bundle
-revopush release-react MyApp ios --entry-file MyApp.js --sourcemapOutput ../maps/MyApp.map
+The base release is a snapshot of the JavaScript and assets shipped in that binary. After it exists, publish regular updates as usual:
-# Release a dev Android build to just 1/4 of your end users
-revopush release-react MyApp android --rollout 25 --development true
+```bash
+# Bare React Native
+revopush release-react ios -d Staging
+revopush release-react android -d Staging
-# Release an update that targets users running any 1.1.* binary, as opposed to
-# limiting the update to exact version name in the build.gradle file
-revopush release-react MyApp android --targetBinaryVersion "~1.1.0"
+# Expo
+revopush release-expo ios -d Staging
+revopush release-expo android -d Staging
```
-The CodePush client supports differential updates, so even though you are releasing your JS bundle and assets on every update, your end users will only actually download the files they need. The service handles this automatically so that you can focus on creating awesome apps, and we can worry about optimizing end user downloads.
+Diff generation is automatic on the 2.x SDK line. Revopush generates the best compatible patch for each client and falls back to a full update when required.
-For more details about how the `release-react` command works, as well as the various parameters it exposes, refer to the [CLI docs](https://github.com/revopush/code-push-cli/blob/main/README.md). Additionally, if you would prefer to handle running the `react-native bundle` command yourself, and therefore, want an even more flexible solution than `release-react`, refer to the [`release` command](https://github.com/microsoft/code-push/tree/v3.0.1/cli#releasing-updates-general) for more details.
+Useful release options include:
-If you run into any issues, or have any questions/comments/feedback, [e-mail us](mailto:support@revopush.org) and/or check out the [troubleshooting](#debugging--troubleshooting) details below.
+```bash
+# Mandatory update with release notes
+revopush release-react MyApp ios -d Staging -m --description "Fix checkout crash"
-*NOTE: CodePush updates should be tested in modes other than Debug mode. In Debug mode, React Native app always downloads JS bundle generated by packager, so JS bundle downloaded by CodePush does not apply.*
+# Gradual rollout to 25% of users
+revopush release-react MyApp android -d Production -r 25
-### Migrate from Appcenter to Revopush
-
-Follow our [comprehensive guide](https://github.com/revopush/code-push-cli/blob/main/README.md) that will help you migrate your applications from App Center.
-
-### Continuous Integration / Delivery
-
-In addition to being able to use the CodePush CLI to "manually" release updates, we believe that it's important to create a repeatable and sustainable solution for continuously delivering updates to your app.
-That way, it's simple enough for you and/or your team to create and maintain the rhythm of performing agile deployments.
-In order to assist with setting up a CodePush-based CD pipeline, refer to the following integrations with various CI servers:
-
-* [Github Actions](https://github.com/revopush/revopush-github-action) - supports all the commands available in the Revopush CLI of appropriate version
-* [Bitrise Step](https://github.com/revopush/bitrise-steplib)
-* [Circle CI Orb](https://github.com/revopush/revopush-circleci-orb)
-
-Additionally, if you'd like more integrations, please message us at [support@revopush.org](mailto:support@revopush.org)
-
-### Multi-Deployment Testing
-
-In our [getting started](#getting-started) docs, we illustrated how to configure the CodePush plugin using a specific deployment key. However, in order to effectively test your releases, it is critical that you leverage the `Staging` and `Production` deployments that are auto-generated when you first created your CodePush app (or any custom deployments you may have created). This way, you never release an update to your end users that you haven't been able to validate yourself.
-
-*NOTE: Our client-side rollback feature can help unblock users after installing a release that resulted in a crash, and server-side rollbacks (i.e. `revopush rollback`) allow you to prevent additional users from installing a bad release once it's been identified. However, it's obviously better if you can prevent an erroneous update from being broadly released in the first place.*
+# Target compatible 1.2.x store binaries
+revopush release-react MyApp android -d Staging -t "~1.2.0"
+```
-Taking advantage of the `Staging` and `Production` deployments allows you to achieve a workflow like the following (feel free to customize!):
+Read the [Revopush CLI documentation](https://docs.revopush.org/cli/getting-started) for more CLI workflows and commands.
-1. Release a CodePush update to your `Staging` deployment using the `revopush release-react` command (or `revopush release` if you need more control)
+> Test OTA delivery in a release build. Debug builds load JavaScript from Metro and do not apply the downloaded OTA bundle.
-2. Run your staging/beta build of your app, sync the update from the server, and verify it works as expected
+## Advanced Workflows
-3. Promote the tested release from `Staging` to `Production` using the `revopush promote` command
+### Staging, promotion, and rollback
-4. Run your production/release build of your app, sync the update from the server and verify it works as expected
+Each application includes Staging and Production deployments. A typical production flow is:
-*NOTE: If you want to take a more cautious approach, you can even choose to perform a "staged rollout" as part of #3, which allows you to mitigate additional potential risk with the update (like did your testing in #2 touch all possible devices/conditions?) by only making the production update available to a percentage of your users (for example `revopush promote Staging Production -r 20`). Then, after waiting for a reasonable amount of time to see if any crash reports or customer feedback comes in, you can expand it to your entire audience by running `revopush patch Production -r 100`.*
+1. Publish to Staging with `revopush release-react` or `revopush release-expo`.
+2. Install the update in a staging/release build and verify it on real devices.
+3. Promote the tested release without rebuilding it:
-You'll notice that the above steps refer to a "staging build" and "production build" of your app. If your build process already generates distinct binaries per "environment", then you don't need to read any further, since swapping out CodePush deployment keys is just like handling environment-specific config for any other service your app uses (like Facebook). However, if you're looking for examples (**including demo projects**) on how to setup your build process to accommodate this, then refer to the following sections, depending on the platform(s) your app is targeting:
+ ```bash
+ revopush promote Staging Production
+ revopush promote Staging Production -r 25 --des "gradual rollout"
+ ```
- * [Android](docs/multi-deployment-testing-android.md)
- * [iOS](docs/multi-deployment-testing-ios.md)
+4. If necessary, roll Production back:
+ ```bash
+ revopush rollback Production
+ revopush rollback Production -r v4
+ ```
-### Dynamic Deployment Assignment
+Use separate applications and deployment keys for iOS and Android so releases cannot cross platforms.
-The above section illustrated how you can leverage multiple CodePush deployments in order to effectively test your updates before broadly releasing them to your end users. However, since that workflow statically embeds the deployment assignment into the actual binary, a staging or production build will only ever sync updates from that deployment. In many cases, this is sufficient, since you only want your team, customers, stakeholders, etc. to sync with your pre-production releases, and therefore, only they need a build that knows how to sync with staging. However, if you want to be able to perform A/B tests, or provide early access of your app to certain users, it can prove very useful to be able to dynamically place specific users (or audiences) into specific deployments at runtime.
+### Dynamic deployment assignment
-In order to achieve this kind of workflow, all you need to do is specify the deployment key you want the current user to syncronize with when calling the `codePush` method. When specified, this key will override the "default" one that was provided in your app's `Info.plist` (iOS) or `MainActivity.java` (Android) files. This allows you to produce a build for staging or production, that is also capable of being dynamically "redirected" as needed.
+You can override the deployment embedded in the binary at runtime. This is useful for beta groups, internal testers, or controlled experiments:
-```javascript
-// Imagine that "userProfile" is a prop that this component received
-// which includes the deployment key that the current user should use.
-codePush.sync({ deploymentKey: userProfile.CODEPUSH_KEY });
+```tsx
+codePush.sync({ deploymentKey: userProfile.codePushDeploymentKey });
```
-With that change in place, now it's just a matter of choosing how your app determines the right deployment key for the current user. In practice, there are typically two solutions for this:
-
-1. Expose a user-visible mechanism for changing deployments at any time. For example, your settings page could have a toggle for enabling "beta" access. This model works well if you're not concerned with the privacy of your pre-production updates, and you have power users that may want to opt-in to earlier (and potentially buggy) updates at their own will (kind of like Chrome channels). However, this solution puts the decision in the hands of your users, which doesn't help you perform A/B tests transparently.
-
-2. Annotate the server-side profile of your users with an additional piece of metadata that indicates the deployment they should sync with. By default, your app could just use the binary-embedded key, but after a user has authenticated, your server can choose to "redirect" them to a different deployment, which allows you to incrementally place certain users or groups in different deployments as needed. You could even choose to store the server-response in local storage so that it becomes the new default. How you store the key alongside your user's profiles is entirely up to your authentication solution (for example Auth0, Firebase, custom DB + REST API), but is generally pretty trivial to do.
-
-*NOTE: If needed, you could also implement a hybrid solution that allowed your end-users to toggle between different deployments, while also allowing your server to override that decision. This way, you have a hierarchy of "deployment resolution" that ensures your app has the ability to update itself out-of-the-box, your end users can feel rewarded by getting early access to bits, but you also have the ability to run A/B tests on your users as needed.*
+Create a custom deployment and target releases to it:
-Since we recommend using the `Staging` deployment for pre-release testing of your updates (as explained in the previous section), it doesn't necessarily make sense to use it for performing A/B tests on your users, as opposed to allowing early-access (as explained in option #1 above). Therefore, we recommend making full use of custom app deployments, so that you can segment your users however makes sense for your needs. For example, you could create long-term or even one-off deployments, release a variant of your app to it, and then place certain users into it in order to see how they engage.
-
-```javascript
-// #1) Create your new deployment to hold releases of a specific app variant
-revopush deployment add MyApp test-variant-one
-
-// #2) Target any new releases at that custom deployment
-revopush release-react MyApp android -d test-variant-one
+```bash
+revopush deployment add MyApp beta
+revopush release-react MyApp android -d beta
```
-*NOTE: The total user count that is reported in your deployment's "Install Metrics" will take into account users that have "switched" from one deployment to another. For example, if your `Production` deployment currently reports having 1 total user, but you dynamically switch that user to `Staging`, then the `Production` deployment would report 0 total users, while `Staging` would report 1 (the user that just switched). This behavior allows you to accurately track your release adoption, even in the event of using a runtime-based deployment redirection solution.*
+Treat deployment keys as routing identifiers. Keep authorization and audience eligibility in your own backend or application logic.
----
+### CI/CD
-## API Reference
+Revopush can be added to an existing release pipeline with:
-* [JavaScript API](docs/api-js.md)
-* [Objective-C API Reference (iOS)](docs/api-ios.md)
-* [Java API Reference (Android)](docs/api-android.md)
+- [GitHub Actions](https://github.com/revopush/revopush-github-action)
+- [Bitrise](https://github.com/revopush/bitrise-steplib)
+- [CircleCI](https://github.com/revopush/revopush-circleci-orb)
-### Store Guideline Compliance
+### Migrating from App Center
-Android Google Play and iOS App Store have corresponding guidelines that have rules you should be aware of before integrating the CodePush solution within your application.
+Existing CodePush applications can keep the familiar client API and deployment model. Follow the [App Center migration guide](https://docs.revopush.org/migration/guide) to move applications, deployments, and release automation to Revopush.
-#### Google play
-
-Third paragraph of [Device and Network Abuse](https://support.google.com/googleplay/android-developer/answer/9888379?hl=en) topic describe that updating source code by any method other than Google Play's update mechanism is restricted. But this restriction does not apply to updating javascript bundles.
-> This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs (such as JavaScript in a webview or browser).
-
-That fully allow CodePush as it updates just JS bundles and can't update native code part.
-
-#### App Store
-
-Paragraph **3.3.2**, since back in 2015's [Apple Developer Program License Agreement](https://developer.apple.com/programs/ios/information/) fully allowed performing over-the-air updates of JavaScript and assets - and in its latest version (20170605) [downloadable here](https://developer.apple.com/terms/) this ruling is even broader:
-
-> Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store, (b) does not create a store or storefront for other code or applications, and (c) does not bypass signing, sandbox, or other security features of the OS.
-
-CodePush allows you to follow these rules in full compliance so long as the update you push does not significantly deviate your product from its original App Store approved intent.
-
-To further remain in compliance with Apple's guidelines we suggest that App Store-distributed apps don't enable the `updateDialog` option when calling `sync`, since in the [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) it is written that:
-
-> Apps must not force users to rate the app, review the app, download other apps, or other similar actions in order to access functionality, content, or use of the app.
-
-This is not necessarily the case for `updateDialog`, since it won't force the user to download the new version, but at least you should be aware of that ruling if you decide to show it.
-
-### Debugging / Troubleshooting
-
-The `sync` method includes a lot of diagnostic logging out-of-the-box, so if you're encountering an issue when using it, the best thing to try first is examining the output logs of your app. This will tell you whether the app is configured correctly (like can the plugin find your deployment key?), if the app is able to reach the server, if an available update is being discovered, if the update is being successfully downloaded/installed, etc. We want to continue improving the logging to be as intuitive/comprehensive as possible, so please [let us know](mailto:support@revopush.org) if you find it to be confusing or missing anything.
-
-The simplest way to view these logs is to add the flag `--debug` for each command. This will output a log stream that is filtered to just CodePush messages. This makes it easy to identify issues, without needing to use a platform-specific tool, or wade through a potentially high volume of logs.
-
-
+## API Reference
-Additionally, you can also use any of the platform-specific tools to view the CodePush logs, if you are more comfortable with them. Simple start up the Chrome DevTools Console, the Xcode Console (iOS), the [OS X Console](https://en.wikipedia.org/wiki/Console_%28OS_X%29#.7E.2FLibrary.2FLogs) (iOS) and/or ADB logcat (Android), and look for messages which are prefixed with `[CodePush]`.
+- [JavaScript API](docs/api-js.md)
+- [Objective-C API for iOS](docs/api-ios.md)
+- [Java API for Android](docs/api-android.md)
+- [Multi-deployment testing for iOS](docs/multi-deployment-testing-ios.md)
+- [Multi-deployment testing for Android](docs/multi-deployment-testing-android.md)
-Note that by default, React Native logs are disabled on iOS in release builds, so if you want to view them in a release build, you need to make the following changes to your `AppDelegate.m` file:
+## Store Guideline Compliance
-1. Add an `#import ` statement. For RN < v0.40 use: `#import "RCTLog.h"`
+Apple and Google permit some interpreted-code and JavaScript update scenarios, but your application and every OTA update remain subject to the current store agreements and review policies. Revopush cannot ship native code changes or bypass platform security.
-2. Add the following statement to the top of your `application:didFinishLaunchingWithOptions` method:
+Before enabling OTA updates in production, review the current [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) and [Google Play Device and Network Abuse policy](https://support.google.com/googleplay/android-developer/answer/9888379). Avoid using OTA delivery to materially change the purpose or native behavior of an approved application.
- ```objective-c
- RCTSetLogThreshold(RCTLogLevelInfo);
- ```
+## Troubleshooting
-Now you'll be able to see CodePush logs in either debug or release mode, on both iOS or Android. If examining the logs don't provide an indication of the issue, please refer to the following common issues for additional resolution ideas:
+Start with the SDK logs, which are prefixed with `[CodePush]`, then check these common causes:
-| Issue / Symptom | Possible Solution |
-|-----------------|-------------------|
-| Compilation Error | Double-check that your version of React Native is [compatible](#supported-react-native-platforms) with the CodePush version you are using. |
-| Network timeout / hang when calling `sync` or `checkForUpdate` in the iOS Simulator | Try resetting the simulator by selecting the `Simulator -> Reset Content and Settings..` menu item, and then re-running your app. |
-| Server responds with a `404` when calling `sync` or `checkForUpdate` | Double-check that the deployment key you added to your `Info.plist` (iOS), `build.gradle` (Android) or that you're passing to `sync`/`checkForUpdate`, is in fact correct. You can run `appcenter codepush deployment list / --displayKeys` to view the correct keys for your app deployments. |
-| Update not being discovered | Double-check that the version of your running app (like `1.0.0`) matches the version you specified when releasing the update to CodePush. Additionally, make sure that you are releasing to the same deployment that your app is configured to sync with. |
-| Update not being displayed after restart | If you're not calling `sync` on app start (like within `componentDidMount` of your root component), then you need to explicitly call `notifyApplicationReady` on app start, otherwise, the plugin will think your update failed and roll it back. |
-| I've released an update for iOS but my Android app also shows an update and it breaks it | Be sure you have different deployment keys for each platform in order to receive updates correctly |
-| I've released new update but changes are not reflected | Be sure that you are running app in modes other than Debug. In Debug mode, React Native app always downloads JS bundle generated by packager, so JS bundle downloaded by CodePush does not apply.
-| No JS bundle is being found when running your app against the iOS simulator | By default, React Native doesn't generate your JS bundle when running against the simulator. Therefore, if you're using `[CodePush bundleURL]`, and targetting the iOS simulator, you may be getting a `nil` result. This issue will be fixed in RN 0.22.0, but only for release builds. You can unblock this scenario right now by making [this change](https://github.com/facebook/react-native/commit/9ae3714f4bebdd2bcab4d7fdbf23acebdc5ed2ba) locally.
+| Symptom | What to check |
+|---|---|
+| No update appears | Run a release build, not a debug build or Expo Go. |
+| Update is not discovered | Confirm the app version matches the release target and the binary uses a key from the same deployment. |
+| Update downloads but is not visible | The default mode installs on the next restart. Launch once to download, then relaunch to apply. |
+| Update rolls back after restart | When using a fully manual flow without the HOC, call `codePush.notifyAppReady()` after a healthy launch. |
+| iOS receives an Android update, or vice versa | Use separate applications and deployment keys for each platform. |
+| Expo configuration changes have no effect | Run `npx expo prebuild --clean` again and create a new native build. |
+| Server returns `404` | Verify the deployment key with `revopush deployment ls -k`. |
-### TypeScript Consumption
+For more help, see [common problems](https://docs.revopush.org/troubleshooting/troubleshooting) or contact [support@revopush.org](mailto:support@revopush.org).
-This module ships its `*.d.ts` file as part of its NPM package, which allows you to simply `import` it, and receive intellisense in supporting editors (like Visual Studio Code), as well as compile-time type checking if you're using TypeScript. For the most part, this behavior should just work out of the box, however, if you've specified `es6` as the value for either the `target` or `module` [compiler option](http://www.typescriptlang.org/docs/handbook/compiler-options.html) in your [`tsconfig.json`](http://www.typescriptlang.org/docs/handbook/tsconfig-json.html) file, then just make sure that you also set the `moduleResolution` option to `node`. This ensures that the TypeScript compiler will look within the `node_modules` for the type definitions of imported modules. Otherwise, you'll get an error like the following when trying to import the `react-native-code-push` module: `error TS2307: Cannot find module 'react-native-code-push'`.
+## License
----
+MIT