# Production checklist

Check readiness before release, observe the rollout, and keep a usable recovery path.

## Complete these checks before release {#before-release}

| Check | Evidence |
| --- | --- |
| Compatibility | Native dependencies and runtime unchanged; baseline registered |
| Content | Correct branch and entry; critical screens verified on devices |
| Targets | App, channel, native version and percentage reviewed |
| Traceability | Package, sourcemap, commit and deployment IDs retained |
| Recovery | Previous stable package available and recovery targets confirmed |

## Optimize the native package {#native-size}

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](/docs/getting-started#android)): 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 {#ppk-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 {#rollout-discipline}

- **Inside first**: validate every release on an internal test channel (see [Channel publishing](/docs/channels#practices)) before staging on production channels.
- **Percentage ladder**: 10% → 30% → 100%, pausing at each step to watch [version health](/docs/analytics#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 {#store-review}

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](https://developer.apple.com/app-store/review/guidelines/#software-requirements) and target store requirements.

## Rollback planning {#rollback-plan}

- 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](/docs/publish#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](/docs/integration#health) configuration, or premature auto-confirmation can skip the protection.

## Archiving habits {#archive-habits}

- Archive a sourcemap with every `publish --sourcemap`, so production stacks can always be symbolicated (see [Error monitoring](/docs/errors#symbolicate)).
- Use traceable `--name` values (ticket numbers or CI run ids) so the version list reads itself.