Super App architecture development for mobile app

Super App Architecture Development

A Super App is an application that hosts multiple mini-applications within itself. WeChat, Grab, Gojek, Kaspi — all represent different implementations of the same concept: users never switch between apps; everything happens within a single platform. For business, this means the platform owner controls a marketplace of mini-programs where partners publish their services.

Architecturally, a super app is far more than just "a large tabbed application." It's a platform featuring an isolated mini-program execution system, shared authentication context, native bridge APIs, and a mini-program distribution mechanism.

Architecture Layers

Host Application (Shell). Responsible for: user authentication and session management, top-level navigation (tab bar, home feed), mini-program catalog, mini-program lifecycle management (launch, pause, destroy), and common services (payments, geolocation, push, camera) through a unified Bridge API.

Mini Program Runtime. An isolated execution environment for each mini-program. On iOS — WKWebView with restricted JS API, or a native container for compile-time plugins. On Android — WebView with WebViewClient + addJavascriptInterface, or DexClassLoader for native plugins. Each mini-program runs in its own WebView/container with isolated localStorage and cookies.

Bridge API. Mini-programs have no direct access to native APIs. All calls go through the Bridge: MiniApp.bridge.call("payment.pay", { amount: 100 }, callback). The Bridge translates the call into native code executed by the host. The host decides whether to permit the call (checking mini-program permissions), execute it, and return the result. This is the critical security checkpoint.

Sandbox and Isolation

Each mini-program receives only what the host explicitly grants:

• Access token for its own backend (not the host's master token)
• Permission for specific Bridge APIs (payments only if partner passes verification)
• Isolated storage (keys prefixed with mini_program_id)
• Restricted network access via WebView content policy — only whitelisted domains for the mini-program

Content Security Policy in WebView: on Android set WebSettings.setAllowUniversalAccessFromFileURLs(false) and enforce strict CSP headers. On iOS, WKWebView with WKContentRuleList blocks XHR to unauthorized domains.

Mini-programs cannot: access data from other mini-programs, read host tokens, or execute native code outside the Bridge API.

Mini-Program Lifecycle Management

Mini-programs transition through states: downloaded → launched → active → paused → destroyed. The host manages this like an OS manages applications.

Caching and Updates. A mini-program is a zip archive (JS/HTML/CSS + manifest with version). First run: download from CDN → validate signature → extract to filesDir. Subsequent runs: check version → if update available, background-load new archive → next launch opens new version. Users don't wait for downloads on repeat opens. Cache invalidation follows semver: major mini-program version requires immediate update, minor version updates in background.

Memory Management. Keep no more than 3 active WebViews simultaneously (configurable). Opening a 4th triggers cleanup of the least recently used (LRU). WKWebView on iOS consumes significant memory rendering heavyweight mini-programs — monitor via os_proc_available_memory(), proactively clear on applicationDidReceiveMemoryWarning.

Authorization: SSO within Super App

User authenticates with the host once. The mini-program receives a short-lived access token for its backend via Bridge API: bridge.call("auth.getToken", { scope: "mini_program_x" }, callback). The host issues a token with limited scope, valid for 15 minutes. The mini-program exchanges this for its own JWT on its backend. The host never shares its master token.

Payments through Bridge

The payment Bridge is the most sensitive component. A mini-program calls bridge.call("payment.requestPay", { orderId, amount, currency }) → the host displays native payment confirmation UI (not WebView!) → user confirms with biometrics → host processes payment through its payment system → returns result to mini-program. The mini-program never sees user payment data.

Case Study. Fintech super app: host built in Flutter (navigation, auth, payments via Stripe), 15 mini-programs (loans, insurance, utility payments, investments) — mix of native plugins and WebView programs. Bridge API: 40+ methods. Mini-program marketplace with moderation: partner uploads zip → CI runs security scan (static JS analysis via ESLint security rules, manifest validation) → manual review → publication. Launch time for cached mini-programs: 200–400 ms.

Technology Stack

Timeline

Pricing is calculated individually. A Super App is a platform product requiring a team with expertise in native development, security, and DevOps.