Instant updates (OTA)

Ship a JavaScript fix to installed apps without a store release.

For a React Native app, most of what you change day to day is JavaScript. Instant updates replace the bundle inside an already-installed app, so a fix reaches your users the day you write it instead of the week the store gets round to it.

This speaks the CodePush client protocol. If your app already uses react-native-code-push, you change the server URL and the deployment keys, and nothing else.

JavaScript only. Anything that changes native code — a new library with native modules, a permission, an icon — still needs a store release. That is why every release targets a range of binary versions.

1. Create deployments

On the app's page, under Instant updates, set up deployments. You get Staging and Production, each with a key shown once. Put the keys in your binary.

2. Point the app here

iOS — in Info.plist:

<key>CodePushDeploymentKey</key>
<string>hsd_YOUR_STAGING_KEY</string>
<key>CodePushServerURL</key>
<string>https://hashdrop.io</string>

Android — in android/app/src/main/res/values/strings.xml:

<string moduleConfig="true" name="CodePushDeploymentKey">hsd_YOUR_STAGING_KEY</string>
<string moduleConfig="true" name="CodePushServerUrl">https://hashdrop.io</string>

3. Publish a bundle

npx react-native bundle --platform android --dev false \
  --entry-file index.js \
  --bundle-output build/main.jsbundle \
  --assets-dest build

# zip the CONTENTS of the output directory, not the directory itself
(cd build && zip -qr ../bundle.zip .)

curl -H "Authorization: Bearer hst_YOUR_CI_TOKEN" \
  -F package=@bundle.zip \
  -F app=your-app-slug \
  -F deployment=Staging \
  -F targetBinaryVersion=1.2.x \
  -F description="Fix invoice totals" \
  https://hashdrop.io/api/ota/releases

targetBinaryVersion

The single most important field. It is a semver range describing which binaries this bundle is safe on, and a device outside it is never offered the update.

Value	Matches
1.2.x	Any 1.2 build — the usual choice
1.2.3	Exactly that version
>=1.2.0 <2.0.0	An explicit range
*	Everything. Only when you are certain

4. Promote what survives

Publish to Staging, put it on a real device, then promote to Production from the panel. Promotion references the same package rather than copying it, so a device that already downloaded it in Staging is not asked to fetch it again.

Rollout, mandatory, and pulling

Rollout — give a release to a percentage. Which devices are inside is decided by hashing the device's own id, so a device never flips back out
Mandatory — the client applies it immediately rather than on next restart. It stays mandatory for a device that skipped it, even if later releases are optional
Pull — stops it being offered and makes the download 404 immediately

Rolling back

Roll back re-releases the previous package under a NEW label, and pulls the bad one. Devices only ever move forward, so reusing the old label would leave everyone already on the bad bundle believing they were up to date.

Watching a release

Each release shows devices, downloads, installs and failures, reported by the client itself. Failures appearing is the signal to pull or roll back — and the panel says so, rather than leaving you to notice.