Documentation
Everything to ship over-the-air updates with Pulsar — from install to multi-deployment testing.
Troubleshooting
Confirm the build’s CodePushDeploymentKey matches the deployment you released to, and that the release --target matches the app’s binary version (semver range). A disabled release is not served.
With next-restart the update applies on the next cold launch. For immediate, ensure notifyAppReady() is called — otherwise the update is treated as bad and rolled back.
Ensure your install-mode mapping treats IMMEDIATE (enum value 0) as a valid mode — a truthy check silently skips it. Pulsar’s reference bottom-sheet handles this correctly.
Non-ASCII characters in --description are URL-encoded by the CLI and decoded server-side; update to the latest CLI if you see header errors on emoji/em-dash descriptions.
Don’t start the CodePush download while a modal/bottom-sheet is mid-teardown — begin the sync only after the sheet has fully closed.
CLI 1.6 compiles releases with the Hermes compiler in your app’s node_modules. Run your package manager’s install in the app folder and release again. If the app doesn’t use Hermes, release with --no-hermes. See Hermes bytecode.
A self-hosted Pulsar server from before Hermes bytecode support can’t send each build the right copy, so the CLI uploads nothing. Upgrade the server, or release with --no-hermes until you do.
A server from before Hermes bytecode support doesn’t know about the JavaScript copy, so it sends the bytecode to every build, and builds that run another bytecode version crash at launch. Once you have released bytecode, don’t run an older server. If you have to, first release again with --no-hermes on every deployment that has a bytecode release live, or disable those releases.