Our React Native Experience

Ben Sandofsky, an iOS developer I have immense respect for, recently tweeted about why React Native is “stuck at its niche 2.6% adoption.” His negative opinion got a lot of traction, so I wanted to share our experience at Healthie.

In 2018, we rebuilt our native iOS and Android apps (which used Swift and Java respectively) in React Native. It was one of the best engineering decisions we’ve made. Here’s why

1) Given our size at the time, it did not make sense for us to have more than one iOS or Android developer. This meant those devs were working in isolation. React Native let us set up a (mostly) shared codebase with multiple people working on it.
2) It allowed our web engineers to understand and give feedback on the mobile app code. We use React for our web front-end, and once we switched, our web devs were able to help mobile out with code reviews and trouble shooting.
3) While you definitely can’t just re-use web React code in React Native, we were able to share libraries and parts of code between our web and mobile applications.
4) 90%+ of the code can be shared between iOS and Android. No more separate git repos per mobile platform.
5) Code push. At the time, we sometimes had to iterate quickly on the mobile app. Code push allowed us to quickly release hot-fixes and improvements without always needing to go through the (at the time slower) App Store review process.
As Ben mentions, 1-5 could all be accomplished via web views, so why not just use that? 95% of our mobile app lends well to React Native. However, parts of our app (Apple Health syncing, video chat, etc), needed to be done in native code. React Native makes it easy to bridge out to native where needed. In addition, there are existing open source libraries for some of those bridges. This is a huge advantage versus a web view approach.
React Native is definitely not right for every type of app or team, but has been a great fit for us given our needs. I don’t think it makes sense to dismiss it out of hand.