React Native at Instagram

React Native has come a long way since it was open-sourced in 2015. Fewer than two years later, it’s being used not only in Facebook and Facebook Ads Manager but also in many other companies, from Fortune 500 companies to hot new startups. Developer velocity is a defining value of Instagram’s mobile engineering. In early 2016, we started exploring using React Native to allow product teams to ship features faster through code sharing and higher iteration speeds, using tools like Live Reload and Hot Reloading that eliminate compile-install cycles.


Integrating React Native into an existing native app can create challenges and additional work that you don’t encounter when you start an app from scratch. With this in mind, we decided to start exploring these challenges by porting the simplest view we could think of: the Push Notifications view. This view was originally implemented as a WebView, so we thought that it wouldn’t be too hard to beat its start-up times. On top of that, this view didn’t require us to build much navigation infrastructure — the UI was quite simple and translations were determined by the server.

Android Methods Count

The first problem that popped up was adding React Native as a dependency without pulling in the entire library. Doing so would not only increase the binary size but would also have a large impact on methods count, making Instagram for Android go multi-dex with all the performance consequences this entails (yes, Instagram is still single-dex!). We ended up selectively pulling in only the view managers we needed at that time and writing our own implementations for the ones that depended on libraries we didn’t want to pull in. Ultimately, React Native ended up adding ~3500 methods. Features are written in React Native barely require defining Java methods, so we believe this investment will be worthwhile in the long run.


As part of the Push Notification Settings experiment, we audited React Native’s impact on several metrics, including crashes and out of memories. We found these metrics to be neutral both on the initial experiment and when we looked into retaining the bridge instance when the user left a React Native feature (so the next time they enter the one we didn’t have to re-create it).

Start-Up Performance

React Native has a start-up overhead mostly caused by having to inject the JavaScript bundle into JavaScriptCore (the VM used by React Native both on iOS and Android) and instantiate native modules and view managers. Although the React Native team has come a long way in improving performance, for Instagram integration we wanted to measure this gap to figure if the tradeoffs would make sense for us. To do so, we ported the existing native Edit Profile view to React Native. Along the way, we built product infrastructure that started being used by product teams in parallel (e.g. navigation, translations, core components).

Full Article:

Featured Posts
Recent Posts
Search By Tags
No tags yet.
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Social Icon