ExpoKit might not be so scary
Charles
3551

I really love Expo and I think it has saved countless hours of development for me on various projects.

However, the initial ejection and getting the app to build again is actually one of the simpler parts of living with an ejected Expo app.

The biggest challenge about ejected Expo apps is keeping them up to date. For example, it took us 1 month of development time to upgrade from Expo 23 to 24, and we’re not unfamiliar with the process as I’ve personally been updating ejected Expo apps since 16 till 23, each one taking anywhere between 1–5 days worth of development work. On the 23->24 update, after a month of work, there were still issues that we couldn’t solve, even after reaching out to Expo’s team.

Things that we had not touched had stopped working, or the behavior was completely changed. Files and folder structures were changed, as well as all of the content of `build.gradle`, and ios project file with no information on what is changed and how to update currently ejected apps other than running diffs on dozens of files and fixing build errors one by one. We ended up giving up after a month of trying and switched to `react-native init`.

I still love Expo and respect their team and their efforts, and I use Expo for most projects that don’t have to be ejected. But, for a project with tens of 3rd party libraries, it can be a pain to keep an ejected Expo project alive with a small team of developers.

The current approach is that after each Expo update each individual developer has to eject a new expo app and diff it against their current project.

I realize it’s a very hard problem that Expo is tackling, but one solution that comes to mind would be if Expo kept an example of an ejected app on a repo, and with each update pushed a PR that demonstrates how to bring that ejected app up to date.

Also, it’s worth noting that this is not necessarily true:

  • Can add any react native library

Depending on how complex your app is, there’s a chance that some of ExpoKit’s dependencies conflict with a package that you’re trying to add. An example is `react-native-background-geolocation` and ExpoKit could require a different version of Google Play Services Location, and you might have to end up forking 3rd party libraries and use hacks to get them working along ExpoKit. Obviously, these hacks could stop working in the next Expo update if, for example, ExpoKit updates their version of Google Play Services Location.