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.
Lev: Wix is a web-oriented company. We have lots of web developers, and actually it works. We can take a web developer and after a pretty short onboarding, he will be able to write for the mobile app.
So, lesson 1: When it comes to adopting a new technology, hiring new developers is not always the right solution. Sometimes there are not enough skilled developers out there, or if there are - they might not have the right mindset you’re looking for. In such cases, training the existing developers might be an easier solution. The same ease-of-use that attracted novice developers to React Native made it really easy to train experienced developers in the new system. Wix engineers learned its intricacies in weeks, even days. Even developers like Omri, who didn’t already know Javascript, could pick up what they needed to know in a relatively short time frame.
Omri: I came from iOS background. I didn’t know JavaScript before I joined Wix. It’s a funny fact. I started learning JavaScript in my first weeks and then I dropped into the React Native world.
With a team of newly-minted React Native developers in place, the project was now underway.
Did you encounter any problems getting used to it in the early stages?
Omri: Profiling, debugging. I can say from my perspective that at the beginning, there was a big – vague around React Native regarding performance. We didn’t know if the performance issue we had was related to React Native itself, to our code, or to something that we are not able to analyze because everything was new.
Performance issues, on their own, were problematic enough. But not understanding the sources of those performance issues was even worse, because you can’t fix what you don’t know.
Omri: We didn’t know how to analyze things. We didn’t know how to debug things because it was the beginning of React Native.
In addition to issues of performance and analysis, there were entire components missing from the framework--features any developer would expect that simply did not exist.
Omri: We need, for example, a testing framework and there is no testing framework for React Native. The test is that you actually turn on the device and click on buttons. So we had to build our own solution which is called Detox.
Lesson 2: a crisis is also an opportunity. Working with such a nascent framework, at times, was like living in a house still under construction. But this need was also a catalyst for growth: in their case, on top of building an entire framework for testing React Native code, the Wix developers built a navigation tool to replace the one that came built-in.
Omri: So we had to invest a lot of effort in infrastructure of our app and React Native.
Did you guys face any challenges in terms of scaling and how the project and the scope of it changed over the course of time?
Omri: I think the most challenging part was to scale the application both from a number of developers working on the application and the amount of code or let’s call it the huge code base that we have today.
So we had to change a little bit the architecture of the application and we made a shift from standard React Native structure, with the same repository of iOS and Android, and did something that’s a little bit different. It came to allow for each team to run independently.
Lev: Production monitoring.
Omri: Production monitoring, yeah, the tools... I think that’s one of the biggest change that we did through the years was the open source.
React Native was open source from day one and we want to contribute to the community back. So kind of a rule of thumb, which – every code that is not Wix-related, we tried to make it open source.
So it brings us to a place where we have today, I don’t know, 20 - 30 libraries that are open source. Part of them was really common in the community, like React Native Navigation, Detox, Detox Instruments, Remx, UI Lib, React Native Calendars, a lot of libraries that most of the community use every day.
The disadvantage is that we have a lot of libraries that we are even not using anymore and this is a challenge. It’s a challenge that we are facing today and we need to invest time and think how we’re going to maintain them or maybe to move them into the community because at the end you want to have a maintained library out there in the community and not just to have an open source library by Wix.
In 2016, Wix bet big on React Native. Maybe it was irresponsible to do so. After months of challenges, the dev team had come to realize that all the benefits of using a nascent React Native framework also came with some serious costs.
But then the mobile app was completed and it didn’t look like those lazy, poor performance apps that people came to associate with React Native.
So can a well-organized effort behind a well-written React Native app really cause an app to perform as well as a well-written native app? Like were there any performance issues that you can’t get over or is it really the same?
Omri: Interesting question. It’s kind of – you can hear a lot of different opinions about it. I think that yes, you can have a fully animatable, interactable application with React Native and there are some people that can even better perform it from native application, pure native application.
But you need to be expert with React Native to do it and I think it’s like any other technology.
I have to say that it depends, because there’s a lot of companies that use React Native for a part of their application. So if you want to create a login screen or a simple UI for the home screen, you can do it with React Native. But as Lev said, if you want to create a super deep technology with hardware interaction or something with Bluetooth, or video processing, you can create native code and just use React Native for the view. That’s another option, but I agree, React Native is not necessarily to do with all of the applications out there, it’s specifically for companies that want to save time, run fast and, maybe, it’s easy for them to bring JavaScript developers.
CONCLUSION
Which brings us to lesson 3: there are no miracles. Ultimately, React Native is neither the miracle cure that it sounds like at first glance, nor the low-grade solution for novices to build lousy apps. It was an effective tool for the right teams in the right situations--teams who value speed, continuous development, efficiency, and have the resources to back up their front-end developers with native ones.
Omri: Another point in this area, I think, is that to build a React Native application, you need a few native developers and it’s kind of a must. It’s a must because not everything is perfect with React Native. We need to say, there are cases where you have a performance issue and you need to go a little bit deeper and understand what’s happening and why. Maybe to fix it in React Native itself. Maybe to analyze if you are using a third library or kind of an open source and open an issue because you find an issue in iOS side of React Native. Not everything will work and you need to be able to analyze it, to debug it.
As a JavaScript developer, you can’t do it. It’s even not an option. So better for you to have at least iOS and Android developer.
So, to recap - what did we learn from Wix’s experience with React Native? Firstly, don’t just go about blindly recruiting developers experienced with the new technology you want to embrace: sometimes, there’s real value in training your existing developers. Lesson 2: don’t be afraid of changes! A change is always an opportunity for growth and development. And lastly, there are no free meals and no easy solutions. Every new technology comes with it’s own drawbacks and challenges, so plan those transitions with care.
Today, React Native looks a lot different than it did when Lev and Omri began working with it in 2016. A lot of bugs have been smoothed out, and missing components have been added.
Lev: For example the startup time. [. . .] Facebook realized that there are some bottlenecks that they have to fix and rewrite. So they developed a new JavaScript engine called Hermes which now with Hermes, the loading time, the startup time of the application on Android is much faster. [. . .] So the framework is evolving to the right direction.
When Wix first began using React Native in 2016, no major company had released a fully-functioning app with it. Today, React Native is being used at Tesla, Bloomberg, Uber, Skype, and, of course, Facebook.
Lev: So it’s a question if five years from now – or let’s think about 10 years from now companies are still going to still have native applications, so I don’t know. I hope no because there is a cool framework out there that can do the kind of merge between them, like React Native.
That’s it for this episode, thank you for listening.
For more engineering updates and insights:
Visit us on GitHub
Subscribe to our YouTube channel