Why I Ditched Expo


Andrew Vo-Nguyen

December 1, 2020

Expo is a great third party wrapper for React Native that aids the speed of development and deployment. The Expo SDK provides developers with a lot of mobile native features out of the box and does all the heavy lifting. Another great feature of Expo is the ability use their mobile app to test your app on real devices without having to use Android Studio or XCode.

The reason why I started my React Native development path with Expo was because it was the perfect tool for beginners. Without too much setup I could focus on development and my coding logic. The courses that I did on Udemy all used Expo to teach how to code in React Native. Another reason I used Expo was that I was using a Windows operating system to code. This meant that I could program for iOS without using a Mac computer and without even having a physical iPhone.

It was when I was working on my first mobile project that I started to hit some road blocks with Expo. Although Expo had it's own implementation of Push Notifications, it would only work while the user had the app open. I needed the functionality to send Push Notifications to users as a background service, and this is something that Expo simply could not accommodate.

My next roadblock was that a lot of React Native third party libraries required the user to be using the React Native CLI or to eject their Expo app as a minimum. Using Expo meant that you were generally locked into their ecosystem of features and if a feature was deployed by the React Native Team, it would take time to be eventually pushed through to Expo.

Lastly, Stripe payments are heavily limited using the Expo managed workflow. What's the point of making an app if you can't suck some funds from your users? 😆. This was the real deal breaker for me. Expo does have a stripe payment module, but is based on using the bare workflow.


I have to give credit to Expo though, as they are very up front with their limitations. I just chose to convince myself that those limitations didn't apply to me initially.

For my current mobile project I decided to use the React Native CLI for the first time. The set up was tedious in many ways so I would recommend allowing ample time to set up both the Android and iOS configurations correctly. Always use version control in case you stuff up a configuration. React Native's getting started guide has a great step by step guide on how to configure the native folders. Even some libraries such as react-native-vector-icons require a lot more manual work to get up and running.

I think as a developer it is important not to stray too far away from the native code by using wrappers or helper libraries. These libraries hide too much of the implementation to make the developer's lives easier however they make us too reliant on them. This is an ironic statement because the basis of React Native is to hide the need to code in Swift and Kotlin. I noticed while using the React Native CLI for my current mobile project that I felt less burdened and my ceiling of possibilities (in my mind) was much higher than when I was using the Expo managed workflow.