Implementing a Flutter Hot‑Fix Solution for ZA Bank: Architecture, Process, and Lessons Learned

Introduction

Flutter is Google’s open‑source UI toolkit that enables a single codebase to target mobile, web, desktop, and embedded platforms. ZA Bank adopted Flutter for fund and stock business modules, gaining development efficiency but lacking an official hot‑fix mechanism, which is critical for financial applications.

Solution Selection

The team evaluated five possible hot‑fix approaches:

Business transformation to JavaScript (high cost, limited coverage).

AOT with JIT support (requires a separate Dart VM, increases package size by >20 MB).

Static DSL generated from Dart Analyzer (maintainability issues, heavy implementation cost).

Flutter Web (leverages existing cross‑platform capability, low impact on existing code).

Shorebird (requires Google Cloud storage, which is blocked in China).

Considering manpower, technical, and time costs, the team chose the Flutter Web‑based page‑downgrade solution.

Overall Scheme

The hot‑fix flow works by downgrading a problematic Flutter page to a Flutter Web page. When a bug is discovered, the page is rebuilt with dart2js , packaged as a web bundle, and the routing table is updated so that the next navigation loads the web version instead of the native Flutter page.

Key components include:

Backend support: a management system for patch versioning, multi‑platform release, and monitoring dashboards.

Native support: integration with the existing mixed‑stack protocol to keep the change surface minimal.

CI/CD jobs: Jenkins pipelines that validate packages, generate diff patches, and automate release.

Flutter Web architecture: non‑intrusive, extensible design that supports dynamic updates without app restart.

Patch generation: a “mother‑package + diff‑package” model where the diff is computed by comparing file hashes (add, del, diff types) and packaged with a config file.

Patch application: the client extracts the diff, applies deletions, additions, and binary diffs, then verifies the resulting package via hash signatures.

Challenges and Solutions

Font rendering issues: Canvaskit lacks built‑in Chinese fonts, causing garbled boxes. The team bundled a custom Chinese font and set fontFamilyFallback to resolve the problem.

First‑screen load time: Large Canvaskit.wasm and font files caused >10 s delays. Offline caching, compression (reducing wasm from 6.8 MB to ~2.8 MB) and font subsetting (10 MB → ~800 KB) cut the load to under 1 s, with a pre‑warm webview engine for instant display.

Package size: Full Flutter Web bundles exceeded 30 MB. A diff‑based approach reduced the incremental download to < 20 KB for most fixes, with the full package rarely needed.

Data sharing across platforms: An action‑based method was introduced to forward calls between native, H5, and Flutter Web layers, ensuring idempotent, side‑effect‑free data flow.

Cross‑domain and safe‑area handling: Native‑side adjustments and custom padding were added to support Android fetch restrictions and device safe‑area insets.

Results

In production testing, the hot‑fix system achieved a 99.27 % fix rate. Performance measurements showed near‑60 FPS rendering, sub‑second first‑frame load, and only ~3 MB additional memory consumption per web page.

Conclusion and Outlook

The Flutter Web‑based hot‑fix solution provides a complete end‑to‑end workflow—patch generation, delivery, and application—covering all Flutter capabilities while keeping the existing mixed‑stack architecture intact. Future work includes expanding the solution to more teams, improving cross‑page memory sharing, and further optimizing low‑end device performance.