Mobile Development 20 min read

Why Flutter Beats WebView and React Native for Cross‑Platform Mobile Apps

This article examines the challenges of cross‑platform mobile development, compares WebView and React Native with Flutter, explains Flutter’s layered architecture, JIT/AOT compilation, hot‑reload, integration strategies for iOS and Android, performance measurements, and practical lessons from Mafengwo’s merchant app implementation.

Mafengwo Technology
Mafengwo Technology
Mafengwo Technology
Why Flutter Beats WebView and React Native for Cross‑Platform Mobile Apps

Why Flutter

Since the release of Flutter 1.0 in December 2018, the Mafengwo e‑commerce client team evaluated mainstream cross‑platform solutions such as WebView and React Native. WebView offers rich web controls and fast development but suffers from poor rendering efficiency and JavaScript performance, leading to slow page loads and sub‑optimal user experience. React Native provides near‑native rendering speed through a bridge to native widgets, yet the bridge introduces platform‑specific differences that make adaptation and maintenance cumbersome.

Flutter Advantages

Flutter addresses these issues with two design‑language widget sets (Material & Cupertino) that reduce development effort while delivering platform‑appropriate UI. Its rendering engine is built on Skia, allowing direct drawing of widgets via high‑performance native ARM code without an intermediate virtual DOM, resulting in performance close to native.

Flutter supports both JIT (enabling hot‑reload during development) and AOT compilation (producing highly optimized release binaries). The framework is written in Dart, which runs on the Dart VM or compiles to native ARM code, offers AOT/JIT, isolates for multithreading, lock‑free memory allocation, generational garbage collection, and linear heap growth.

Flutter Architecture

Flutter follows a layered design:

Embedder : adapts Flutter to any platform.

Engine : includes Skia, Dart runtime, and text rendering.

Framework : provides UI widgets and higher‑level APIs.

The Framework is further divided into components such as Foundation, Animation, Painting, Gesture, Rendering, Material, Cupertino, and Widget. Rendering proceeds through layout, paint, and compositing stages, with a 7‑step pipeline illustrated in the diagrams.

Flutter in Mafengwo Merchant App

The team chose a hybrid approach—Flutter modules combined with native code—because the existing merchant app could not be rebuilt from scratch. Four Flutter project types were considered:

Flutter Application (standard app with Dart and native layers).

Flutter Module (Dart code only, native wrappers generated automatically).

Flutter Plugin (Dart plus native implementations).

Flutter Package (pure Dart library).

For iOS, the official module integration script was examined but rejected due to its heavy reliance on the Flutter environment, which would hinder native developers. Instead, a remote‑artifact strategy was adopted: the Flutter module builds App.framework, Flutter.framework, static libraries, and assets, which are then published to a remote repository and consumed by the native iOS project.

flutter_application_path = '../flutter_Module/'
eval(File.read(File.join(flutter_application_path, '.ios', 'Flutter', 'podhelper.rb')), binding)

For Android, a Gradle‑based remote dependency was added:

implementation 'com.mfw.app:MerchantFlutter:0.0.5-beta'

Both platforms use Platform Channels (MethodChannel) for asynchronous communication between Flutter and native code, ensuring UI responsiveness.

Performance Comparison

Both iOS and Android list‑page implementations were built in native and Flutter. Visual comparisons showed negligible difference in smoothness, while Flutter exhibited slightly higher memory and GPU/CPU usage. Package size increased from 39 MB to 44 MB after adding Flutter. Overall, native remains marginally faster, but Flutter’s cross‑platform productivity and hot‑reload outweigh the performance gap.

Hybrid Stack Management

Flutter’s navigation uses Route and Navigator widgets, managing a stack of pages. When embedded in a native app, the team adopted a hybrid‑stack model: native initiates push/pop, synchronizes with Flutter via channels, and maps each Flutter page to a dedicated native container (FlutterContainerVC). A singleton FlutterViewController is reused to reduce thread and resource overhead, while RelayoutBoundary and RepaintBoundary mechanisms minimize unnecessary redraws.

Lessons Learned

Flutter’s rapid adoption, strong community, and Google backing make it attractive, yet challenges remain: early‑stage stability (e.g., rendering bugs in 1.2), limited dynamic update capabilities, reliance on platform channels for native features, migration complexity for existing codebases, and verbose nested widget trees without a separate layout language.

Despite these issues, Mafengwo’s experience demonstrates that Flutter can achieve near‑native performance, simplify cross‑platform development, and provide a viable path for future mobile projects.

FlutterPerformanceCross-PlatformarchitectureHybrid Integration
Mafengwo Technology
Written by

Mafengwo Technology

External communication platform of the Mafengwo Technology team, regularly sharing articles on advanced tech practices, tech exchange events, and recruitment.

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.