Why One Codebase Can Run Everywhere: Deep Dive into Cross‑Platform Architecture

Building on the DRY (Don’t Repeat Yourself) principle from *The Pragmatic Programmer*, the article treats cross‑platform development as a higher‑level reuse that aims to write code once and run it on many devices.

What "cross‑platform" Covers

Typical targets include:

PC (macOS, Windows, Linux)

Mobile (Android, iOS)

Web applications and plugins

Mini‑programs (WeChat, DingTalk, Alipay, Kuaishou, etc.)

H5 pages

The logical separation consists of three layers:

Hardware form factor – physical devices such as PCs, phones, IoT boards.

Operating‑system layer – different OSes on the same hardware (e.g., macOS vs. Windows).

Application layer – distinct apps or derived apps running on the same platform (e.g., browsers, mini‑programs).

How Cross‑Platform Works

Cross‑platform is achieved by providing a container that abstracts rendering and logic/native capabilities. Examples of such containers include browsers, Electron, Docker, JVM, and Node, which expose a unified API so that a single codebase can execute across diverse environments.

Architectural Patterns

2.1 H5 Hybrid

Uses a WebView for rendering, a JavaScript engine for logic, and a JSBridge to call native APIs. The stack is:

Rendering: WebView

Logic: JavaScript engine

Native capability: JSBridge + platform APIs

Advantages

Very low integration cost; can reuse existing front‑end ecosystems.

Balanced efficiency.

Supports hot updates, fast release cycles.

Disadvantages

Complex or animation‑heavy pages perform poorly due to WebView limitations.

High‑frequency or time‑critical scenarios cannot achieve native‑level performance.

2.2 Framework + Native Rendering

Represented by React Native and Weex, this approach combines the web ecosystem with native UI components. The stack is:

Rendering: Native components

Logic: JavaScript engine + JSI

Native capability: Direct native components

Advantages

Balanced development cost—higher than pure hybrid but lower than full native.

Low learning curve for front‑end developers.

Mature ecosystem with many third‑party solutions.

Backed by Facebook, offering relatively stable evolution.

Disadvantages

Platform‑specific code may still be required, increasing maintenance.

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

Rendering results may differ across platforms, prompting efforts to unify UI.

2.3 Framework + Self‑Rendering Engine (Flutter)

Flutter compiles Dart code to native binaries and uses the Skia rendering engine directly, avoiding any bridge. The stack is:

Rendering: Skia

Logic: Dart VM

Native capability: Native components via platform channels

Advantages

Excellent performance, close to native.

Consistent UI across Android, iOS, and other platforms.

Supports both JIT and AOT compilation for flexible deployment.

Disadvantages

Developers must understand native Android/iOS basics; UI may still need platform‑specific tweaks.

Potential increase in crash rate when integrating third‑party native code.

Widget‑centric code can be hard to read and select.

Ecosystem fragmentation: many third‑party packages lack a unified standard.

2.4 DSL Compile + Hybrid Rendering

Solutions such as uni‑app, Taro, Chameleon, and Rax compile a custom DSL into target code for iOS, Android, H5, and various mini‑program platforms. The stack is:

Rendering: Mixed (Weex native, WebView, mini‑program engines)

Logic: JavaScript engine + Vue

Native capability: Native components & plugins

Advantages

Supports many mini‑program ecosystems and multiple device types.

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

Rich plugin ecosystem (though quality varies).

Disadvantages

Jack‑of‑all‑trades but master‑of‑none; high‑performance or complex interactions may suffer.

Compatibility bugs across platforms are common.

Native features not covered by the DSL require separate native implementation.

Real‑World Implementations

3.1 Qunar’s React Native‑First Unified Solution

Qunar leverages its existing RN stack for iOS/Android and extends it to H5 and mini‑programs:

RN → H5: Uses react-native-web with webpack aliasing to replace RN components with web equivalents, requiring no code changes.

RN → Mini‑program: Uses Remax to generate a custom VNode tree and render it via the mini‑program runtime, handling the separation of view and logic through setData.

3.2 Flutter Full‑Platform Approach

Flutter provides a single Dart codebase that runs on Android, iOS, and (with limitations) Web. The Web support currently suffers from large bundle size (~1.1 MB) and sub‑optimal scrolling performance due to frequent Canvas creation.

Examples of Flutter adoption include DingTalk’s four‑platform framework Dutter, Meituan Waimai’s web experiments, and many consumer apps.

3.3 Hybrid Solutions in Large Companies

Enterprises often build custom hybrid containers, focusing on three performance‑boosting principles: earlier (pre‑load components), nearer (cache resources locally), and faster (replace weak points with native implementations).

Key Takeaways

Choosing a cross‑platform strategy requires answering four questions:

Strategic & business fit: Is there a genuine multi‑device demand and sufficient user volume?

People & organization: Do you have the right talent and team structure to maintain a shared codebase?

Ecosystem maturity: Are there stable libraries and community support for the chosen stack?

Performance & experience: Can the solution meet latency, UI consistency, and interaction requirements?

Ultimately, cross‑platform development brings cost savings only when the ROI justifies the added complexity.