It is known that React-Native exists as a framework to make cross-platform mobile development easier (as long as the platform you choose is Android or iOS). However, there are many ways to develop a React-Native app - some being a breeze, some bringing headaches. That’s why knowing what you’re buying into before any investment is essential, because fixing what has been done tends to be more difficult than building from scratch.
Currently, if you go on React-Native’s website, the first recommendation offered is Create-React-Native-App (CRNA), a development client built upon Expo framework, which allows you to quickly start developing a React-Native app. It comes without much explanation, which could confusingly overcomplicate your project if you don’t understand Expo’s capability.
Why is CRNA the very first application?
Because after getting the first one shipped, you’re very likely to gain enough experience to make the right decision for your next project. So this article will focus on getting you the information needed to deploy your first product ever.
Let’s go through them to see what we gain and lose by following each implementation:
What is Create-React-Native-App/Expo?
How it works:
The sheer amount of built-in native modules available from the Expo SDK gives you enough flexibility to build the application most needed (we will get into that later).
One benefit of working in the Expo ecosystem is the huge amount of hours saved from having your build delivered to your own phone, and to your testers/customers. Traditionally you would need to build the APK and IPA, executable binaries for Android and iOS respectively (and in case of iOS, prepare the provisioning profile for each and every device you want to test your app on). Then you need to send the build to the right people. With Expo, you only need to send the published Expo link and the app will run on other phones regardless if it’s an Android or iPhone. This technology is not something entirely new, as it’s built toward the philosophy of CodePush or similar services, but wrapped very nicely in a cohesive package that is (mostly) seamless to use.
Expo will also help streamline your build process to the bare minimum. What was a long and agonizing process is now reduced to two command lines to build packages for iOS and Android. Expo will handle the whole code signing / keystore generating process for you (if you allow it to).
Because Expo is already handling APNs key registration, you don’t have to go through the standard protocol to setup and config push notification on iOS/Android.
With all these benefits, why do we ever need pure React-Native anymore?
React-Native already provided a healthy dose of those bridges, and the Expo SDK give you even more to play with. Still, there will always be some unavailable features, hence the temptation to move away from Expo sometimes.
What could the pros/cons possibly be by using pure React-Native?
Capabilities extension via Native modules
Leaner package size due to not having to include modules not in use
More control over the build process
More standardized build process means it is easier to integrate with services like Microsoft AppCenter
Loss of the expedited process of development and deployment enabled by Expo
All mundane steps of mobile application must be manually handled such as:
- Handling/securing the keystore
- Generate and securing APNs keys
- Provisioning devices for testing
Push Notifications function requires a lot of work
Loss of conveniently tunneled ngrok implementation
Loss of CodePush-like (even better) implementation
What if I am already using Expo and want to switch to pure React-Native?
That could be more complex than it may seem. Theoretically, you can still use ExpoKit (the underlying framework powering the Expo client) to provide almost everything you need from the Expo ecosystem. However, there will be some drawbacks:
Push notification: sadly since Expo is no longer handling your APNs key, the push notification feature won’t work. Ideally, it would work if they allowed us to upload our own APNs key, but such a feature is not currently available.
Offline bundle for Android: for some reasons, Expo won’t bundle your JS app in the APK, so it needs to download the bundle from Expo server the first time it’s loaded. This functionality works on iOS, however.
Dependency on the Expo ecosystem: which is not necessary a drawback. But it’s a free ecosystem that may or may not exist in the future. It’s being provided for free now but there’s no uptime SLA available thus you can’t guarantee that it works at different scales.
All in all, Expo gives you a pleasant experience getting into React-Native development but you should always approach it cautiously. It would be best to carefully go through your project, examine thoroughly its requirements to see if Expo SDK provides all native modules you need. More often than not, there will be the JS-only package that could fill the missing features you need, but any further integration is problematic.
On the other hand, moving back (or “detaching”) from Expo to pure React-Native is a huge undertaking, which requires extensive regression testing, depending on what stage of development you’re currently in. Expo lets you develop without too much experience in mobile development so if it fits the project requirements, your product will be shipped without difficulty. Otherwise, be prepared for a lot of headaches. In the next post of this series, I will discuss more about the steps you need to migrate from Expo to React-Native.