How Enterprise WeChat Scaled to Millions with Flutter: Architecture & Lessons

1. Background

Enterprise WeChat runs on Android, iOS, macOS, Windows, and Web, with tens of millions of lines of code. Each feature iteration requires synchronized development and releases across all five platforms, creating a huge challenge for developers, product, design, and testing teams.

Initially, the low‑level network, database, and most business logic were implemented in C++ for reuse, but UI code was written separately for each platform, leading to duplicated effort.

After evaluating H5 and mini‑program solutions, which fell short in performance or experience, the team turned to Flutter when Google released it. Flutter’s Skia‑based rendering and rich pub ecosystem met the high‑complexity requirements.

2. Enterprise WeChat Flutter Architecture

Flutter provides four module types:

Application (independent app)

Module (add‑to‑app)

Plugin (contains Android/iOS Dart code)

Package (pure Dart)

For an existing large project, the team uses the Flutter Module approach and adopts native‑component‑style modularization inside the module. Business code is written in pure Dart packages, while native code is accessed via plugins. UI libraries, basic tools, and routing components are also provided.

<code>library lib_flutter;</code><code>export 'src/cupertino/dialog.dart';</code><code>export 'src/cupertino/nav_bar.dart';</code><code>export 'src/cupertino/route.dart';</code>

3. Hybrid Stack Development

A hybrid stack means native and Flutter pages coexist and can navigate to each other. Most modern apps adopt this model.

Two solutions are compared:

FlutterBoost: clearer stack management but higher development and maintenance cost.

FlutterThrio: uses Flutter’s native navigation stack, lower cost, but documentation is limited.

Enterprise WeChat built its own internal navigation stack based on AppContainer, pre‑warming it during engine initialization and handling routing via channels, avoiding engine‑level invasiveness.

4. Engine Management

Two phases:

Single‑Engine Phase: One engine is cached and shared by all Flutter pages, suitable before Flutter 2.0.

Multi‑Engine Phase: With Flutter 2.0, FlutterEngineGroup enables engine memory reuse, reducing per‑engine overhead (~4 MB). A primary engine handles pages without other Flutter pages; a temporary engine is used when multiple Flutter pages coexist, and it is cached for subsequent use.

5. Flutter Communication – Pigeon

Pigeon generates type‑safe channel code from Dart interfaces, solving consistency, safety, and serialization issues of manual MethodChannel usage.

Challenges with pigeon include limited support for List and Map types. The team extended pigeon to generate protobuf code, enabling List/Map support and reuse of existing proto definitions.

6. Dart ↔ C++ Invocation

Enterprise WeChat reuses its mature C++ service layer. Three approaches are discussed:

Modifying the engine to expose RegisterNatives and Dart_SetNativeResolver (high maintenance).

Using dart::ffi (available after Dart 2.5) – but it has limitations such as complex binding, static‑only C++ calls, memory management issues, and potential crashes.

Using ffi::gen (auto‑generated ffi) – not adopted due to unresolved glue code and thread‑safety concerns.

To simplify, the team built a Dart‑C++ RPC framework based on protobuf, allowing Dart to call C++ services as if they were local async methods.

<code>final GovernRpcServiceApi api = GovernRpcServiceApi(WeRpcClient());</code><code>final RpcResult<GetGovernMyReportListResp> result = await api.getGovernMyReportListFromServer(GetGovernMyReportListReq()..limit = 10);</code>

7. Flutter Performance Optimizations

Shader jank was traced to Skia’s GPURasterizer::Draw, with occasional spikes up to 600 ms. Enabling Metal rendering on iOS after Flutter 2.3 mitigated this.

For add‑to‑app scenarios, the team caches compiled shaders (io.flutter.shaders.json) and includes them as assets.

Image caching is unified across native and Flutter by routing image requests through native cache when Flutter lacks one, reducing duplicate downloads.

SVG support is achieved by converting SVGs to custom icon fonts, improving rendering performance and reducing package size.

8. Ecosystem Construction

Multi‑language support is built on flutter_intl, with scripts to extract hard‑coded strings, translate them (English manually, Traditional Chinese via API), and merge results back into .arb files.

Custom UI components replicate native experience, and dark‑mode adaptation is handled via MaterialApp’s theme and darkTheme, with dynamic colors defined using CupertinoDynamicColor.

9. Debugging Tools – UiInsight‑Flutter

UiInsight‑Flutter provides efficiency and performance tools similar to native UiInsight, including widget inspection, MethodChannel monitoring, memory leak detection, FPS tree view, large‑image warnings, color picker, and AOP‑based method‑time ranking.

It also supports extensible plugins, such as a native‑call tracker specific to Enterprise WeChat.

10. Dynamic Loading – LiteApp

Flutter lacks the dynamic‑loading capabilities of React Native or Hippy. Enterprise WeChat explores dynamic solutions using LiteApp (Vue‑based) and Kraken (JS/TS). LiteApp compiles Vue code into a zip package, parses it into a Virtual DOM, maps it to LuggageView, and finally renders it as Flutter widgets via dart2cpp.

Four business modules (e.g., Blackboard, School‑Home) have been launched with LiteApp, though memory usage is still being optimized.

11. Outcomes & Outlook

Flutter adoption has increased across versions, reducing development effort by ~50% for engineers, improving design efficiency by 40%, and enabling cross‑platform test coverage with a single team.

The approach has been showcased at Google I/O and continues to evolve with ongoing research into dynamic loading and performance.