Understanding the Meaning, Essence, and Practical Solutions of Cross‑Platform Architecture

1. The Significance of Cross‑Platform Architecture

The DRY principle from "The Pragmatic Programmer" advocates eliminating duplicate code to improve flexibility and simplicity; cross‑platform development extends this idea to reuse across different devices and platforms, aiming for "write once, run everywhere".

Typical development separates Android, iOS, Web, and mini‑programs, but modern front‑end advances enable many cross‑platform frameworks. The target devices include PC (macOS, Windows, Linux), mobile (Android, iOS), Web applications/plugins, various mini‑programs (WeChat, DingTalk, etc.), and H5.

Cross‑platform logic can be viewed in three layers:

Hardware form factor – e.g., PC, mobile, IoT devices.

Different platforms on the same hardware – e.g., macOS vs. Windows on a PC.

Different applications or derived applications on the same platform – e.g., browsers, WeChat mini‑programs, Alipay mini‑programs on iOS.

Operating systems act as bridges between hardware and users; each OS has its own executable format, creating platform differences that must be abstracted.

Cross‑platform solutions include browsers (which provide a container and unified API), Electron (Chromium + Node.js for desktop), and the need to share business logic across apps while preserving native‑like experience.

2. The Essence of Cross‑Platform Architecture

At its core, a cross‑platform architecture consists of rendering, logic, native capability support, and build methods, usually realized by creating a custom container that smooths or abstracts platform differences.

2.1 H5 Hybrid Solution

Browsers inherently support cross‑platform execution; by embedding a WebView in native apps and using JavaScript with a JSBridge to call native APIs, developers can achieve a hybrid approach where simple pages are fully web‑based while performance‑critical UI uses native components.

Components: Rendering – WebView; Logic – JavaScript engine; Native capability – JSBridge + native APIs.

Advantages:

Very low entry cost; reuse of existing front‑end stack.

Balanced efficiency.

Supports hot updates for rapid releases.

Disadvantages:

WebView limits performance for complex animations or infinite‑scroll pages.

High‑performance or time‑critical scenes may not achieve native‑level smoothness.

2.2 Framework + Native Rendering

React Native and Weex combine web‑style JavaScript with native UI components, offering better performance than pure WebView.

Components: Rendering – native components; Logic – JavaScript engine + JSI; Native capability – native components.

Advantages:

Balanced development cost (higher than hybrid but lower than pure native).

Low learning curve for front‑end developers.

Leverages mature front‑end ecosystem.

Backed by Facebook, providing stable evolution.

Disadvantages:

Platform‑specific code may still be required.

Complex interactions can cause performance issues (though newer architectures mitigate this).

Rendering inconsistencies across native components.

Examples: Facebook, YouTube, Discord, QQ, Baidu (React Native); Taobao, Tmall, Ele.me (Weex).

2.3 Framework + Self‑Rendering Engine

Flutter compiles Dart code to native binaries and uses the Skia engine for rendering, eliminating bridges and offering near‑native performance and consistent UI across Android, iOS, and desktop.

Components: Rendering – Skia; Logic – Dart VM; Native capability – native components.

Advantages:

High performance, close to native.

Excellent cross‑platform experience across many platforms.

Stable UI consistency.

Supports both JIT and AOT compilation.

Disadvantages:

Requires native development knowledge for platform‑specific features.

Potential increase in crash rate when integrating Flutter.

Widget code can be hard to read and select.

Ecosystem contains many third‑party packages without a unified standard.

Used by DingTalk, Meituan Waimai, Mafengwo, etc.

2.4 DSL Compilation + Mixed Rendering

Solutions like uni‑app, Taro, Chameleon, and Rax compile a custom DSL into target code for iOS, Android, H5, and various mini‑programs, mixing WebView, native, and Weex rendering.

Components: Rendering – mixed (WebView, Weex native, etc.); Logic – JavaScript engine + Vue; Native capability – native components & plugins.

Advantages:

Supports many mini‑program platforms.

Low development and learning cost; essentially front‑end development.

Rich plugin ecosystem (though quality varies).

Disadvantages:

May not excel in any single area; performance‑critical apps need careful evaluation.

Compatibility issues across many platforms.

Native features rely on nvue; missing native APIs require native developers.

3. Concrete Implementation Cases

3.1 Qunar’s React Native‑First Multi‑Platform Strategy

Qunar builds on an existing RN stack for iOS and Android, then converts RN code to H5 using react-native-web (via webpack aliasing) and to mini‑programs using Remax, which provides a React reconciler‑based renderer for various mini‑program environments.

3.2 Flutter Full‑Platform Solution

Flutter uses Dart and Skia to deliver consistent UI on Android, iOS, and desktop; Web support exists but suffers from large bundle size and sub‑optimal scrolling performance.

3.3 Hybrid Solution

Large companies often create custom hybrid containers, focusing on three optimization principles: earlier (pre‑load components), nearer (cache resources locally), and faster (replace weak points with native implementations).

4. Summary

Cross‑platform technology evolves rapidly; today’s best solution may be outdated tomorrow. When considering a cross‑platform approach, evaluate strategic business needs, team expertise, ecosystem maturity, and performance/experience trade‑offs, and always calculate the ROI before committing.