At Manas we organise internal hackathons on a monthly basis, with the goal to explore new technologies, languages, frameworks, paradigms, or whatever we want to play with; thus both satisfying our need to be constantly learning, and evaluating the tools that we will use for the projects to come. We have tried ReactJS, Clojurescript, Phoenix, LISP, and, most recently, React Native. For every hackathon, the members who participated share with the rest of the team their findings and experience; this time, we decided to share it publicly here on the blog.
In one sentence, and from their homepage, React Native is a framework for building native apps using React.
Though React Native requires a full Android and iOS development setup, plus all the actual React Native libraries, the setup is surprisingly easy. Downloading all prerequisites, especially the Android SDK and XCode, might take a few hours if you hadn’t had downloaded them previously, but the configuration is pretty straightforward and powered by npm.
We first went through the tutorial that covers the basics, and soon went on to implement an app of our own; we decided to work on a client app for reporting time to brium.me.
As we worked on the apps, we found that the same philosophy used for developing web apps using React could be brought to the mobile environment with almost no friction.
Even though React Native does not attempt to be a write-once use-everywhere solution, and encourages you to write different interfaces for iOS and Android, sharing only the common business logic, we found that for a simple application we could use exactly the same codebase, since the React Native wrappers over the basic components are the same for both platforms.
The bad and the ugly
React Native still hasn’t reached its 1.0 milestone, and we did stumble upon a few killer bugs. Attaching the debugger to an Android emulator changed the behaviour of the Fetch API, requiring an extra user interaction to actually return the result of a request, something that took us a few hours to figure out; fortunately, this issue has been already identified and solved in the upcoming version. Also, we could not run the app on the iOS emulator or deploy to an iPhone unless Chrome debugging was running, something that has also been reported by others. Documentation on some modules is scarce (see the Flexbox polyfill docs for instance), but being open source, we could always fall back to the source code to figure things out; so lack of docs was not a showstopper at any point.
The missing pieces
Being a one-day event, we missed several features of the framework that we would have liked to evaluate, such as bindings to native code, local storage, notifications, background operations and access to specific phone services such as geolocation.
We would also have liked to try React Native in combination with another framework, such as Redux, in the context of a larger app - but this can be the goal of a future hackathon.
Clearly a thumbs-up for React Native. We had already fell for the development model introduced by React, and being able to carry that model almost directly the the mobile environment is immensely powerful, especially taking into consideration the implementation of applications across mobile browsers, Android and iOS apps.
Use in production still feels a bit risky at this point, considering some of the bugs we faced, but we cannot rule out the possibility that with some additional time we could have worked around them.
All in all, React Native looks like a fantastic tool for implementing mobile apps, especially for developers coming from the web world.
You can check out the code of the app we implemented here.