What are the main performance limitations of running an app inside expo go compared to a standalone build?

[dannyyol]

Discussion Type

Question

Discussion Content

No response

[xxx-tx]

Expo Go is great for quick testing, but it’s basically a generic container. That means it loads a bunch of extra stuff you might not need, starts up slower, and you can’t use custom native code. A standalone build is much faster and slimmer because it only includes what your app needs, runs in release mode, and gives you the real production performance.

[mecodeatlas]

Thanks for posting in the GitHub Community, @dannyyol!

We're happy you're here. You are more likely to get a useful response if you are posting your question in the applicable category, the Discussions category is solely related to conversations around the GitHub product Discussions. This question should be in the Programming Help category. I've gone ahead and moved it for you. Good luck!

[PRIYAtechky]

Main Performance Limitations of Running an App Inside Expo Go vs. Standalone Build

1. JavaScript Bundle Size & Performance

   • In Expo Go, the entire Expo runtime is included, which makes the app larger and slightly slower compared to a tree-shaken standalone build.
   • Standalone builds only include the specific modules you use, reducing size and improving load times.

2. Limited Native Modules

   • Expo Go only supports the native modules bundled with it.
   • If you need custom native code or performance-critical native APIs, they are unavailable in Expo Go but possible in a standalone build.

3. Startup Time

   • Expo Go apps can take longer to start because they load dynamically and rely on the Expo client.
   • Standalone builds are optimized and start faster.

4. Overhead from Development Tools

   • Expo Go is designed for development and debugging, so it has extra overhead (logging, hot reloading, etc.).
   • Standalone builds remove these extras, improving runtime performance.

5. Offline Performance

   • Expo Go requires a connection to the Expo client for initial execution and some dependencies.
   • Standalone apps bundle everything locally, leading to better offline performance.

👉 Summary: Expo Go is great for development and testing, but standalone builds are smaller, faster, and more flexible since they allow native code integration and optimized performance.

[Joaquimdacosta1999]

The main limitations of running your app in Expo Go come down to three key things:

1. Performance and Size
   Expo Go is essentially a "universal app" that includes a massive collection of Expo's native libraries. Think of it like a giant sandbox. When you run your app in it, your app is just one small part of that big sandbox. This means:

Slower Startup: Your app has to load inside the larger Expo Go environment, which can lead to a noticeable delay when starting up, especially on older devices.

Larger Size: Since Expo Go has to include every possible library just in case you use it, the app bundle itself is much bigger than your final, optimized app would be.

2. Native Code Limitations
   This is the biggest deal-breaker. Expo Go only includes the native modules that are part of the core Expo SDK. If your app needs a third-party native library—for example, a specific barcode scanner or a custom Bluetooth module—you simply can't use it in Expo Go. You'll get an error telling you that the module isn't available.

To use custom native code, you have to create a standalone build (also called a development build with EAS), which is a custom version of the Expo Go app that includes all your specific dependencies.

3. Debugging and Production Inaccuracies
   Expo Go is built for development. It includes extra debuggers and tools that are helpful for building but can slow things down. A standalone production build, on the other hand, is highly optimized, minified, and doesn't have any of the development-specific overhead. Running your app in Expo Go can give you a false sense of how it will perform in the hands of a real user.

So, when should you switch? You'll need a standalone build when:

You want to test your app's actual performance and startup time.

You're ready to submit your app to the Apple App Store or Google Play Store.

Your app needs a native module that isn't included in the standard Expo SDK.