The goal of this article is to provide meaningful insight to fellow developers on whether they should use Expo if they start a fresh React Native project in 2024.

Upon deciding to do so, many questions arise:

• Should I use the Managed Workflow?
• Should I use the Bare Workflow?
• Should I use Expo Go?
• Should I use EAS?
• What is CNG?
• And how do all these relate to React Native without Expo?

I aim to answer all of the above questions based on my knowledge and experience as a technical decision-maker at a software development agency that has heavily relied on React Native for 7 years. So much so that we ship all our mobile applications with React Native, considering it the superior method for creating mobile apps today.

And, to be frank, a large contributor to that is Expo itself, and the community behind Expo.

Let's Start with the Basics

The available literature on this topic is generally outdated. Many articles are based on former knowledge without catching up with the latest features. Expo has evolved significantly in the last 3 years, and the React Native ecosystem is steadily adapting to the "New Architecture."

Both developments are huge contributors to making it easier than ever to build, debug, test, and ship native mobile applications by abstracting away the complexity that comes with native development.

React Native

What was React Native a couple of years ago?

A cross-platform framework that enabled mostly web-technology-familiar individuals (React, JavaScript, CSS, Flexbox) to build mobile applications rendering native elements.

From a business perspective, it was somewhat limited by performance issues, primarily due to serialization and the bridge.

From a technical perspective, it might have lured (web) developers into believing they could deliver mobile apps with native elements without touching the native parts, which almost always proved to be an illusion. Even without writing native code, familiarity with native tooling (XCode, CocoaPods, Android Studio, Maven) was necessary.

Was it an unusable framework? Absolutely not. The benefits still outweighed the disadvantages, and now they do more than ever.

The fact that most of the codebase is shareable between iOS and Android, the composability of UI, and the ability to push code changes to users without resubmitting to stores were still significant selling points for React Native.

What is React Native today?

In my opinion, React Native is growing-up, luckily before hitting 18 years old. It's gradually becoming the framework it likely aimed to be from the start, enabling anyone with limited or no native knowledge to develop cross-platform mobile apps with React, JavaScript/TypeScript, and CSS/Flexbox. These apps render native elements without the need to interact with native parts.

With features like autolinking (July 2019) for native modules, a significant step was made toward this goal. Then came Hermes (the optimized JS Engine for React Native), Flipper (the debugger), and Fast Refresh (which preserves the state of functional components and hooks), among many others.

With the "New Architecture" (see my StackOverflow post from 2022, or the official docs), React Native is finally overcoming its main performance limitations and UI complexities.

