How App Distribution Works When There's No Install: The Mini-App Delivery Pipeline

The app store gives you install-based distribution. Mini-apps give you fetch-based distribution. Here's how the second one actually works under the hood — and why Apple just formalized it.

Quick context before the code. The install funnel is saturated: 65% of US smartphone users download zero new apps in a typical month, users spend 87% of mobile time in five apps, CPI is $3.50+ and 30-day retention sits around 25%. Meanwhile Apple's Mini App Partner Program (late 2025) formalized the alternative — embedded mini-apps with WebKit standards, a 3–5 day express review channel, and a defined 15% commission. When the store owner builds a tax structure for the channel that bypasses installation, that channel is officially infrastructure.

So let's look at how that channel actually works, technically. Because "no install" doesn't mean "no distribution" — it means a completely different delivery pipeline.

Install-based vs fetch-based distribution

App store model (install-based):
  publish → store review (days-weeks) → user finds it → downloads 50-200MB
  → OS installs → home screen → hope they open it again
  update = repeat the entire cycle, user must accept the download

Mini-app model (fetch-based):
  publish → platform review → available in host
  → user taps entry point → runtime fetches package (~2-10MB) → runs
  update = next fetch gets the new version. User does nothing.

The fundamental shift: in the store model, distribution happens once, up front, heavily. In the mini-app model, distribution happens continuously, on demand, lightly. The package isn't installed onto the OS — it's fetched into a runtime.

The delivery pipeline, step by step

1. Publish: the package and its manifest

A mini-app is packaged as a versioned bundle with a manifest:

{
  "appId": "miniapp_store_locator",
  "version": "2.4.0",
  "package": {
    "url": "https://cdn.platform.com/pkgs/store_locator/2.4.0.zip",
    "hash": "sha256:9f2ab...",
    "sizeKb": 3840
  },
  "runtime": { "minVersion": "3.1.0" },
  "permissions": ["location:read", "network:api.retailer.com"],
  "rollout": { "strategy": "gray", "initial": 5 }
}

The hash matters: the runtime verifies package integrity before executing anything. The permissions matter: they're granted at publish time by the platform, not requested at runtime from the user's OS.

2. Discover: entry points instead of store listings

There's no store page. Discovery is contextual — the host surfaces the mini-app where it's relevant:

// Entry points are host-side configuration, not user-side search
entryPoints: [
  { type: "icon_grid",  section: "services" },
  { type: "deep_link",  pattern: "app://store-locator" },
  { type: "contextual", trigger: "user_views_order", position: "footer" },
  { type: "qr_scan",    payload: "miniapp_store_locator" },
  { type: "search",     keywords: ["store", "location", "near me"] }
]

This is the economic core of the model: discovery happens at the moment of need, inside an app the user already opens. The $3.50 CPI is replaced by an entry-point tap.

3. Fetch: lazy, cached, verified

When the user taps, the runtime resolves and fetches:

async function launch(appId) {
  const meta = await registry.resolve(appId, {
    userCohort: user.cohortId,      // gray release: which version is THIS user on?
    runtimeVersion: RUNTIME_VERSION
  });

  let pkg = cache.get(appId, meta.version);
  if (!pkg) {
    pkg = await cdn.fetch(meta.package.url);
    if (sha256(pkg) !== meta.package.hash) throw new IntegrityError(appId);
    cache.put(appId, meta.version, pkg);
  }

  return sandbox.run(pkg, meta.permissions);  // execute inside isolation
}

Three properties worth noting:

• Cohort-aware resolution — the registry answers "which version for this user," which is how gray releases work at the distribution layer. 5% of users fetch 2.4.0; the rest still get 2.3.x.
• Content-addressed caching — second launch is instant and offline-tolerant; the fetch only recurs when the version changes.
• Integrity verification — the hash check means a compromised CDN can't inject modified code.

4. Update: distribution as a continuous property

This is where fetch-based distribution diverges most sharply from install-based:

# Publishing v2.4.1 — no user action, no store cycle
release:
  appId: miniapp_store_locator
  version: 2.4.1
  rollout:
    initial: 5%
    health_check: { crash_rate: "<0.5%", p95_launch: "<1200ms" }
    auto_widen: [25%, 50%, 100%]
  rollback:
    to: 2.4.0
    trigger: health_check_breach   # automatic, seconds, per-mini-app

Users on 2.4.1's cohort simply fetch the new package on next launch. If health checks breach, the registry re-points the cohort at 2.4.0 — rollback is a metadata change, not a re-installation. Compare this to the store model, where a bad release means an emergency review submission and days of exposure.

5. The iOS layer: what Apple's program standardizes

Apple's Mini App Partner Program adds a formal layer for iOS hosts:

- Rendering: WebKit-based (HTML5/CSS3/JS) — the runtime's iOS rendering path
- Review: mini-apps reviewed with the host, express channel 3-5 business days
- Payments: virtual goods route through IAP at a defined 15% rate
- Data: storage on compliant servers, disclosed usage rules

For the delivery pipeline above, this mostly constrains the rendering engine choice on iOS and the payment flow — the fetch/cache/rollout mechanics remain the platform's own. The strategic reading: the pipeline is now legitimate enough that the OS vendor wrote rules for it.

What this means if you're building the channel

Running fetch-based distribution for your own app — turning your app into a host where internal teams and partners publish — means owning this pipeline: a package registry with cohort resolution, CDN delivery with integrity verification, a sandboxed runtime across platforms, and the release-management layer (review gates, gray rollout, health-checked auto-rollback) on top.

That's a lot of infrastructure to build from scratch, which is the build-vs-buy point: FinClip provides the pipeline as a product — cross-platform runtime (iOS aligned with Apple's WebKit standards, Android, HarmonyOS, desktop, IoT), package management, gray release, rollback, permissions, and analytics in one console. Your services get fetch-based distribution; your engineering team doesn't spend a year building the plumbing.

The test

1. Can you ship a service update to users without any store submission or user action? (Fetch-based updates.)
2. Can 5% of users be on the new version while 95% stay on the old — resolved at fetch time? (Cohort-aware registry.)
3. Is every package integrity-verified before execution? (Hash checks — non-negotiable once partners publish.)
4. Is rollback a metadata change measured in seconds, not a re-release measured in days?

If your distribution still requires an install for every change, you're paying store-funnel economics on every iteration. Which part of the pipeline would you build first? 👇

---

More on mini-app distribution, runtimes, and platform infrastructure → https://super-apps.ai/