Playing with React Native
Posted on Mar 19 2016
It’s finally time to start building apps with JavaScript.
During one of our hack days at GoSquared I decided to play with one of the latest of Facebook’s numerous open source endeavours. Having already gained a reputation in my team as a React fanboy, I decided to take my enthusiasm a step further and attempt to build an iOS app in a day using React Native.
An appropriate response imho
For those who aren’t aware (i.e. those living in the proverbial cave) React is an increasingly popular JavaScript library for managing your application UI in a declarative and functional paradigm. React Native is an effort by Facebook to take the power of React and implement it natively on iOS and Android, allowing you to write JavaScript code that takes advantage of React’s paradigms whilst offering native components and, in theory, native performance. Having experimented with it over a few weeks now I thought I’d share some of my thoughts and learnings.
I’m sure many people will have recoiled in horror at the idea of choosing JavaScript for native development over the type safety of Swift or the verbosity of Obj-C. I for one have worked with Objective C building iOS apps and JavaScript with React building web apps and there are great (and not-so-great) thinks about both camps.
Native isn’t really native
The initial selling point for me of React Native was the idea that I could write JavaScript (my primary language) but with native performance. In many ways this is what I got but with a few exceptions.
Having developed iOS apps with Obj-C, I initially thought that I would be simply mapping Obj-C commands to JavaScript functions and abstractions. In actual fact, React Native’s JavaScript runtime is entirely separate from the underlying iOS code and communicates via bridges implemented in Obj-C or Swift. This means that many of the native functionalities (such as TouchID, background activity, multithreading) are unavailable as standard. Generally speaking, to access these one must write some bridging code between the two. This isn’t particularly hard and the open source community is filling in many of these gaps but it was frustrating to realise that implementing some relatively trivial native code would require a bridge (and a language swap) to access.
What you do get is an actual native app. The
More than just writing JavaScript
Utilising React Native is not just a case of writing JavaScript. Not only is the language abstracted from the native code but those coming from iOS app development are required to step away from the paradigms such as storyboards and segues and instead hand your application state to React’s virtual rendering flow. For React veterans this may sound like bliss but the problem comes when considering working in a team. For my own personal project this worked out well as only I was working on it. However, once I considered collaborating with other members of my team with native iOS experience, I realised that they would not only have to swap languages but also their application architectural processes – arguably a more difficult switch.
This is somewhat remedied by Facebook’s interfaces allowing you to include native views and controllers in your React Native application (and vice versa). It is however, a big sticking point when considering its usage in production as part of a team. Unless that team of course, is primarily good JavaScript developers in which case you can utilise all of their skills to build native iOS *and *Android apps!
The Good
-
My fellow React fans will rejoice in the simplicity of React’s UI management applied to a native app
-
Facebook have covered 90%+ of the typical app needs and the open source community is busy building the rest
-
If your team uses React in your web application and the wonderful Redux then React Native will be music to your ears. You might not use the same codebase between your web and native apps but all the proficiencies and techniques apply.
-
Live reloading is awesome and fast. Going back to having to wait even a few seconds for Xcode to build makes me shudder…
The Bad
Remember that React and React Native are still 0.x releases so these are likely (I would think certain) to be remedied with Facebook’s aggressive development.
-
Your app will feel native but you’ll struggle to match the default style. I personally don’t mind this as most popular apps often work hard to deviate from the default UI but if you want your app to look like a stock Apple app then it is probably better to stay fully native.
-
Animations are sometimes painfully slow. Whereas in most cases my hackday app felt snappy and native, implementing animations was far trickier and janky. This is high priority for Facebook however.
-
Navigation is still awkward. Version 0.21 added a new experimental Navigation component that might be the start of the solution but it is arguably the most un-native part of a RN app.
-
Android has come slightly later to the game. It is certainly catching up (and adding the cool Android specific abilities) but its not quite as impressive as the iOS side yet…
Final thoughts
In React Native’s current state, it is really a question of your team. If you have dedicated Android or iOS devs then you should probably stick with that. If however you are mainly a JS team, especially if you’re already using React, then the speed at which you can build a quality native app is staggering and the ecosystem is only getting stronger. I urge anyone who is on the fence to take a hackday out to build an MVP of your product and I think you’ll be pleasantly surprised by the results.
P.S. If you’d like to see a production example of what can be done with React Native check out the fantastic Discord iOS app, that I believe is built entirely with React Native. It gives some of the best fully native apps a run for their money…