Expo has become the default starting point for React Native development, and for good reason. The developer experience is excellent, the managed workflow handles complexity, and you can ship to both platforms without touching Xcode or Android Studio.
But Expo isn't always the right choice. Here's what I've learned about when to use it and when to consider alternatives from the start.
When Expo Shines
Before diving into limitations, let's acknowledge where Expo excels:
Rapid prototyping: Going from idea to testable app on a physical device takes minutes, not hours. The QR code scanning workflow is genuinely magical for early development.
Standard app features: If your app needs camera, location, notifications, file system access, and similar features, Expo's SDK has you covered with well-tested, consistent APIs.
Over-the-air updates: Push bug fixes and minor updates without going through app store review. This alone can justify using Expo for many projects.
No native build environment: Your team doesn't need Xcode or Android Studio installed. CI/CD is simpler. Onboarding new developers is faster.
The Limitations That Matter
Native Module Requirements
If your app needs to integrate a native SDK that isn't in Expo's ecosystem, you'll hit a wall. Common examples:
- Certain payment processors with native SDKs
- Specialized Bluetooth libraries
- Custom video codecs
- Hardware-specific integrations
Yes, Expo now supports custom native modules with "development builds," but this adds complexity that somewhat defeats the purpose of the managed workflow.
// This is the dream with Expo
import { Camera } from 'expo-camera';
// But if you need something like this specific SDK,
// you're looking at ejecting or development builds
import { SpecializedBluetoothLibrary } from 'react-native-specialized-bt';
App Size
Expo apps include the entire SDK, whether you use it or not. A minimal Expo app starts around 20-30MB. The same app built with bare React Native can be 5-10MB.
For some markets and users, this matters. If your target audience has limited storage or slow connections, the size overhead is a real consideration.
Build Times and EAS Costs
EAS Build is excellent, but it's not free for high-volume usage. If you're iterating quickly and burning through builds, costs add up. Local builds with bare React Native are free (if slower to set up initially).
Specific Platform Features
Some platform-specific features are harder to implement correctly in Expo:
- Complex background processing
- Widgets (iOS/Android home screen)
- App Clips (iOS) and Instant Apps (Android)
- Deep CarPlay or Android Auto integration
Questions to Ask Before Choosing Expo
-
Do you need native SDKs not in Expo's ecosystem? Check the SDK list carefully before committing.
-
Is app size a concern for your users? Know your audience and their constraints.
-
Do you have native mobile developers on the team? If yes, bare React Native might be more comfortable.
-
How frequently will you build and deploy? Factor in EAS costs for high-frequency builds.
-
Do you need platform-specific features like widgets? These are possible but more complex in Expo.
My Current Approach
I start with Expo for most projects because the developer experience is genuinely better. But I make the decision consciously:
- Prototype/MVP: Almost always Expo
- Standard business app: Usually Expo
- Complex native requirements: Bare React Native from the start
- Performance-critical apps: Depends on where the performance matters
The worst situation is building extensively with Expo and then realizing you need to eject. Ejecting isn't terrible, but it's disruptive. Better to make an informed choice early.
Conclusion
Expo is excellent—I use it regularly and recommend it often. But "excellent" doesn't mean "universal." Understanding its limits before you start saves pain later. Ask the hard questions early, check the SDK compatibility, and make a deliberate choice based on your project's actual needs.