Mini Programs system inside mobile Super App

Mini Programs System Implementation in Mobile Applications

While a super app is a complete platform, the mini-programs system is its specific technical component. This covers how a mini-program launches within the host application, how it accesses native APIs, how it updates without App Store reviews, and how it remains isolated from other programs and the host.

Mini-Program Runtime

Two fundamentally different approaches exist.

WebView-based. A mini-program is a web application (React, Vue, or custom DSL like WeChat WXML/WXSS). It runs in an isolated WKWebView (iOS) or WebView (Android). Standard web technologies, low entry barrier for partners, cross-platform code portability. Drawbacks: performance below native levels, no access to complex native APIs without Bridge.

Native plugin-based. A mini-program is compiled native code (Android: DEX via DexClassLoader; iOS: compile-time Swift Package). Native performance, full API access through controlled interfaces. Drawbacks: App Store prohibits executable code downloads on iOS, so native plugins on iOS must be included in the binary at build time.

In practice, we use a hybrid approach: basic partner services via WebView, critical in-house mini-programs as native plugins.

Mini-Program Package Format

A mini-program is distributed as a zip archive with a manifest:

{
  "id": "com.partner.loans",
  "version": "2.3.1",
  "minHostVersion": "3.0.0",
  "entryPoint": "index.html",
  "permissions": ["payment", "geolocation"],
  "allowedDomains": ["api.partner.com", "cdn.partner.com"],
  "signature": "sha256:abc123..."
}

Upon loading, the host: verifies the archive signature (RSA-PSS with partner's public key), checks minHostVersion compatibility, validates permissions against the partner's allowed list, and extracts to an isolated directory. Launch occurs only after successful verification.

Bridge API: Design and Security

The Bridge is the sole contact point between mini-program and host. Request-response architecture:

On the mini-program side (JS):

MiniAppBridge.call('payment.pay', {
  orderId: 'order-123',
  amount: 99.99,
  currency: 'USD'
}).then(result => {
  // result.transactionId
}).catch(err => {
  // err.code, err.message
});

On the host side, the Bridge:

1. Receives the call via WKScriptMessageHandler.userContentController(_:didReceive:) (iOS) or @JavascriptInterface method (Android)
2. Parses method and params
3. Checks: does this mini-program have permission to call payment.pay?
4. If yes — executes native code (displays Payment UI, processes transaction)
5. Returns result via webView.evaluateJavaScript("MiniAppBridge._resolve(requestId, result)")

Each Bridge method has an explicit permission list. Calling a method without the required permission triggers a synchronous PERMISSION_DENIED error. Permissions are issued during partner registration, stored on the server, and cached in the host.

Isolated Storage and Sessions

Each mini-program receives a namespace in local storage: keys like {mini_program_id}:{key}. No direct access to host SQLite or SharedPreferences. Access only through Bridge methods storage.set / storage.get / storage.remove with enforced namespacing.

WebView localStorage is also isolated: each mini-program launches with a WKWebViewConfiguration with a separate WKWebsiteDataStore.nonPersistent() or named persistent store. On Android, WebStorage with a custom directory and cross-origin access prevention.

User Session. A mini-program gets an access token only through Bridge auth.getToken(). The host issues a token valid for 15 minutes, bound to mini_program_id, with limited scope. The mini-program never sees the user's master JWT.

Mini-Program Updates

Updates happen without App Store review. The sequence:

1. On mini-program launch (or scheduled background check), the host verifies the current version via GET /mini-programs/{id}/version
2. If the server returns a newer version, download the archive in background
3. Verify the new archive's signature
4. On next mini-program launch, activate the new package
5. Previous version saved as backup for rollback if needed

Forced updates: if the new package's minHostVersion is incompatible with the current host, display an "App update available" screen instead of launching the mini-program.

Debugging and DevTools for Partners

Mini-program developers need convenient tools. We provide:

• Simulator mode: local server (localhost:8080) as mini-program source instead of CDN — the host reads files directly without signature verification (debug builds only)
• Bridge Inspector: log all Bridge calls to Xcode debug console / Android Studio Logcat
• Mock Bridge: JS library (mini-program-bridge-mock) for browser testing without the host

Case Study. Marketplace partner ecosystem: 8 partners, 23 active mini-programs (12 WebView, 11 native plugins on Android / compile-time on iOS). Bridge API: 55 methods. Average cold start time for mini-programs (first in session) — 380 ms on iPhone 14. Warm start (returning after pause) — 80 ms. Background update: 70% of users receive new mini-program versions without restarting the host.

Mini-Programs System Implementation Timeline

Pricing is calculated individually after analyzing Bridge API requirements, partner count, and security requirements.