I started writing this article at the end of last year when my experience was still fresh but never finished it. Now I am coming back to the topic inspired by a visit to Airbnb last month (thanks at Fan, Xiaowen and Matt). After talking to people at Airbnb I learned that they are retiring their react native efforts (more on that here). I worked a lot with react native during my last job at an Invest-Tech startup. Initially, I was very enthusiastic about what was possible with react native, but with time there came doubt and the realization that it is not the holy grail it appeared to be at first. This is probably true for Cross-Platform technology in general.
When I joined the company it was very early stage and web was the only supported platform at the time. A mobile app was requested by users but not planned yet. After some discussions with our CEO and CTO, I started the project to launch a mobile app version of our product. The promises made by cross platform technologies proved to be very intriguing for a boostrapped startup.
Look at these promises:
Titanium: “Build great mobile experiences faster”
Xamarin: “Deliver native Android, iOS, and Windows apps with a single shared .NET code base.”
React Native: “Build once, run everywhere”
Ionic: “Build amazing apps in one codebase, for any platform, with the web.”
Phonegap: “Build amazing mobile apps powered by open web tech.”
That sounds pretty exciting. Using the same code everywhere makes sense from a tech as well as a business perspective. No need to hire developers for each platform. No need to handle bugs in two codebases and the list goes on. Hiring developers requires time and costs money. Everyone knows time is money which means it actually costs money money.
Making the decision
Our team had a dislike for web view based web apps (they just don’t feel real) which narrowed the list down a little bit. And left us with Titanium, Xamarin and React Native. In the end we decided to go with React Native for simple reasons:
- It offered the promise of producing a native app and was flexible for extensions
- Airbnb decided to use it (And they know what they are doing, right?)
- It was backed by a big company (Facebook) so we assumed its gonna stick around
- It’s free (Did I mention already that we were bootstrapped?)
- I saw the presentation when it was revealed on React Conf and thought it was THE SHIT! (A little bias is unavoidable)
The premise for using react native was to support iOS as well as Android with one codebase. We assumed that there would be hiccups, so we decided to focus on iOS if necessary. This was sensible as our data showed that the majority of our users used iOS devices.
The Experiment Begins … and succeeds (seemingly)
Our experiment started. While working on the designs I started to familiarize myself with react native. I soon was supported by another developer as well. The setup felt a little bit hacky compared to working in xCode but it worked. You wrote JS code and magic turned it into a working iOS app. It’s pretty easy to get started and pump an app out.
In fact, I never got a working app ready this fast. The speed was definitely closer to web development compared to what I’ve seen before. (Disclaimer: I have some experience with iOS development but are by no means a seasoned iOS dev, so this might be different for seniors) Of course it took us longer than expected to finish the app but we released in September 2017 on iOS. It worked and was perceived well by our customers — which is the most important thing.
With hindsight I must admit, there are several drawbacks one should consider before using react native.
React-Native is bleeding edge technology
React-Native was pretty new back then. While a lot of the features made you go “wow”, you could also feel that it had some way to go. I’m sure there were a lot of improvements since then but to be honest there is still a reason the version number is a 0.x. We knew that before hand of course. I remember when we compared alternatives, we listed “beta” on the negative side for react-native. Yet, as hyped as we were, it was a very naive assumption to think that this would not cause problems further down the road. Problems had already begun to turn up with more developers working on the project. Instead of “checkout and go” it was often more like:
- Get a weird error
3. Research it on stack overflow
4. Try suggested fixes
5. Out of frustration try a restart
6. Oh yay it works again
The real overhead came with react-native version updates. There was no proper update procedure. Later, react native introduced a git-based updater, which caused less problems. However, with the first versions, an update overwrote files including the changes you made to them. With that, an update in turn meant a lot of copying & pasting. Also facebook was pretty ruthless in deprecating functionality. Of course they were… we were working with a beta!
Cross-Platform is more a wish than a reality
React Native is not really as expandable as you might think
This also brings us to the next problem. Bridge libraries and other plugins will create dependencies on external code. Together with Facebooks habit of ruthlessly updating react-native you will more often than not come to the situation where an update breaks your dependencies. Creating the situation where you will have to decide between the following options:
- Wait for these dependencies to update their code (might never happen)
- Fork dependencies and update by yourself according to your needs (after some iterations that basically means you did a rewrite)
- Contribute if its open source (you cannot really do that for all of them)
- Don’t update react-native at all (which just delays the problem)
None of these options is really sustainable.
What about code reuse on Web?
One might argue we didn’t really try to use react natives full potential by reusing the codebase also on web. While it might be suitable for some use cases to do that, it’s not a good solution in most cases. For a lot of products, users use the product very differently on web vs mobile. To provide the best experience on all platforms this should be reflected in design and functionality. This also means prioritization and thus the feature set will be different across platforms thereby, making code reuse require plenty of additional overhead or completely impossible.
Don’t get me wrong, React Native is a great technology and it’s amazing what it accomplished. When I look back, I realize that the decision to use React Native was still the right one. Going native would have forced us to hire native developers, for which we had neither the time or the resources. Given that time to market was one of the most important criteria at that time I don’t see making any other decision leading to the same or early release date. However, the experience allowed me to grow beyond my naivety and will make me definitely think twice the next time I consider React Native for a business. Since this experience with React-Native some time passed and improvements were released.
One of the prominent efforts of improving the usability of React Native is the Expo.io project, which by now is also recommended in the official React Native documentation. Expo provides a set of development tools and native integrations, that make the implementation of a lot of things easier and reduces the aforementioned problems in these cases. But the approach of Expo restricts expandability even more. Using native code or features that are not out of the box supported by Expo requires you to disconnect your app from expo. This makes Expo basically only useful for projects where the scope is known beforehand and covered by expos feature set. The fundamental problems I mention in this article are still present, which is also the sentiment of airbnb’s post I mentioned at the beginning of this post.
With this in mind, think twice if this is the right technology for your project. It might be a good place to start, like it was in our case. But the idea that you will have only one codebase for your growing business stays a dream as of now. For bigger projects there is still no way around full native app development to provide the best experience to users but also from the perspective of complexity. That said, there is definitely a place for the technology. For smaller projects or prototypes React Native or Expo is still a good solution and I think we will see more and more projects using cross platform technology. Also other interesting frameworks pop up overtime — maybe Flutter.io will change the cross platform game (haven’t tried it yet).