Upgrading React Native from 0.51 to 0.62: Performance Gains, Migration Strategy, and Deployment Plan

Background : The mobile team at Manbang Group started using React Native in early 2018 with version 0.51. After three years the app covered 16+ business modules and 200+ pages, generating tens of millions of daily page views. Dynamic releases replaced traditional app releases, allowing multiple updates per week.

0.62 Major Improvements

Performance : Android switched to the Hermes JavaScript engine, delivering faster startup, lower memory usage, and higher execution efficiency.

Stability : Numerous bugs were fixed, including stronger SDK robustness (e.g., ReactHostView.show() and hide() safety) and stricter error handling in ViewManager .

Ecosystem : React Native 0.62 supports React 16.11+, bringing Context, Hooks, and many third‑party libraries that were unavailable in 0.51.

Performance Benchmarks

Android tests compared JSC and Hermes on a VIVO X21 (6 GB RAM). Cold‑start time dropped by more than 50% with Hermes+HBC, while memory consumption decreased by about 30%. Execution speed of JavaScript instructions improved to roughly 1/6 of JSC, benefiting frame rates and animation smoothness.

iOS remained on JSC for 0.62, but the new RAM bundle format was evaluated; the team plans to adopt Hermes on iOS in future releases (e.g., RN 0.64).

Migration Strategy

Key challenges include multi‑team coordination, simultaneous SDK upgrade and high‑frequency dynamic releases, minimizing upgrade cost, and guaranteeing online stability for apps with half‑million daily active users.

The upgrade follows low‑risk principles: batch‑wise gray‑scale rollout, separate release lines for 0.51 and 0.62, and immediate rollback capability. A unified codebase is maintained by adding an adaptation layer that abstracts breaking API changes, allowing the same source to run on both SDK versions.

Technical Preparation

API Changes : The team catalogued breaking and non‑breaking changes between 0.51 and 0.62, providing migration guides (e.g., replacing legacy AsyncStorage with a custom bridge). Sample migration code:

//npm install --save @react-native-community/asyncstorage

// import AsyncStorage from '@react-native-async-storage/async-storage';

// Bridge usage example

MBBridge.app.storage.getItem({ key: BootPageModalKey.KEY_IS_SHOW_BOOTPAGEMODAL })
  .then(res => { if (this.isGuidanceSwitch(res?.data?.text)) { /* ... */ } });

MBBridge.app.storage.setItem({ key: Constant.StorageKey.Common.RefName, text: commonStore.refName })

Code Adaptation : Navigation code was refactored from StackNavigator to a compatibility layer createStackNavigatorCompat and createAppContainerCompat , enabling a single codebase to target both SDK versions.

Script Tools :

API compatibility checker (Python) that runs locally or in CI/CD pipelines.

Environment‑switch script (Shell/Python) to toggle between 0.51 and 0.62 configurations.

Runtime‑environment validator to detect mismatched native SDK and bundle versions.

Release Plan

Two‑stage batch upgrade: first batch for driver‑side apps, second batch for shipper‑side apps. Android uses dynamic plugin deployment (Hermes+HBC) with gray‑scale control; iOS follows standard App Store release with a 7‑day gray‑scale.

CI/CD integrates environment switching, API‑check scripts, version‑number generation (0.51 → 5.91.xxx.yy, 0.62 → 5.91.1xxx.yyyy), and HBC map upload.

Online Verification

During gray‑scale, daily reports track DAU, PV, JS/SDK exception rates, and performance metrics. When thresholds are exceeded, rollout pauses. Collected data confirmed offline test expectations: package size grew ~45% (due to HBC), cold‑start time improved ~64%, memory usage dropped ~30%, while hot‑start remained unchanged.

Conclusion

The end‑to‑end upgrade—from research, performance profiling, planning, testing, to production monitoring—demonstrated that a well‑orchestrated, low‑risk migration can be achieved without disrupting business velocity, while delivering measurable performance benefits.