We continue our set of articles about eliminating extra dependencies in the code. You may find out more about our first article about removing jQuery here.
The main character of our article is Expo today. This is a set of tools every React developer knows. It’s an instrument that makes your developers’ life much easier when you develop apps for iOS and Android. Expo is about Over The Air updates without deployment on Google Play and Apple Store and sharing the app with the others without .apk or .ipa files. Expo is a toolchain that helps and guides you almost in every possible problem while developing. And finally, Expo is an extra-dependency we have got rid of in our product. You can read about it here.
A Fast Review of Expo
You can build applications with Expo in two ways: managed and bare workflow. Managed workflow is an Expo itself with all its advantages: Over The Air updates, build service, no need to use Xcode or Android Studio, Expo push notification service, etc. The bare workflow is when you use Expo SDK like a set of libraries (ExpoKit) that gives you access to the underlying native APIs.
You can start using this approach by ejecting Expo from your app with the “expo eject” command (if you have already used Expo in development) or by running the “expo init” command to get started with Expo. In bare workflow, you get access to every APIs that Expo SDK contains, but you still have to work with Xcode and/or Android studio. If you don’t use Expo in development either with managed workflow, or the bare workflow you work with Vanilla React Native. But when Expo is ejected from the project that has contained Expo before, you still keep working with ExpoKit, because the functions in your project are based on the instrument from the kit.
These are key terms and you need to understand them clearly. For more information visit official documentation. Meanwhile, we are going on…
Meet the Well-known Limitations of Expo
Let just speak about the limitations of the Expo. But first of all, we want to emphasize that the developers of Expo took a prudent approach to write the documentation for Expo with included limitations of it. Therefore warned means armed.
In the documentation, there are a bunch of cases in which Expo fails. So we have an officially issued list of Expo problems. Let’s check out this list and figure out what problems we face here.
- Not all iOS and Android APIs are available yet – Bluetooth, In-App Purchases are the most painful. This is not so much a problem as a severe limitation. If in your requirements list Bluetooth or In-App Purchases include, forget about managed workflow.
- Your app needs background code execution – one of the most discussed and problematic topics. That is about the situation when the app works in the background, not if it was killed or swiped. Play audio, handle push-notifications in the background are in development for several years. That also cuts off a part of potential apps.
- The simplest app size with “Hello, world” is 25 MB – this is the most frightening thing for new developers since even the simple chat app will take more than 70 MB of the space when unwrapped. That is because you have to store all Expo SDK modules in managed workflow even when they are not in us.
- You can’t add custom native code to an Expo project – Expo doesn’t support custom native code in projects with Managed workflow. If you want to use third-party libraries or just to adjust the native code (Objective-C or Java) you are not able to do that with Expo. Expo SDK offers a large set of native modules for the most developers need – try to find one that fits your project. But if you have some specific uncommon needs, Expo may not help you. And here the explanation of the big size of Expo SDK comes – to provide developers with necessary functionality when they are not able to manipulate the native code or add third-party libraries, the solution (Expo) has to contain as many possible tools as it can hold.
- The only supported push notification service goes from Expo – it’s called Expo Push Notification service/API. Not a big problem while you are comfy with the service.
- Expo supports Android 5+ and iOS 10+ OS versions – just a matter of the audience. According to the law of the vital few if Expo covers 80% of the audience there is no need to abandon Expo just because a part of your potential users are used to their old smartphones.
- There can be a delay for build’s production – since Expo provides developers with free standalone built service, which cluster is a finite, shared resource, builds can sometimes be queued. It’s allowed to buy Priority plan with prioritized build infrastructure for developers who dislike waiting. We don’t consider that fact a problem, rather the consequence of the opportunities Expo offers. Server costs money, business user helps cover that cost for getting the priority in using it. Priority plan is less expensive anyway than holding your own server.
Except for the limitation listed above, you can meet additional surprises like:
- Every app that was built with Expo includes the whole bunch of SDKs it Expo contains – do you know which of them are active in your app? There was a problem in 2017 when Expo apps that don’t use Facebook libraries keep them active. For what reason: accidentally or to collect personal data? We don’t know. The problem was solved and Expo developers have disabled Facebook libraries in apps that don’t use it. But the question about the security of your data remains open.
- Slow background image rendering – even tiny 2k icons sometimes take several seconds to load. If an app has a huge amount of images in one go, it takes time to load the app. The possible solution to it is caching crucial assets when the app starts.
What Points From That List Became Crucial for Us?
Lack of native modules. Imagine that you buy a template and figure out that you have problems with in-app purchases function just because the developers of the template have used Expo. That is can be a big trouble.
Inability to add custom code for expansion of the functionality of the project. That is the most limiting and annoying thing about Expo. The only way to adjust the code is by ejecting Expo and built the project within the bare workflow (or just in Vanilla if you get rid of all ExpoKit’s dependencies). And we assure you that ejecting is a very painful process.
Since our products are oriented on developers from different spheres with various needs, it is essential for our products to be flexible and provide opportunities, not limitations.
However, there is always a possibility to hack the system and overcome the constraints. If you are one of such developers, google “expo and raw react-native together”, and try your luck. Those who seek always find the opportunity to achieve their wishes.
Did We Make the Right Decision?
Since we made React Native Starter for the usage of other developers, they will be the best judges of our decisions. And today this is one of the most popular React Native Starter kits on GitHub with 1.2 k stars and we got a lot of positive feedback about our product and RNS turned to be a great kit in several successful cases like the one with AirBnB-like app. So we think yes, we made the right decision but if you want you can check it on yourself here.
Thanks for reading
About Flatlogic
At Flatlogic we develop admin dashboard templates and React Native templates. We are listed among the Top 20 Web Development companies from Belarus and Lithuania. During the last 6 years, we have successfully completed more than 50 big projects for small startups and large enterprises. As a team, we always have a deep desire to help our clients.
