Meituan React Native (MRN) Dynamic Framework: Architecture, Practices, and Performance

MRN Overview

Meituan’s R&D team built a customized dynamic solution on top of the open‑source React Native framework, called MRN (Meituan React Native). The solution aims to provide a development experience comparable to native RN while supporting the full lifecycle of development, building, testing, deployment, and operations.

Background

Since the launch of Meituan Waimai in 2013, the product has expanded from a single food‑delivery service to more than ten major categories (e.g., groceries, pharmacy, flowers). Rapid growth created three major pain points:

Long release cycles due to native app store approvals.

Limited client‑side development resources versus growing business demands.

Rapidly increasing app package size (≈140% growth from 2018 to 2019).

React Native, released by Facebook in 2015, offered a hybrid development model that could address these issues. Meituan adopted RN, then extended it with custom scaffolding, component libraries, pre‑loading, bundle splitting, and release pipelines, forming the MRN ecosystem.

Hybrid Architecture

The MRN architecture consists of multiple layers (from bottom to top):

System service layer (Android/iOS).

Platform service layer.

MRN infrastructure layer – abstracts platform differences.

Business component layer – adds RN containers and exposes RN‑callable components.

MRN interface layer – unifies RN APIs across Android and iOS.

Business layer – the pages visible to users (implemented in Android, iOS, or RN).

Supporting tooling (code standards, lint, debug plugins, CI) is placed in the top‑left corner of the diagram.

Component Library

To mitigate the limited set of RN core components, Meituan built a component library that includes pure‑JS components and hybrid JS‑Native components. The library integrates open‑source Beeshell components and internal native services (e.g., cart, ads). Over dozens of business components now support nearly 100 RN pages.

Technology‑Selection Rules

Three stacks coexist: Native, MRN, and H5. Selection criteria:

Strong interaction (multiple gestures, complex animations) → Native.

When strong interaction is absent, prefer MRN.

Lightweight, quickly‑updated pages → H5.

Release & Operations Support

MRN release follows a five‑module pipeline: development delivery, online release, monitoring, incident response, and post‑mortem improvement. The process uses Meituan’s internal Talos system for code review, bundle packaging, and deployment to the Eva CDN.

Engineering Structure Evolution

Initially a single Git repo with a Talos project, MRN later split into four business‑domain repositories (order, traffic, merchant, marketing) to reduce merge conflicts and permission bottlenecks. Two main build strategies were evaluated:

Single‑project single‑bundle – simple but tightly coupled.

Multi‑project multi‑bundle – decoupled but caused dependency fragmentation.

The final solution is a single‑project multi‑bundle approach: one package.json manages all dependencies, while each business bundle is built independently, achieving both decoupling and dependency consistency.

Monitoring Metrics

Key availability metrics:

Download success rate (≈99.9%).

Engine initialization success (>99.99%).

Bundle load success (>99.9%).

JS error rate (≈0.01%).

Page exit success (target >99.99%).

Performance metrics focus on load latency (engine init, bundle parsing, first‑frame rendering) and runtime FPS (≈55 fps on Android, near‑full on iOS). Pre‑loading the JS engine reduces first‑load latency significantly.

Efficiency Measurement

Formulas were introduced to quantify:

Productivity gain (ratio of saved native person‑days).

Code reuse rate (RN lines vs. total lines).

Maintenance cost reduction (native lines saved vs. total).

Results show >50% productivity improvement for simple pages, near‑100% code reuse for pure‑display pages, and substantial maintenance cost savings.

Conclusion

By adopting MRN, Meituan Waimai has launched over 60 RN pages with daily PV in the tens of millions, achieving faster releases, reduced package size, and higher operational stability. The case also highlights challenges such as increased architectural complexity, the need for cross‑stack expertise, and the importance of robust monitoring and release tooling.