Mobile Development 20 min read

Which Cross‑Platform Mobile Solution Wins? Web, Native, or Flutter Explained

This article examines the evolution of China's mobile internet, outlines three cross‑platform development approaches—Web rendering, native rendering, and custom rendering engines like Flutter—analyzes their architectures, advantages, and trade‑offs, and offers guidance for selecting the right solution for different product needs.

ELab Team
ELab Team
ELab Team
Which Cross‑Platform Mobile Solution Wins? Web, Native, or Flutter Explained

Background

In the past 20 years China’s internet has grown rapidly. The first decade (up to 2010) was the PC era, which built user habits that later fueled the mobile internet era driven by smartphones. Early mobile apps like WeChat, Alipay, Toutiao, Meituan became essential services, and the market has now become a red‑sea where leading apps either become super‑apps or specialize in vertical domains.

To maintain competitive advantage, leading apps must continuously expand service boundaries and respond quickly to market changes, while newer apps need product and business model innovation to improve development agility without sacrificing user experience.

Cross‑platform development emerged as a solution focused on development efficiency and user experience, but each implementation involves trade‑offs between these goals.

This article introduces the technical architectures of different cross‑platform solutions, analyzes their strengths and weaknesses, and provides guidance for technology selection when targeting iOS and Android.

Cross‑Platform Solutions

Based on rendering technology, solutions are divided into three categories:

Web rendering solutions

Native rendering solutions

Custom rendering‑engine solutions

Web Rendering Solutions

Web rendering uses the native WebView component to display HTML pages and defines a JSBridge for two‑way communication between H5 and native code.

The rendering pipeline mirrors that of a regular web page, with performance bottlenecks similar to first‑screen rendering and additional WebView initialization overhead.

Companies customize the WebView kernel (e.g., Tencent X5, Alibaba UCWebView) to reduce initialization cost.

Offline‑package techniques preload H5 resources locally to minimize white‑screen time and approach native experience.

Advanced H5 containers add rich JS APIs, enhanced WebView controls, and plugin mechanisms.

Example: Cordova, an Apache open‑source framework, consists of a Web App, an HTML rendering engine (WebView), Cordova plugins for native access, and the underlying mobile OS.

Mini‑programs (e.g., WeChat) also rely on WebView rendering but separate rendering and logic layers: rendering uses WebView, while logic runs in a dedicated JavaScript engine (JavaScriptCore or V8) on a worker thread, communicating via the native layer.

Mini‑programs blend Web and native rendering, offering high development efficiency, dynamic updates, and consistent appearance, but suffer from slower performance and sandbox limitations.

High development efficiency

Good dynamic update capability

Consistent UI across platforms

Performance drawbacks due to WebView sandbox

Native Rendering Solutions

Native rendering keeps UI description in a front‑end framework, parses JavaScript, and uses a Bridge to invoke native components. Representative frameworks include React Native and Weex.

React Native architecture: React layer (UI description), JS bundle, Bridge layer (UIManager, NativeModules), Native layer (native UI, Yoga layout engine, native modules).

Thread model includes UI thread (native rendering), JS thread (React code), Shadow thread (layout mirroring), and Native Modules thread (native capabilities).

While offering better performance than Web rendering, the Bridge introduces latency due to serialization between JS and native layers, especially in animation‑heavy scenarios.

Custom Rendering‑Engine Solutions

Custom engines render UI directly without WebView or native component translation. Flutter exemplifies this approach.

Flutter consists of four layers: Dart App (widgets), Flutter Framework (UI libraries), Flutter Engine (Dart VM, Skia renderer, platform channels), and Embedder (host environment, thread creation, plugins).

Thread model: Platform thread (vsync), UI thread (Dart code, layer tree generation), GPU thread (Skia rasterization), IO thread (resource loading).

Flutter’s UI is drawn by Skia, providing consistent high‑performance rendering across platforms. Dart code is AOT‑compiled in release mode, offering superior execution speed compared to JavaScript‑based solutions.

Direct Skia rendering for UI

Dart‑based UI description with diff optimization

AOT compilation improves performance

Higher data‑exchange efficiency between UI and native layers

Current State and Outlook

All three approaches have viable use cases. Small‑to‑medium companies often adopt Web rendering for its low entry barrier, while large companies may extend their apps with mini‑program ecosystems. For performance‑critical products, native rendering or custom engines like Flutter are preferable, with custom engines offering the highest potential.

One possible future direction is a hybrid architecture where a front‑end DSL generates UI information that is passed via a C++ interface to a Skia‑based engine, combining cross‑platform consistency, dynamic updates, and high performance.

References

H5 container overview

Offline package introduction

Hybrid App offline package practice

Cordova architecture

Mini‑program architecture

WeChat mini‑program technical analysis

Mini‑program same‑layer rendering analysis

React Native architecture overview

React Native startup process

React Native new architecture analysis

Flutter compilation modes

Flutter cross‑platform evolution

In‑depth Flutter rendering engine analysis

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

cross-platformarchitectureWebViewReact Native
ELab Team
Written by

ELab Team

Sharing fresh technical insights

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.