React Native: Technical Background, Planning, and Risks Overview

Facebook open‑sourced React Native at the F8 conference on March 26, and this article summarizes its technical background, roadmap, and associated risks.

The team completed a React Native migration of the “Guess You Like” feature in the Tmall iPad client on April 2, and began publishing performance, stability, extensibility, and development‑efficiency evaluations.

Background : React Native aims to combine native‑level user experience with the developer productivity of React on the web, encapsulated in the slogan “Learn once, write anywhere.” The concept addresses the industry pain point of high native development cost while preserving web‑like development speed.

Key arguments for native development include superior native controls, better gesture recognition, and more suitable threading models for tasks such as image decoding and text rendering, which web technologies cannot yet match.

React Native’s design philosophy is illustrated by the “Learn once, write anywhere” principle, emphasizing that a single codebase can target multiple native platforms without forcing a single native implementation to run everywhere.

The architecture consists of three layers: React code written once, a Virtual DOM that serves as a lightweight in‑memory representation of the UI, and platform‑specific renderers (Web, iOS, and upcoming Android) that communicate via a JavaScript‑Native bridge.

Planning details include:

Integration of React Node for server‑side rendering of initial screens.

Setup of the React Native base environment, noting that integration into existing complex apps (e.g., the Tmall iPad client) can require several days of effort.

Networking refactor to handle session cookies, opting for native‑handled network I/O accessed through a HybridAPI.

Cache and bundling strategies to improve both first‑load and subsequent‑load performance.

Adapting the internal MUI component library to React Native components.

Leveraging Alibaba’s HybridAPI for efficient communication between JavaScript and native code.

The first business feature is scheduled for release in mid‑April; its success will determine broader adoption.

Risks identified are:

Uncertainty about App Store policy changes as React Native adoption grows.

Android support is expected only after October 2015, limiting three‑platform consistency.

iOS 6’s JavaScriptCore is a private API, posing potential review rejections.

ListView performance issues that require ongoing monitoring.

Overall, the article concludes that while “Write once, run anywhere” remains valuable for efficiency, “Learn once, write anywhere” better reflects the practical trade‑offs of React Native, and the team plans to open‑source their component adaptations once mature.