Production checklist

Complete these checks before release

Optimize the native package

Differential benefits depend on baseline quality — a smaller, cleaner baseline means smaller patches.

iOS

For the same archive (version, build time and embedded bundle are fixed regardless of export options), export the ipa several times with different options and upload the smallest one as the hot-update baseline. Cleaning duplicate resources (redundant image scales, unused architecture slices) during export is the cheapest win.

Android

• crunchPngs false (see Installation): keeps resource bytes stable across builds — the precondition for meaningful diffs.

• Use apkanalyzer to find duplicate resources and unused native libraries.

• Register signed release APKs as baselines; never mix debug and release builds.

Control the update package size

A .ppk contains only the JS bundle and assets — images are usually the bulk:

• Ship large images from your CDN and download on demand instead of bundling them;

• New image assets are the top reason update packages grow; review the asset diff before publishing;

• With Hermes enabled, the CLI reuses baseline bytecode automatically (--hermesBase auto), so patches are typically much smaller than full packages; when a patch is not worth it, the platform falls back to the full package without manual intervention.

Rollout discipline

• Inside first: validate every release on an internal test channel (see Channel publishing) before staging on production channels.

• Percentage ladder: 10% → 30% → 100%, pausing at each step to watch version health.

• Signals over schedules: pause immediately when rollback or failure rates look wrong — going slow beats shipping sick.

• Snapshot every widening: each rollout step leaves a clear record in deployment management, so "which step broke it" always has an answer.

App-store review windows

Keep submitted behavior consistent with review materials. Do not use updates to hide features or bypass review. Channels control delivery, not approval. Check the official Apple review guidelines and target store requirements.

Rollback planning

• Before every release, confirm the previous version is still listed and deployable (historical packages can become a new full deployment at any time — see Rollback).

• Agree on alert thresholds in the team: who watches rollback/failure rates, and how fast they respond.

• When a hot update crashes, the SDK rolls back to the last good version automatically — make sure your critical initialization matches your health confirmation configuration, or premature auto-confirmation can skip the protection.

Archiving habits

• Archive a sourcemap with every publish --sourcemap, so production stacks can always be symbolicated (see Error monitoring).

• Use traceable --name values (ticket numbers or CI run ids) so the version list reads itself.