People see React Native as a write-once-deploy-anywhere solution, potentially speeding up development for applications that need to be written for both iOS and Android and making it possible for Web Developers to easily write native applications, but is React Native the best choice for your next project?
React Native is a native version of the popular web library of the same name and its main purpose is to bring the power of React to native development. React Native components are pure, side-effect-free functions that return what the views look like at any point in time. For this reason it is easier to write state-dependent views, as you don’t have to care about updating the view when the state changes since the framework does this for you. The UI is rendered using actual native views, so the final user experience is not as bad as other solutions that simply render a web component inside a WebView.
The best way to evaluate a new technology is to use it. We gathered together a team of four developers native in programming iOS and Android, to plot, scheme and research React Native. Here was our action plan:
The source code of the Twitter Client we created, both for iOS & Android, is available in our Spikes repo: https://github.com/novoda/spikes/tree/master/ReactNative/ReactTwitter
Hot Reloading is similar in concept to Instant Run on Android. Every time a source file was saved, the changes were deployed immediately on the device where the app was running, thus greatly expediting the feedback loop. Although it works better than Instant Run, it still breaks from time to time, requiring a restart of the app.
We cannot deny the fact that many times we have to resolve the same problems as others did before us, and that’s why we decide to make use of third party libraries, so we don’t have to reinvent the wheel. Whereas there are plenty of libraries to chose from on iOS and Android, we cannot say the same about React Native. There are definitely a considerable number of libraries, but as we experienced, some of them are not always working as expected.
One more thing worth mentioning is that React Native has a two week release cycle. While it is good that they bring more features and push the framework towards maturity, often they bring breaking changes as well, maybe in a “move fast and break things” fashion specific to Facebook. These changes sometimes where a burden to overcome, as we had people spending a lot of time fixing things when upgrading the framework. But we can’t deny that this isn’t expected, as the framework has yet to reach a stable status, still being under heavy development.
With these pros and cons, the state of the tools, the lite documentation and uncertainty of libraries as it is in the present, we feel that by using React Native you can actually save some time compared to traditional native development. In particular, according to the developers we have interviewed, on real projects one could save around 30% of development time. Of course this is just a high level estimate and depends on multiple factors, the most relevant is to have person with web-development knowledge in your team, as discussed previously on this article.
At this point, you might think that React Native is another “write once, run anywhere” framework, like Titanium or PhoneGap, but you would be wrong. As Facebook very clearly states on their blog post, they acknowledge the differences between platforms, so instead, their goal is to bring the paradigms of React, which is very successful on the web, to native, while having the same set of engineers working on whatever platform they choose. They call this approach “learn once, write everywhere”.
Starting to work with a new platform like React Native, one of the first things we did was to explore the available documentation, both official and from the community. We found that, while Facebook is putting effort in keeping it up to date, a good amount of the components are not well documented for the current release of React Native. This is even more evident if we consider community-created articles, given that these are often obsolete after a few releases of React Native.
When the documentation wasn’t satisfying enough we tried looking up things in the React Native source code, however we found ourselves disappointed by the poor quality of code base. Probably in a rush to push more functionality to the framework, they also sometimes overlook how clean the code is.
Speaking about the core React Native library, we found many of the main components being still in a Work-In-Progress status. The official documentation regarding how to implement some key features (like navigation) changed the suggested component in different releases of React Native. The migration from one to another of these components is not a straightforward task and it requires some not-negligible work.
Of course it is possible to use third-party components, but the selection is not comparable with the number of community-generated libraries that we can find for iOS or Android. A big problem with these components is also the fact that the compatibility and support is not guaranteed with future React Native releases.
When the iOS or Android SDKs are updated, it takes some time for React Native to integrate these newly introduced APIs into their core library. The React Native team is pretty fast to update in order to allow developers to use new APIs, but the priority is given by the amount of requests that every API gets. It can happen then, that some new features will be included in the next React Native release, while some others are not going to be included at all.
We found that a good use case for React Native can be found in applications that need short time support, for example an app for a one-shot event like a concert or a conference. These kind of apps could also benefit from the fast release cycle available if dynamically loading part of the application logic from a remote server.
The demo app we created is completely open-source, and it's available at https://github.com/novoda/spikes/tree/master/ReactNative/ReactTwitter
For more Novoda open-source project, have a look at http://novoda.github.io/
We plan, design, and develop the world’s most desirable Android products. Our team’s expertise helps brands like Sony, Motorola, Tesco, Channel4, BBC, and News Corp build fully customized Android devices or simply make their mobile experiences the best on the market. Since 2008, our full in-house teams work from London, Liverpool, Berlin, Barcelona, and NYC.
Let’s get in contact