---
title: "CodePush | Skills We Assign For | Azendo"
description: "CodePush for React Native updates — what can ship over the air, the rules that apply, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/codepush/"
---

[Skills](https://azendo.co/skills/) CI and delivery 

# CodePush.

CodePush delivers JavaScript and asset updates to React Native applications without a store release. The application checks for an update and applies it, so a fix reaches users in minutes rather than after a review cycle.

## 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](https://azendo.co/services/cloud-and-devops/) 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.

## Roles we assign CodePush for

* [React Native Developer Mobile development](https://azendo.co/services/mobile-development/react-native-developer/)

## Service lines it sits in

* [Mobile development](https://azendo.co/services/mobile-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in ci and delivery

* [GitHub Actions — skill we assign for](https://azendo.co/skills/github-actions/)
* [Jenkins — skill we assign for](https://azendo.co/skills/jenkins/)
* [GitLab CI — skill we assign for](https://azendo.co/skills/gitlab-ci/)
* [Fastlane — skill we assign for](https://azendo.co/skills/fastlane/)
* [Codemagic — skill we assign for](https://azendo.co/skills/codemagic/)
* [TestFlight — skill we assign for](https://azendo.co/skills/testflight/)
* [App Store Connect — skill we assign for](https://azendo.co/skills/app-store-connect/)
* [Play Console — skill we assign for](https://azendo.co/skills/play-console/)

## Tell us what your roadmap needs CodePush for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)