React Native: Modern Web Techniques For Building Native Apps

April 21, 2016

Earlier this month, I gave a Friday lunchtalk for my colleagues at In The Pocket on React Native. This is an upcoming framework for building native mobile apps using JavaScript and React. As I'm very excited about this, I decided to present some context and outline the many advantages of the framework to develop native apps.
  • Building a mobile app using familiar web techniques has always been an attractive strategy for many companies and developers. The advantages are obvious: easy code sharing between different platforms, the ability to use familiar tools and libraries, and more flexibility to update content and layout.

    Remember the early days of the Facebook app? The first version of the app was in fact a full HTML5-based app; However, performance and user-experience were so poor that Facebook decided to rewrite the entire app natively two years later. Mark Zuckerberg admitted that HTML5 was simply not able to deliver the fast and reliable experience that people were expecting from a mobile app.

    Slowly it became clear that in order to deliver fast, smooth and consistent apps, native was the way to go; iOS and Android development soon became the norm with millions of mobile developers joining the party.

    Building mobile apps however is not always rosy. Not only do iOS and Android require a different development stack, it also does not allow any kind of code sharing between both platforms. Code also needs to be recompiled after every change, resulting in a slow iteration speed.

    On the web, development is a lot easier. Front-end code is more easy to understand with Javascript, CSS and HTML as the fundamental building blocks. Changes can be immediately observed and a wide range of frameworks (like React) are available to structure and organise code in a clear manner.

  • What if we could have best of both worlds? Providing the consistent, smooth user experience from native apps with the developer experience of the web. Enter React Native!

    React Native is an open-source framework started by Facebook in 2015 with the purpose of building truly native applications using a consistent developer experience based on Javascript and React. It is important to realise that, even tough all logic is written in Javascript, the application is fully native and indistinguishable from an app built using Objective-C/Swift or Java. This is unlike other hybrid frameworks like PhoneGap that basically execute Javascript code in a browser view.

    React Native adopts the same strategy as the React.js framework to construct user interfaces by declaring stateless components. Apart from well structured code, this also means that any web developer familiar with the standardised set of React API’s can now start developing native apps. In addition, instead of recompiling changes, React Native can reload your code instantly while retaining your application state. Really cool to see this in action!

    Another advantage is that React-Native can be interchangeably used with native components (written in Objective-C or Java), imposing no vendor lock-in. This is important as it enables to integrate React-Native easily in existing native apps.

    Facebook is already using React Native in a number of its apps, including the main Facebook app and Instagram app. Say what?! Soundcloud and AirBnb are also on that list.

    In my slide deck, I embedded some slides from Martin Konicek, an engineer at Facebook giving a talk titled “Under the hood of React-Native”. In his talk he showcases the Facebook Ads Manager and explains the development process as it was one of the first apps to use React Native. Interesting is that the iOS and Android app each look very different with a truly native look and feel. At the same time, 85% of the code is shared between both platforms, which is huge if you ask me.

    However, code sharing according to a “write once, run anywhere” mantra is not the reason why Facebook started this project. On an early blog posts they motivate this as follows: “Different platforms have different looks, feels, and capabilities, and as such, we should still be developing discrete apps for each platform, but the same set of engineers should be able to build applications for whatever platform they choose, without needing to learn a fundamentally different set of technologies for each. We call this approach “learn once, write anywhere.””