Being Fearless: Our Move to React Native

by Guy Eldar, Mobile Software Engineer

They say that any software engineer who wants to stay in the game will have to go through a radical technology change once in a decade. That means they will have to ditch their old‐school, now‐deprecated, so‐90s technology they have been working on over the last years–and boldly go where not so many engineers have gone before.

Among the well known “technology‐chasms” were the mass‐migration from old COM style VB/C++ to the .Net framework, the vast adoption of JavaScript and PHP as dynamic web pages were introduced in the mid 90s, and above all, the oh‐so‐sexy 21st century “mobile genesis”. The latter began with technologies like J2ME, WAP and Symbian. Once the first smartphones were introduced, new technologies emerged–Cocoa, Java for Android (Dalvik), Adobe AIR, Swift, etc.

This February, we made a big decision here at HoneyBook. It’s one of those fate‐changing decisions where the end user probably won’t notice anything different, but for us engineers, it was a game changer; the beginning of a new era. And I personally see it as a mini technology chasm every mobile developer should cross.

What did we do, you may be wondering?

We built our new mobile product with React Native (RN), ditching the mid-80s Objective­-C in favor of the fancier JavaScript.

Now, web developers won’t really understand what the fuss is all about. JavaScript has been around for the last ~20 years, and we all know its strengths (and weaknesses). Is it really such a big deal?

Well, yes. As a seasoned mobile developer who coded only Objective‐C (and C++) over the last six years, I can easily bring up a few inherent difficulties in the current state of things: ­

1. Continuous deployment is practically impossible due to the App Store’s rigid app submission policy. Apple’s official standpoint on this matter is that we, as developers, must plan our rollouts so we can allow three weeks(!) for an app to go through the approval process. ­
2. Talent sourcing is hard! Even though the much more modern and robust Swift has been introduced, the vast majority of iOS apps are still written in Objective C. Considering the fact that only iOS devs are writing apps in Objective C/Swift, the relevant talent pool is very limited. ­
3. As Android aggressively wins the mobile war, (Android captured 80% of 2015 Q4 worldwide sales), code­sharing between platforms is needed more now than ever before. Currently we have two different technologies, two separate dev teams–but with the same client side business logic. And that doesn’t make sense. ­
4. iOS apps are not as flexible and dynamic as Android apps. Interaction with JS code inside web views is VERY limited.

I must admit that a month ago when I heard about the possible transition to RN, my original reaction was very instinctive: Why the heck do we need to go through this enormous learning curve, adopt a technology that barely reached version 0.17, and deal with countless unknowns along the way?! It just doesn’t make sense. I’m writing Objective‐C faster than I write in Hebrew or English. I can write our app in 1/10 of the time, and better!

Fast‐forward one month. During this month we played with RN, experimented, argued, benchmarked, threw mud at each other, discussed, fist‐fought (kidding), got some tips, and ultimately agreed to choosing React Native.

In our case, the game changers pretty much correlated with the pains I’ve listed earlier:

1. HoneyBook is not a web­-first company. It’s a web­-only company. Among others, that means continuous deployment is our bread and butter. Our SLA for hotfixes is ASAP. Not a second later. We also use this technique to quickly make build‐test‐fix iterations on features. Therefore, we couldn’t just come up with a technology that will enable us to roll out production builds in a matter of days, best‐case scenario. With RN, we’re able to roll out JS builds on the fly, without going through App Store at all.
2. We have the best JS engineers on earth. Why not use them for mobile as well? No doubt they will still have to learn all about the OS, various mobile UX patterns, and proprietary features, but it will be MUCH easier. In other words, it would be a bitter mistake to have one team work on Objective‐C, while all other teams hack their way with JS. On that point it goes even further–‐it’s a cultural gap. Just imagine how alienated this Objective‐C team would be as all other teams around them eat and breathe JS.
3. We’re currently starting only with iOS, but Android cannot be ignored. Therefore, business logic code‐sharing between the two platforms never looked so good. With RN, we will still need to build a proprietary UI layer for each platform but the BL heavy lifting will reside in one common code base. Will definitely save us tons of time and effort.

Recapping with my thesis from the beginning of this post‐‐long term, React Native will become one of the next groundbreaking technologies that end up changing the game. Up until now, the software development landscape somehow resembled another, well known, great alienation‐‐between the two dominant theories in physics‐‐relativity and quantum physics. Each one works perfectly in its own playground, but try to merge them into one unified theory, and everything collapses. For me, React Native is the missing link that unifies mobile and web development. When you zoom out and think about it, it doesn’t make sense that web developers won’t be able to write mobile apps and vice versa.

My projection is that three years from now, the standard way of developing mobile apps will be with real native hybrid technologies like RN. It still has a long way to go. But with such a fast‐growing community of developers, I’m very optimistic and excited to take part in this journey.

Crossing this technology chasm is challenging for experienced mobile developers, but we should be fearless and ambitious, exactly like we always aspire to be here at HoneyBook.