Mini-Program Marketplace Implementation in Super App
A mini-program marketplace is not a catalog with search. It's a verification, distribution, monetization, and version control system embedded in a mobile app. App Store for mini-apps, only working in real time without Apple's 24-72 hour review.
Three Layers of Marketplace
The marketplace consists of three independent subsystems that teams regularly confuse:
Storefront — UI inside Super App: catalog, search, categories, personalized recommendations, launch history. Usually a native app screen or a separate WebView mini-app acting as a catalog.
Distribution Backend — server storing each mini-program's bundle, managing versions, serving manifest.json with metadata, and handling update requests. This is CDN + metadata API + version storage.
Review System — developer portal where they upload new versions, track review status, get feedback. On the admin side — a review queue with tools for automated and manual analysis.
How Mini-Program Upload and Launch Works
User taps a mini-program icon. Behind the scenes:
- Container checks local cache: is the mini-program's bundle present? Is the version current?
- If not or outdated, request the bundle from CDN (ZIP with JS/HTML/CSS/assets)
- Bundle extracts to a protected app directory (not
Caches— system can delete without notice, but toApplication Supporton iOS orgetFilesDir()on Android) - Bundle signature verification — SHA-256 hash signed with the platform's private key
- Load into WebView, initialize bridge
Step 4 is critical. Without signature verification, a man-in-the-middle attack can replace the bundle with malicious code. Signature verification uses the public key baked into the host binary at compile time.
Cold start time (first load): 1.5–4 seconds depending on bundle size and connection speed. Target for warm start (from cache): < 800 ms. To achieve this: parallel WebView initialization and bundle extraction, prefetch manifest.json in background on each Super App launch.
Versioning and Updates
Mini-program manifest file:
{
"id": "com.vendor.miniapp",
"version": "2.3.1",
"minContainerVersion": "4.0",
"bundleUrl": "https://cdn.superapp.com/bundles/vendor/2.3.1/bundle.zip",
"bundleHash": "sha256:a3f8...",
"permissions": ["location.read", "camera"],
"size": 186432
}
minContainerVersion is critical. If a mini-program uses an API added in container version 4.0, users on older Super Apps won't launch it. The container checks compatibility at startup and shows an "Update app" screen instead of crashing.
Update strategy: background update on every Super App launch. The container checks manifests of all installed mini-programs in the background and downloads new bundles without user involvement. Next time the mini-program opens, it's already updated.
Review System: Automation and Manual Checks
Automated checks when uploading a new version:
- Static JS analysis: forbidden patterns (eval, dynamic imports from external URLs,
window.parentaccess) - Manifest permissions check: requested rights match API calls in code
- Known vulnerability scan in npm dependencies (Snyk or npm audit integration)
- Bundle size within limits (typically < 2 MB for main bundle)
- Minimum container version is correct
Manual review is for new mini-programs and cases where automation found warnings. The review team gets a queue of tasks with automated check results, screenshots (generated via headless simulator), and the developer's description.
Monetization: Paid Mini-Programs and In-App Purchases
If the platform supports mini-program monetization, the marketplace must manage payment relationships. Two typical scenarios:
One-time access purchase — user pays to unlock a mini-program. Payment goes through Super App (Apple Pay / Google Pay / card), access confirmation stored on platform backend. Mini-program checks access token via bridge on startup.
Commission on in-app transactions — mini-program uses the container's payment API, platform takes a percentage of each transaction. Requires strict control: mini-programs must not bypass the payment bridge and accept payments directly.
Analytics for Developers
The developer portal should include analytics: launch count, retention, crash rate by version, average cold start time. This is standard expectation from third-party developers — without this data they can't assess their product quality.
Collect data on the container side (not forwarding raw event streams to mini-apps), aggregate on backend, and expose through REST API of the developer portal.
Timeline for implementing a complete marketplace: 3 to 7 months depending on review system requirements, monetization, and platform count. Storefront + CDN distribution only without developer portal: 6 to 10 weeks.