Problem: users see old bugs for weeks
Suppose your e-commerce Super App contains a miniapp 'Shopping Cart'. You fix a discount calculation bug, but it takes 2–5 days for the update to pass App Store review. If it's not a critical bug, waiting for the next app release means another 2–4 weeks. As a result, users see the error, conversion drops by 15–20%, and business loses revenue. A hot-loading system for miniapps solves this: you publish a new bundle to a CDN, and within minutes it reaches everyone. But the implementation is simple only in words. We have implemented dozens of such systems — we share the architecture that doesn't crash. Order a hot-loading architecture for your project — we will help avoid typical mistakes.
Hot-loading system architecture
Hot-loading for miniapps is not the same as Hot Module Replacement in Webpack. It is a CDN-based delivery system with version control and rollback capability.
Basic flow:
- Developer publishes a new version of the miniapp (new bundle.zip on CDN)
- Platform updates the manifest — a JSON with metadata and URL of the new bundle
- Super App periodically (or on launch) checks the manifest server
- If the version has changed — downloads the new bundle in the background
- On the next miniapp open — loads the new bundle
The devil is in the details of steps 3–5.
Update check strategies: comparison
| Strategy | Delivery delay | Battery impact | Reliability on mobile networks |
|---|---|---|---|
| Polling on startup | Hours | Low | High |
| Long polling / SSE | Seconds | High | Low |
| Silent push (APNs/FCM) | Minutes | Medium | Medium (depends on iOS Doze) |
In practice, we combine: silent push as the main channel + polling on startup as a fallback for devices where the push didn't arrive. Silent push via APNs delivers the update in an average of 5 minutes — 10 times faster than daily scheduled polling. Polling on startup ensures 99.5% delivery within an hour for all devices.
Why atomic update is critical?
You cannot apply the bundle during an active miniapp session. Replacing files while the WebView is running guarantees a crash.
Solution — staged swap:
/miniapps/com.vendor.app/ current/ <- current active bundle (v2.3.1) pending/ <- downloaded but not yet applied (v2.3.2) rollback/ <- previous bundle for rollback (v2.3.0) pending becomes current only at the next cold start of the miniapp. Renaming a directory is an atomic file-system operation. If the host crashes during the swap, pending remains as is, and the attempt repeats on the next launch.
Directory structure example on iOS and Android
// iOS let baseURL = FileManager.default.applicationSupportDirectory let appDir = baseURL.appendingPathComponent("miniapps/com.vendor.app/") let currentDir = appDir.appendingPathComponent("current") let pendingDir = appDir.appendingPathComponent("pending") let rollbackDir = appDir.appendingPathComponent("rollback") For Android, similar via Context.getFilesDir().
Verification before application
Before applying the new bundle — verification:
// iOS let expectedHash = manifest.bundleHash // "sha256:a3f8c2..." let actualHash = SHA256.hash(data: bundleData).hexString guard "sha256:\(actualHash)" == expectedHash else { throw BundleError.hashMismatch } Additionally: digital signature verification of the manifest (platform signs manifest with private key, client verifies with public key). This protects against attacks where the CDN replaces the bundle with a malicious one.
If verification fails — the bundle is deleted, we continue using the current version. Analytics receives a hash mismatch event for monitoring.
How to protect against crash loops?
The new bundle may contain a JS error that causes a crash loop. Automatic rollback is needed.
Mechanism: the container counts consecutive crashes when loading the miniapp. If 3 crashes in a row on startup — roll back to the rollback/ directory (the previous known working version). Analytics event, developer notification via portal.
A crash is defined as: WKWebView navigation finished with an error, or JS threw an uncaught exception within 2 seconds of loading, or the bridge did not respond to the init-handshake within 5 seconds.
On the platform side — ability for emergency rollback: change currentVersion in the manifest to the previous one. All clients that check the manifest will download the 'old' bundle. This takes minutes, not hours.
Differential updates: saving 10–30 times bandwidth
For large bundles (>1 MB) — differential patches instead of full replacements. The bsdiff algorithm (Colin Percival, 2003): for updating v2.3.1 → v2.3.2, a patch file is generated that is 10–30 times smaller than the full bundle. The client downloads the patch, applies it to the current bundle, and gets the new one. Users with slow internet save up to 95% bandwidth. For a project with 500k users, bandwidth savings from differential patches amount to up to 90%.
Requires storing the binary bundle on the client (not only extracted files) for patch application. Complicates implementation, but is critical for users with slow internet.
Typical problems and solutions
| Problem | Consequences | Our solution |
|---|---|---|
| Old bundle during session | WebView crash | Staged swap on cold start |
| Malicious bundle via CDN | Data leak | Digital signature of manifest |
| Crash loop from new version | User leaves | Automatic rollback after 3 crashes |
| Slow bandwidth | Poor UX | Differential patches (bsdiff) |
What is included in a turnkey hot-loading implementation
- Architecture design: delivery strategy selection, manifest API schema
- Client-side loader implementation (iOS/Android) with verification and rollback
- CDN aggregator and publication API development
- CI/CD integration: automatic bundle publication on merge to main
- API documentation and configuration schema
- Load testing (simulating 1000+ concurrent requests)
- Post-release support: monitoring, alerts, hotfix via emergency rollback
Timelines for implementing a hot-loading system from scratch (manifest API + CDN + client-side loader with verification + rollback): 6 to 12 weeks. With differential patches — add another 3–4 weeks. Get a consultation — we will assess your project and propose the optimal architecture.
Our experience: 10+ years in mobile development
We have implemented hot-loading in the Super App of four major clients with an audience of over 1 million users each. Not a single incident of data loss or miniapp unavailability after more than 500 releases. We use the same approaches described above. Order development — we guarantee reliability and speed.