Understanding Expo

I’ve seen a few posts in the React Native community mentioning how Expo shouldn’t be used and how it’s like “training wheels for React Native” and I wanted to share my understanding of what Expo is and is not…

Managed vs Bare Workflows

Before the release of Expo EAS (more on that later), the Expo managed workflow could have been thought of as “training wheels for React Native”.

Today however, the difference between the managed and bare workflows is simple… the managed workflow can be used 100% in javascript/typescript, while the bare workflow give you access to the native project files for Xcode and Android Studio.

Here’s Expo’s documentation on the differences: https://docs.expo.dev/introduction/managed-vs-bare/

Managed workflow with EAS

Now, here’s the important bit… before December-ish of 2021, the managed workflow was limited to what it could offer… if you wanted to run that sweet React Native tracking library, or install a specific React Native database, like Realm, that required low-level native code adjustments, it wasn’t possible. If you stop here, you’ll continue to think Expo is limited, and as I said, before December-ish of 2021 it was… BUT…

As of the release of a new Expo service called EAS (Expo Application Service), you can now add ANY react native libraries that you want while staying in the managed workflow. There are very very few limitations (I haven’t run into any myself, but I’m leaving this open as I haven’t tested every library).

At its core, EAS is a way to build your application.

• You send EAS your code, either via a CLI locally, or you can add it to your CI/CD, and you tell it what kind of build you want to run; development, internal or production
• EAS takes your bare Expo app and a configuration file with a list of native dependencies you want to install and ejects your app into a base React Native app.
• It then goes through the configuration and installs all your native dependencies (like Realm), and automatically edits the native files for you to get the native dependency work (it knows how to do this via a ‘plugin’ folder on the dependency)
• If you told EAS to build in development mode, it adds a nice dev-client on top of your app, otherwise it finishes the build and sends you back the app to run in a simulator. Once loaded on your simulator, the dev client will connect to your local server and bundle your javascript (with hot reloading), just like a normal RN app.
• If its not a production/test build, EAS can submit it up to Apple / Google (EAS runs fastlane in the background to submit your build) and helps you manage all the certificate / provisioning profile / keystore stuff.

Theres a lot more EAS can help with; different environments, code push, internal testing, etc, but at its core, EAS is a new powerful build tool that allows Expo bare workflow applications to do everything a traditional React Native application could do. Its limitless.

Expo and the team are awesome, and I really respect everything they are doing for the RN community. If you haven’t tried the managed workflow with EAS, you really should do a spike / get a demo up, and I think you’ll be impressed with how far Expo has come and how different the bare workflow with EAS is from the original Expo workflow that you might be familiar with.!

—

Although this post is in response to developers misunderstanding of Expo, I can’t fault these developers entirely. I think Expo could do a better job at naming and branding the differences between these offerings. It took me a while (longer than I would have liked) to understand all the differences between the bare & managed workflows and how EAS and the Go application all fit into the Expo ecosystem. That being said, the Expo team is incredible and I appreciate all their amazing work done for the React Native community!

Let me know your thoughts and if you’ve run into any challenges with EAS, (I’ve personally struggled with getting a good E2E/Detox integrated in a good way)!