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 (C
RNA), 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?
The goal of Expo is to allow mobile developers to build native app purely in JavaScript. It took the initial idea of React-Native app being a pre-built native app that can run JavaScript in runtime and push it further. They include a handful of commonly used native modules, packaged in an Expo client with a living service built around it. Create-React-Native-App (CRNA) is a lighter version of the Expo that has been repackaged under a different name yet still relies upon Expo infrastructure to work.
How it works:
-
You mainly develop using the Expo client on your phone to run the JavaScript application served through ngrok (a reversed proxy solution to channel your app through a tunnel to the public web) using exp-cli running on your computer. It may sound complicated but it is actually much simpler in practice: you run `exp start` on your computer, point your phone toward the QR code on the screen and the app loads instantly on your phone without any further need of Xcode or Android Studio build
-
Most of the work is done when your application’s JavaScript bundle is served through the ngrok tunnel (which exempts you from needing a cable, granting more freedom in development as it’s not necessary to be in the same network as your computer for your application to work!)
-
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).
Benefits
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?
The big elephant in the room is still native-modules. At its core, React-Native is basically two native Android iOS runtimes bundled with your application written in Javascript. React-Native provides a bridge between your JS code and mobile native environment, which means in order to fully use native capabilities, we must have those capabilities exposed on the bridge.
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?
Pros:
-
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
Cons:
-
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.
Stay tuned…
