Mobile app development is stuck in first gear

Getting updates out to your users can be a complicated proposition, but if you're using React Native there's an excellent shortcut in CodePush. You may wonder why you should bother with a third-party tool when both iOS and Android's app stores have built-in processes for this — but the benefits are numerous enough that you might soon wonder why you ever used the first-party options in the first place.

In essence, CodePush allows you to change the code running on your users' devices without issuing an actual update and triggering the usual delays and oversight. While CodePush can't update your native code, the majority of your releases will be entirely Javascript-based. That means you can avoid the review process for most of your releases.

Normally an update would involve building a fresh binary, something that may take half an hour or more to happen — not counting any time you'd have to spend on code review and other preliminary steps. Once you submit it to the store it has to go through the review process, the length of which depends on many factors outside your control. Even in the best case submission and approval scenario, it's entirely possible that users will have turned off automatic updates, or it will be waiting for a Wi-Fi connection, or plenty of other situations that add hours in the best case and days in the worst case when, in the case of a crucial update, every minute counts.

A truly agile update pathway

CodePush lets you make significant changes to users' experiences in as little as five minutes. If you want agile, this is as agile as it gets. A user opens the app, goes to grab a cup of coffee, then opens it again — boom, UI refresh. New checkout flow. Faster animation. If you can achieve it in React Native, you can quickly and easily get it to users with CodePush.

But aren’t we skirting the store’s review process?

To a certain degree. But it’s important to note that you can only use CodePush to send updates to your users once your app has been submitted and accepted to the store. This means you’ve already undergone the review process once.

Also using CodePush is completely in compliance with store policies as long you follow these guidelines. In summary, Google is okay with you changing the js bundle without review which is exactly what CodePush does, and Apple is okay with it as long as you don’t change the purpose of what the app was originally intended to do.

Your code, your processes, at your speed

Naturally, this all has to work with your own code management and review policies. So CodePush is integrated with AppCenter, which will let you add release notes and manage the update. And by default the changes deploy to your staging environment, so you can check them in the debug version of the app before promoting it to production.

It also lets you set up what you might call cascading updates. Say you have an updated UI ready to go, but elements of it involve a feature that won't debut until version 2.4.1 ships. All you need to do is set the "target version" for the Javascript update, and when 2.4.1 rolls around, it's automatically activated.

If you want to do a little A/B or limited roll-out testing, that's possible too. You can simply select what percentage of users you'd like to see a given update. You can also update your logging setup through the CodePush update to uniquely identify which users the setup has been rolled out to. This way you can monitor if your change has caused an increase in errors or crashes. If this is the case, CodePush also has a simple CLI for rolling back releases.

The main challenge to CodePush is keeping documentation straight — if something breaks on a full update, it's important to know whether it was a conflict with an "invisible" Javascript update, a bug in the native code itself, or an issue with another Javascript change pushed on a target version. Good versioning and documentation are crucial, since there will be many updates on a single bundle version, you need to ensure you can track which CodePush updates correspond to which changes. An easy way to track this is by adding the build number to each CodePush release.

If you can handle this slight increase in diligence — and who couldn't be doing a better job of documentation anyway? — you'll find CodePush to be an incredibly powerful tool for agile development.