Skip to content
himture.dev

Why I used bare React Native, and why I use Expo now

I chose bare React Native for a driver app in 2023. Shipping two Expo apps since then has changed how I'd approach the same decision.

1 min read#React Native#Expo#Mobile

I used bare React Native for the an2 cabs driver and rider apps in 2023. At AfterBoards, I ship two apps with Expo.

Both choices came from the requirements I was working with. What I'd do differently now is check an Expo development build against those requirements before taking on the native projects myself.

Why I chose bare React Native

The driver app needed background GPS tracking, floating ride-request notifications, and native modules. Those were requirements I couldn't drop: drivers still needed to receive requests and report their location while using other apps.

I chose bare React Native so I could work directly in the native projects. That gave me control over the integrations and a build I understood.

At the time, I didn't have an Expo setup I trusted for that combination of requirements. That was the basis for my choice; it doesn't mean every app with background location needed to make the same one.

What I use at AfterBoards

Expo development builds let me use custom native code and third-party modules alongside EAS Build and over-the-air updates. That covers the native work I need for the AfterBoards apps without requiring me to manage every part of the build myself.

I still need to understand what runs on the device. But I spend less time maintaining native project files, which matters when I'm the only engineer responsible for two mobile apps as well as the web products.

The maintenance I took on

With bare React Native I owned Xcode and Gradle upgrades, native dependency conflicts, signing, provisioning, and changes to native files during React Native upgrades.

That work can be worth doing when the control is useful. It also keeps turning up between feature releases. I would want a specific requirement before taking it all on again.

How I'd make the decision now

For a new app, I'd start by listing the native features it needs and trying those in an Expo development build. If one didn't work, I'd investigate that limitation before deciding to manage the native projects directly.

I wouldn't choose based only on what worked for me in 2023. The requirements are worth keeping; the tooling choice is worth checking again.

  1. I explained the architecture badly and my team built the wrong thing

    At an2 cabs, an incomplete explanation cost my team two days of work. I changed how I checked an implementation after that.

All writing

For a role or a project, email hi@himture.dev, or see my freelance services.

résumé, PDFGitHubLinkedIn