Breaking Down React Native, E06: Full Transcript

Updated: Apr 21

For years mobile development teams split their talent between Android and iOS in a way that was costly, slow, and inefficient. Then, in 2015, Facebook developers came up with a cross-platform solution called React Native.

In this episode we follow our Wix mobile engineering team as they adopt React Native and work with it for several years while building the official Wix app. Listen to Lev Vidrak and Omri Bruchim as they take a deep dive into Reach Native:

You can also listen to this episode on Apple podcast, Spotify, Google or on Wix Engineering site. And you can also read the full episode here:

Hi, welcome back to The Wix Engineering Podcast. I’m Ran Levi.

Omri: I’m Omri. I’m leading the mobile platform at Wix.

When I joined Wix around 3.5, 4 years ago, Wix was at the stage where the company brings everyone to build the website, kind of a stunning website, where you can manage your business beside creating a cool website on the web.

What it means is that if you have a restaurant, for example, so you can build a cool website in a few minutes to get a reservation, to book a table, for your customers to make a – kind of pick-ups, takeaway... And then we decided that we want to have the same functionality for the owners on the go.

Almost as soon as he’d arrived, Omri was tasked with building Wix’s new mobile application.

Omri: But then we decided that we have another part for the application. So we want to allow both [. . .] the owner of the business to download the app and create a website and manage it, but moreover, we want the customer themselves to download the Wix app, [. . .] we want customers and owners to interact with each other from the app. And not to do the conversation via Whatsapp, and transfer money from another application, and book sessions from another application, but all of this functionality from the same application. So this is the reason we created the Wix app.

In order to build the mobile app, Wix would have to build out their development teams.

What you want is to create two applications - one for iOS, the second one for Android - and you want to create a website. So basically you need a web developer, and you’ll probably want a server developer, and to create iOS and Android applications, you need an iOS developer, probably familiar with Objective-C or Swift, and the same for Android, probably Java / Kotlin developer, and then they create the first application. And then you want to recruit more people because you want to grow your application, create more flows...

Maybe you can sense an issue here.

Lev: So as you know, in the mobile world we have the Android operating system and the iOS.

This is Lev, an Android developer of ten years.

Lev: The problem in this approach is that you basically need to implement the same functionality, adjusting to different – the same business logic (meaning functionality), in two different languages, and you can’t share code between the apps and you can’t share with people.

One alternative to writing multiple implementations of the same app is to use a cross-platform solution--one that allows your app to function on both iOS and Android, equally.

Omri: The cross-platform idea for mobile, it’s not new. [. . .] Xamarin, Ionic, PhoneGap, all these friends...

The appeal of cross-platform is in its efficiency.

Omri: But most of them are based on “WebView”, meaning they are trying to simulate native views and not actually using the Android and iOS SDK. When you are doing this, you are not getting the performance that users are used to with native apps.

They right away feel there’s something wrong with the app.

For a novice developer, or a small team working on a low-stakes project, cross-platform development may be cost-effective. But at a real organization like Wix, what’s lost in performance is simply unacceptable. The user feels it--the sacrifice in quality isn’t subtle.

So, for years, building for iOS and Android was simply a necessary evil in the industry--inefficient, perhaps, but a part of life. That is, until 2015, when a developer named Jordan Walke came up with a way to solve this problem--to bridge the iOS-Android gap. It was developed and released under the name “React Native.”

Want to go deeper? Watch Lev Vidrak's talk "Deep Dive Into React Native":

Lev: The React Native is a framework by Facebook, which - they decided to build a framework for cross-platform development in mobile. Basically the idea is that a React Native developer will implement this business logic in JavaScript.

The beauty of React Native was in how it combined the efficiency of cross-platform development with the performance of native development.

Lev: Under the hood, the JavaScript API will invoke methods from React Native code, which is implemented in Java or Objective-C, that will call, eventually, the same Android or iOS SDK. And there is another layer that glues the JavaScript and the native code, which is written in C++.

In other words, you input standard Javascript into the system, and it spits out native iOS and Android code.

Omri: It means you write your business logic once in JavaScript and you create the application also once because the UI most of the cases for iOS and Android is the same.

Then you can use the business logic that you wrote in JavaScript and make a shared library and do the same for the web. I mean you don’t need to create the same logic twice for the web and for the mobile because in most of the cases, it’s the same.

The sheer cost savings of having one React Native team instead of two separate iOS and Android teams is, on its own, a strong incentive for any business. But that incentive is only worth anything if you can make React Native work for your organization - and that is no easy feat, because much like any other piece of software, React Native has its fair share of drawbacks. And on top of those drawbacks, there’s also the matter of how to adopt a new framework in the context of a large organization with an existing cadre of developers with varying skills and mindsets. In this episode, then, we’ll follow Wix’s story of adopting React Native, and discover the lessons learned from this experience.

Where was React Native at the time when you guys started working with it, in terms of how old was it, how mature was it as a platform?

Omri: I remember it was, when I arrived, I think 2016.

In 2016, when Wix began developing their mobile app, React Native was just one year old. Now, to those of you out there who are developers: have you ever heard of a software product that was finished and polished after just one year? It’s pretty rare--usually it takes years to upgrade, fix and work out the bugs in even a well-designed program.

Lev: React Native was in a stage that no one knew why to choose this arbitrary framework to build your mobile application. It was super new. It was not mature enough.

I mean we took a bet big time about React Native. When you think about it today, I think that it’s not responsible [laughing].

They ventured where few developers had gone before, and didn’t look back. The path would not be easy.

Omri: There were no big companies in production with React Native. [. . .] A lot of React Native users are building some proof of concept. We wanted to build a real product.

The first issue that arose from using such a new framework is that so few people knew how to use it.

Lev: It’s not easy to recruit someone to handle React Native, and I’ll explain to you why. Because there is no such – a lot of React Native developers out there, especially in Israel or in Lithuania, for example, which is another country where Wix is hiring developers, and we are mostly hiring native developers - iOS or Android developer - and then kind of transfer them to React Native.

A one-year-old framework simply won’t have the adoption that older, established frameworks have built up over many years. But even developers who knew of React Native, and had the ability to learn it, weren’t.

Lev: I think that the perspective today about React Native is that – because of the past - that React Native performance is not that good. So people are a little bit afraid of going into career of being a React Native developer.

So not many developers knew React Native. Those that did, on the other hand, were not always attracted to it for the right reasons.

Want to know more? Watch Omri Bruchim's talk "React Native at Wix: Architecture For App in Scale", React Advanced London:

Omri: I think it’s just an easy entry point. If you want to start building apps with React Native, you can do it in – I don’t know - in three days you’ll will build an app. It’s just easy. [. . .] The easy entry point to React Native is a good thing and a bad thing. It’s good because it’s obvious, yeah, and a bad thing because it brings lots of not very good developers.

Lev: We think that because React Native is super simple to get into it, you just need to learn JavaScript, you can write your first mobile application in a few days, that’s why we saw a lot of React Native developers that are not experienced enough.

There are junior developers that claim that they know React Native. But they don’t know for real how everything works behind the scenes. They don’t know the technology deep enough.

Omri: Eventually the perspective about React Native that it’s not a good framework for a performance. But it’s not because of React Native. It’s just because developers are not very good and there are lots of them who are using React Native.

So instead of hiring lots of new people, the company focused on training existing staff in the new system. Luckily, React Native is just Javascript, and you can’t throw a keyboard inside of Wix headquarters without hitting ten people who can code Javascript.