When you’ve done mobile development for a long time, it’s pretty easy to overlook the quality and effectiveness of your processes and development. From time to time, it’s good to take a step back and look at how you do things.
Like any other company, we at Showmax always think about efficiency with our development projects - we don’t want to waste time and money on things that don’t work. More importantly, we care about the future and we’re thinking about it all the time. In this case, I want to talk about scaling a business.
We want to be prepared for Showmax’s growth, and that means looking at how we do things now, how we’ll do them when we have twice as many customers, and then five times as many, and so on (fingers crossed!). There are basically two ways to expand a development team - hire more developers or find them internally. But, what about cross-platform development? What can it bring us? What would it cost? What are the pros and cons?
Mission Accepted & First Impressions
Our mission was to literally break it - we wanted to find issues, cracks, bottlenecks, anything that could slow us down.
Learning the basics of RN is pretty easy, but the fun kicks in when you’re looking for some juicy and advanced stuff. The documentation is quite good, but it’s not advanced at all, so when you need more, you have to ask the community or Google it. One downside is that there are a lot of obsolete articles and tutorials about RN - so Google with caution.
Over the Bridge
First, the amount of data traveling from one side to other side and back should be as low possible. What does “low” mean? It depends on the use case, so we decided to define a proof-of-concept app that would suit our needs. The app we built was a two-screen app with a grid of movie posters with vertical scrolling and lazy loading. Our goal was to measure the amount of data we could pass through the bridge, and then evaluate the result. Our assumption was that the bridge would fail - but we were wrong. If you use the bridge in a common-sense way, the data could be pretty big. 6KB of assets data in our case was just fine. Here’s why:
- All communication over the bridge is asynchronous
Reasons Not to Proceed with RN
Our goal was to answer a “simple” question - should we move forward with RN? Our early success was great. Android developer Jakub Broz was working on two screens for just two days, and iOS developer Michal Fousek had everything working basically out-of-the-box. We certainly saw the potential of cross-platform development.
However, our standards are very high in terms of both development processes and their end results. There were some roadblocks we found to be too important, and we decided to not proceed with RN. Here are some of the issues we had:
Our app is mostly table- or grid-based, so users scroll a lot through dozens of items. RN provides FlatList, which is fine for basic usage and a reasonable amount (a few dozen) of items. Unfortunately, FlatList doesn’t provide the same feature set and performance as native components like RecyclerView on Android and UITableView/UICollectionView on iOS. We tried to use multiple 3rd party components that claimed to be able to handle scrolling through hundreds and thousands of items, but none of them worked well enough.
RN provides its own navigation which, unfortunately, is not based on native navigation in either iOS or Android. It’s just a stack of components/views with some basic transitions. It doesn’t look good, feel smooth, nor is it what the user is used to. Wix implemented a package of navigation that runs natively on both iOS and Android, but it’s only focused on mobile devices, and we were looking for native navigation even for tvOS and Android TV. Therefore, Wix’s solution didn’t solve our needs either.
Mobile Devices Over Leanback
Generally, there is better support for mobile devices compared to TVs, but Android TV is not supported at all. A recent pull request has added support for Android TV, but it is still missing any focus handling, so developers have to do it by themselves. On tvOS the focus engine is presented, but it’s missing native navigation.
The ability to debug a developer’s issue is, without question, the most important thing. Unfortunately, the Android debugger has some serious issues with attaching to the app - for us, it worked one or two times out of ten. It’s worth noting that the iOS debugger worked absolutely fine.
iOS Over Android
It’s not a surprise that development for iOS is a bit easier compared to Android, even in native form. Android systems, the various devices and models, and dozens of screen resolutions, have always made things more challenging for Android developers. The same is true for RN, it just looks like iOS is more supported. Android developers should prepare for more complications than their colleagues working in iOS.
Write Once, Run Everywhere
Maybe in the Future: v1.0
It’s important to note that RN is still under heavy development and pretty far from being a stable and production-ready version. Version 0.55 (up-to-date as of this writing) gives us a clear vision of where they are at the moment. Also, the development of all native systems is pretty fast, but RN is still in catch-up and remains a few steps behind. A perfect example is the iPhone X - which you either have to wait for, or implement support for it on your own. Imagine how many devices and changes both Apple and Google do every year.
Lack of Experience
Hybrid Over Fully RN
After quite a bit of experimentation, we realized that, in order to build a great app that would fulfil our expectations, hybrid was a better choice. Whenever there is a screen or logic on which users depend, it’s better to do it natively. All other and less-frequently used parts of the app can be switched to the RN version. We believe that even Facebook (author of RN) has actually done it this way.
Using RN for prototyping is still a good choice - it’s amazing how fast you can build a working app. We also like the instant reload and update of the simulator when you do a small change in the code.
We like RN so far, but we don’t believe it’s ready for bigger businesses at the moment. It can still be used for prototyping and internal app development though, and we’d actually recommend it for just that purpose.
In our case, we can’t have a framework that we fight with next to day-to-day issues. We tried it out, learned a bit, finished our proof-of-concept, and decided to get back to RN in few months to check out their progress. At some point, we’re sure it will be ready. When that day comes, we will seriously consider using it.
Have you worked with React Native? Do you agree or disagree with our findings? We’re always looking for sharp minds and good ideas, and would love to hear from you. Find us on Twitter or drop us an email, and let’s solve some problems together!