At Rocket Insights we have no shortage of developer talent across iOS, Android, and Web platforms. It was only recently, however, that we were presented with the opportunity to explore a fusion of these traditionally separate teams under the umbrella of our first production-ready React Native app. The appeal of React Native is obvious and, perhaps, a bit tired. Share source code between platforms while expanding your resource pool and drastically decreasing your time to delivery? Yes, please. The theoretical potential of this Holy Grail has been torturing developers for years and, continuing with the same analogy, many have died in the pursuit of its fortification. It should be no surprise, then, that we engaged with eyes wide open and a limited definition of success despite advocacy from some (very public) heavy hitters.
Dipping A Toe In The Water
One of the more ubiquitous adages in engineering is to “implement now…perfect later”, and we found there is no better path of adherence to this wisdom than using Expo. Expo provides a highly accessible all-in-one solution for building and deploying React Native apps while requiring essentially zero knowledge of the actual native platforms. We knew up front that this would not be our final destination as many of our clients require deep integration with proprietary SDKs. However, the appeal of building the shell of our React Native app in (literally) minutes while passing rough deployments between devices via QR Code was too enticing to deny. Ultimately we ended up building well over 90% of our presentational components within Expo before ejecting and proceeding with a vanilla React Native architecture.
One of the benefits of starting with Expo is that it provides a handful of modest opinions in areas that otherwise suffer from fragmentation within the React Native community at large. There is no better example of this than navigation. A few blogs circulating from late 2017 captured the pain points of trying to understand a) why there were so many navigation options; and b) which option best suits our immediate needs. I have casually coined this as “The React Problem” in my personal developer circles, meaning that there is a tendency to conflate a modular approach to the ecosystem with a rigid agnosticism regarding what peripheral libraries belong in the stack. Cue the fragmentation and noob misery.
Native Developers and Custom SDKs
As much fun as it was to translate the design into presentational components, the true test of the platform was working with our native development team to integrate our client’s custom SDK and make the app actually do something. The ease of this process was arguably the biggest surprise we encountered. Within a few short days we were rapidly working in tandem, implementing needed adjustments in our relative domains not unlike the client-server relationship familiar to web developers. Suffice to say that we found the provided tools for native integration (Async Storage, Native Modules) were not only adequate but also surprisingly pleasant to use.
Our experience with React Native was a resounding success, though this statement does come with an important caveat. As mentioned above, we have a deep talent pool at Rocket Insights in both web and native development. In hindsight, it was very unlikely for us to encounter a challenge that required expertise beyond our internal team. Because of this, I think it would accurate to say that we are very much the target audience for the React Native platform. There are excellent tools (such as Expo) that can bridge the native gap for teams comprised of predominantly web talent. But any serious commercial app will likely need ready and dedicated access to both talent pools in order to succeed.