Hot-Loading Mini-Programs Without Super App Update
The core advantage of mini-programs over native apps is deploying new versions to users instantly, without App Store Review and without user action. Fix a JS bug tonight, every user has the new version tomorrow morning. This works only if hot-loading is implemented correctly. Otherwise, users see old bugs for weeks, or worse, a crashing screen after a broken bundle update.
How Hot-Loading Works
Hot-loading for mini-programs isn't the same as Hot Module Replacement in Webpack. It's a CDN-based delivery system with versioning and rollback capability.
Basic flow:
- Developer publishes new mini-program version (new bundle.zip on CDN)
- Platform updates manifest — JSON with metadata and new bundle URL
- Super App periodically (or on startup) checks manifest server
- If version changed — download new bundle in background
- Next time mini-program opens — load new bundle
Devil's in the details of steps 3-5.
Update Check Strategies
Polling on host startup. Simplest: each Super App launch, a background service checks manifest for all installed mini-programs. For 50 mini-programs — 50 HTTP requests or one batch request with bulk manifest API. Update lag: until next app launch, average several hours.
Long polling / Server-Sent Events. Host keeps an open connection to manifest server. On new version publish, server pushes all connected clients. Instant delivery, but constant connection drains battery and data, unstable on mobile networks. Suits enterprise apps where instant updates matter.
Silent Push Notification. APNs background push (iOS) or FCM data message (Android) on new version publish. System wakes the app in background for 30 seconds (iOS) or without explicit limit (Android with Doze mode restrictions), it downloads bundle. Optimal balance between delivery speed and battery impact. iOS limitation: APNs silent push can be throttled by system.
In practice we combine: silent push as primary channel + polling on startup as fallback for devices where push didn't arrive.
Atomic Update Application
Critical moment: don't apply bundle during active mini-program session. Replacing files while WebView runs guarantees a crash.
Solution — staged swap:
/miniapps/com.vendor.app/
current/ <- current active bundle (v2.3.1)
pending/ <- downloaded but not applied (v2.3.2)
rollback/ <- previous bundle for rollback (v2.3.0)
pending becomes current only at next cold start of mini-program. Directory rename is atomic at FS level. If host crashes during swap, pending stays, retry on next launch.
Verification Before Application
Before applying new bundle, verify:
// iOS
let expectedHash = manifest.bundleHash // "sha256:a3f8c2..."
let actualHash = SHA256.hash(data: bundleData).hexString
guard "sha256:\(actualHash)" == expectedHash else {
throw BundleError.hashMismatch
}
Additionally: verify manifest's digital signature (platform signs manifest with private key, client verifies with public). Protects against CDN replacing bundle with malicious code.
If verification fails, delete bundle, keep using current version. Log hash mismatch to analytics for monitoring.
Rollback on Crash
New bundle may contain JS error causing crash loops. Need automatic rollback.
Mechanism: container counts consecutive crashes on mini-program load. Three crashes in a row on startup — revert to rollback/ directory (previous known-working version). Log to analytics, notify developer via portal.
What counts as crash: WKWebView navigation failed, JS threw uncaught exception within 2 seconds of load, or bridge didn't respond to init-handshake in 5 seconds.
On platform side — emergency rollback capability: change currentVersion in manifest to previous. All clients checking manifest download the "old" bundle. Executes in minutes, not hours.
Differential Updates
For large bundles (> 1 MB) — differential patches instead of full replacement. bsdiff algorithm: for v2.3.1 → v2.3.2 update, generate patch file 10-30x smaller than full bundle. Client downloads patch, applies to current bundle, gets new.
Requires storing binary bundle on client (not just extracted files) for patch application. Complicates implementation, but critical for users with slow internet.
Timeline for hot-loading system from scratch (manifest API + CDN + client-side loader with verification + rollback): 6 to 12 weeks. With differential patches, add 3-4 weeks.