The following article is part of The Ultimate Guide to React Native Optimization and discusses the topic of OTA updates.
Why is this important?
Traditional ways of updating apps are too slow and make you lose precious time on them. Compared to native apps, React Native applications come with an advantage in this regard, though. The advantage in question are over-the-air (OTA) updates, and this article explains what they mean to your business and how to implement them.
In other blog posts based on The Ultimate Guide to React Native Optimization, we touch on the following stability-related topics:
- Shipping Fast with Continuous Deployment
- How Can Continuous Integration (CI) Improve Your React Native Apps?
- Run Tests for Key Pieces of Your App
Why should you submit critical updates and fixes instantly through OTA?
What do OTA updates (or lack of them) mean to your business?
Every update, no matter how quickly shipped by your developers, is usually going to wait some time while the App Store and Play Store teams review your product against their policies and best practices.
As a result, the submission process takes a while. And if you’re about to ship a critical update, every minute counts.
When critical bugs happen - minutes and hours can be essential. Don’t wait for Apple and Google to review your app.
If your application is not OTA-ready, you risk it being left with a critical bug on many devices, for as long as Apple / Google reviews your product and allows it to be distributed.
Even though the review times got much better over the years, it is still a good escape hatch to be able to immediately recover from an error that slipped through the testing pipeline and got into production.
How to implement OTA updates with App Center / CodePush
As mentioned earlier, React Native is OTA-ready. It means that its architecture and design choices make such updates possible. However, it doesn’t ship with the infrastructure to perform such operations. To do so, you will need to integrate a 3rd party service that carries its own infrastructure for doing so.
The most popular and widely used tool for OTA updates is CodePush, a service that is now a part of Microsoft’s App Center suite. An alternative is EAS Update, which you might find more convenient if you’re already running an Expo app. To learn more about this tool, check out chapter 4 of our Ultimate Guide to React Native Optimization; for now, though, let’s focus on CodePush.
Configuring the native side
To integrate CodePush into your application, please follow the required steps for iOS and Android respectively. We decided to link to the official guides instead of including the steps here as they include additional native code to apply and that is very likely to change in the coming months.
Basic CodePush integration
That’s it! If you have performed all the changes on the native side, your application is now OTA-ready. For more advanced use cases, you can also change the default settings on when to check for updates and when to download and apply them. For example, you can force CodePush to check for updates every time the app is brought back to the foreground and install updates on the next resume.
The following diagram code snippet demonstrates such a solution:
Custom CodePush setup
Shipping updates to the application
And then we continue with a <rte-code>release<rte-code> command to bundle React Native assets and files and send them to the cloud:
Once these steps are complete, all users running your app will receive the update using the experience you configured in the previous section.
<p-bg-col>Note: Before publishing a new CodePush release, you will have to create an application in the App Center dashboard. That will give you the <rte-code>ownerName<rte-code> and <rte-code>appName<rte-code> that you’re looking for. As said before, you can either do this via UI by visiting App Center or by using the App Center CLI.<p-bg-col>
Benefits of shipping critical fixes and some content instantly to the users with OTA updates
For example, it may happen that your backend will stop working and will cause a crash at the startup. It may be a mishandled error - you never had a backend failure during the development and forgot to handle such edge cases. You can fix the problem by displaying a fallback message and informing users about the problem. While the development will take you around one hour, the actual update and review process can take hours if not days.
With OTA updates set up, you can react to this in minutes without risking that bad UX will affect the majority of users.