CodePush.

Where CodePush fits on a long engagement.

Over-the-air updates change the cost of a mistake. A defect that would otherwise need a submission, a review and a user update can be corrected the same hour, which for a production incident is the difference between a bad afternoon and a bad week.

The boundaries are firm. Only the JavaScript bundle and assets can move this way — anything native still requires a store release — and both stores place limits on changing an application's behaviour outside their review process. Updates that materially change what the app does are not what the mechanism is for.

What an assigned team does with CodePush.

The discipline problem is drift. Each over-the-air update widens the gap between the reviewed binary and what users are running, and without a policy about when that gap is closed by a real release, nobody can say what any given user actually has.

Agreeing that policy and holding it is part of owning the release path, scoped with devops managed services alongside the mobile capacity.

What we use CodePush for.

• Correcting a production defect quickly A JavaScript fix delivered in minutes rather than waiting on a review cycle.
• Staged over-the-air rollout Updates released to a percentage first, so a bad bundle does not reach everyone.
• Keeping the binary in step A stated policy for folding accumulated updates back into a store release.

How CodePush capacity is assigned.

Over-the-air update policy is agreed at scoping as part of the release path rather than adopted informally after the first incident.