But, in my view (which reflects our team's opinion), the most significant step was undoubtedly Expo, especially with the changes introduced in the last 3 years.

Expo

What was Expo a few years ago?

A framework for React Native developers aimed at simplifying the complexity of native development, by providing a prebuilt app and an SDK. Developers were limited to using Expo's SDK (prebuilt into the app now known as Expo Go, which has since become an opt-in feature). If further native functionality was required, they needed to eject from Expo to a pure React Native workflow, losing the ability to use Expo modules.

In response to the community's need for more control and flexibility while still benefiting from some of Expo's features and ecosystem, the Bare workflow was introduced in June 2019. It allowed developers to use parts of Expo without being restricted by Expo's SDK. A significant milestone enabling this was the UniModules feature of Expo, allowing the use of Expo modules in pure React Native projects.

This meant that when using Expo's SDK sufficed for native needs, you could be in the Managed workflow (similar to now using Expo Go), without having to touch ios and android folders.

But when additional native modules not available in Expo's SDK were needed, you ejected to the Bare workflow (essentially a pure React Native app using Expo modules). You could still utilize Expo modules, but not the features of Expo Go. Plus, you had to build your app to the device (remember, no Expo Go) and manage the native parts (ios and android folders) using Android Studio and XCode.

As this example illustrates, the further back we go in history, the more crucial the technical decision to use Expo or not becomes.

That changed entirely and, in my opinion, unequivocally. And the winner is: Expo (and therefore, React Native).

What is Expo today?

A framework that successfully abstracts away the native components of your cross-platform React Native codebase while offering the option to easily opt into writing native code if needed. And with EAS, it's much more. A complete toolkit to develop and ship faster.

The transition from the Managed workflow (where ios and android folders are continuously generated with CNG and not committed to source control but controlled by you) to the Bare workflow (where ios and android folders are managed by you and committed to source control) is seamless, but most likely unnecessary.

With Config Plugins introduced in April 2021, developers could control their native code in the Managed workflow through Expo's app.json. Expo then generates the native ios and android folders on demand based on the modified config. This became the recommended way for package authors to make their code compatible with Expo's Managed workflow, eliminating the need for developers using Managed workflow Expo apps to eject to the Bare workflow. So much so that eject as a feature was removed from Expo, as it became obsolete, marking the blurring line between Managed and Bare. One can now transition easily and gradually.

So today, the only difference between a Managed and a Bare workflow Expo app is essentially whether you generate the native folders based on config plugins (Managed) on demand, or commit those to the source code to allow for writing native code inside the project itself directly (Bare).

Please note that if you'd like to write your own custom native modules, you can still do that in the Managed workflow with CNG, with the help of Local Expo Modules, which is likely sufficient for most use cases.

EAS

Expo has evolved to be more than just the framework discussed so far. The Expo team has developed various cloud features to help developers build and ship apps faster and more easily.

It consists of several components:

• EAS Build: Allows building in the cloud, eliminating the need for Android Studio or XCode setups. This can be crucial for iOS development if you're not working from a Mac since it can replace XCode.
• EAS Update: Enables you to deliver instant updates to your app's JavaScript, images, and other assets without going through the app store review process. Available in both Bare and Managed workflows.
• EAS Submit: Simplifies the process of submitting your apps to the Apple App Store and Google Play Store. It automates various steps in the submission process, making it less tedious and error-prone.

and many upcoming features like EAS Metadata, EAS Insights, and possibly more.

Should you use these features?

It's totally up to your preferences and budget. For example, we at Scriptide tend to build locally, so we don't use EAS Build for day-to-day development. However, for CI, it's a good option.

On the other hand, we rely more heavily on EAS Update and Submit, as they save a lot of time, especially if your team isn't that seasoned with the submission procedures (particularly the iOS-related, not-so-straightforward ones).

To Expo or Not to Expo?

We believe the decision is clear. You should always use Expo if the app is suitable for building with React Native.

A more relevant question might be: What parts of Expo (and EAS) should you use?

Should you use Expo Go?

It depends on your specific needs. More likely no than yes.

Yes: If you're just starting out and want to experiment, use Expo Go. It's easier. You just download it, scan a QR code, load your JS bundle, and you're good to go. Even the React Native team recommends that.

No:

If you need any of the following:

• Deep Linking and URL Schemes (e.g., OAuth Login)
• Push Notifications
• Payments
• Custom Native Code
• Custom Native Modules
• Background Tasks
• Advanced Graphics and Animations

Don't even bother implementing them with Expo Go, even if technically possible, as the release process will work differently.

If your team is confident with the tooling (XCode, Android Studio) and building an app locally is not an issue, I'd also recommend against using it. Your environment will change when you release the app from Go, potentially complicating your life.

With expo-dev-client, you can essentially use any feature of Expo Go, like advanced debugging, in your custom app without having to worry about the technical limitations of the Go app.

Managed or Bare Workflow

As mentioned earlier, the primary difference is whether you generate (Managed) or commit (Bare) the ios and android folders to source control, and whether you write native code through Local Expo Modules (Managed) or directly (Bare).

The Bare workflow is technically equivalent to a bare React Native app now (with Expo CLI installed). If you start with the React Native CLI, you'll likely still use many Expo Modules, as they are usually the best-in-class for a given requirement. And since expo install helps you install packages that are compatible with each other more easily than doing it yourself, why not start with the Expo CLI?

Conclusion: Start with the Managed workflow, opting for the Bare if you need total control of the native layer and know what you're doing.

Don't opt for the React Native CLI, as it offers no advantages over starting with the Expo CLI's Bare workflow.

Expo Dev Client

You should use it. You lose nothing with it but gain a better debug experience and other useful features detailed in the docs.

Summary

Using Expo is almost always a safe bet. For us, not using Expo Go, usually in the Managed workflow, is the sweet spot.

P.S.

Neither I nor Scriptide are affiliated with Expo in any way. We're grateful for what they build and how they advance React Native, making our lives as a software development agency easier and more enjoyable. We're excited about what the future holds.

Feel free to reach out to me in email or LinkedIn if you have any questions, comments on the article.