# Distribution

> Two gates, four version states, phased rollout, rollback as a new version, and the public index Apple requires.

Source: https://miniapp.sollar.com/platform/distribution/

---

## Two gates

| | **Tenant-private** | **Store** |
|---|---|---|
| Who publishes | The company, or its AI tooling | A third-party developer |
| Sollar review | **None** | Required |
| Verified entity | Already a contracted customer | Required |
| Visibility | The organisation only | Public catalogue |
| Countersigned by | The organisation's CA | The Sollar store key |
| Installation | Administrator provisions, or staff install from the internal catalogue | User installs from the public catalogue |
| Price | Outside the app | Outside the app — see [Store compliance](/compliance/) |

**A package cannot be both.** `distribution.channel` is exclusive, and declaring both is a validation
error. Managed Google Play enforces the same exclusivity for the same reason: channels with
different rules cannot share an artifact.

Precedents: Lark separates self-built from store apps exactly this way. DingTalk does the same for
enterprise-internal applications. And Firefox demonstrated that "unlisted but still platform-signed"
is a workable model — you lose curation, never the signature chain.

## Four version states

Coexisting, following WeChat's model, which is the best-resolved of the ones surveyed:

```
   development  ──▶  trial  ──▶  in review  ──▶  published
   (latest per      (named        (ONE at         (what users
    developer)       testers)      a time)         are running)
```

**One review slot.** Only one version can be in review at a time; resubmitting **replaces** rather
than queues. This avoids a backlog of superseded versions nobody wants any more.

**One development version per developer.** Each team member has their own, and a new upload replaces
it. It is a working state, not a history.

**Named testers.** Only project members and explicitly listed testers reach a trial version, and
testers must be members of the organisation — the tenant is the natural boundary.

## Rollout

Full, or phased.

Phased follows Apple's fixed curve, the best-documented starting point available: **1%, 2%, 5%, 10%,
20%, 50%, 100%**, one step per day, pausable at any time.

A fixed curve beats a freely chosen percentage because it removes the decision from the moment of
stress. Nobody picks a good number at three in the morning with the error graph climbing.

WeChat also offers phased publication but does not document the mechanics publicly — the steps,
rollback limits, or emergency path.

## Rollback

Fast, and as a **new version**, not a true reversal. This is the Chrome Web Store's model: about a
minute, no review, republishing an earlier build under a higher version number.

```sh
sollar rollback --to 2.4.0     # publishes 2.4.2 carrying 2.4.0's content
```

Why not a real reversal: the monotonic version is what tells a client it needs to update. Lowering
the number breaks that guarantee and creates ambiguity about what is installed.

**Rollback skips review** because the code was already reviewed. Publishing never-reviewed code
through this path is abuse, and the platform detects it by comparing hashes against approved
versions.

## Emergency revocation

Distinct from rollback, and covered in [Review policy](/platform/review-policy/): a signed revocation
list consulted at launch with a short TTL; the client refuses the revoked version and updates to a
safe one if there is one; a fully revoked app leaves the catalogue and stops opening.

## Updates

- **Delta updates** — a bsdiff patch against a specific prior version, with a full-download fallback
  when no patch path exists.
- **Merkle verification** — blocks verified as they are read, so a mini app starts before the whole
  package is hashed.
- **Monotonic versions** — the client accepts only a higher version than the one installed.

## The public index

Apple's Guideline 4.7.4 requires:

> *You must provide an index of software and metadata available in your app. It must include
> universal links that lead to all of the software offered in your app.*

[The catalogue at `/apps/`](/apps/) is that artifact, with a universal link per mini app
(`https://sollar.com/app/<id>`).

**This means the public catalogue cannot be closed or invitation-only** if Sollar wants App Store
approval. That is a constraint on the product, not a documentation detail.

> **CAUTION**
**Tenant-private mini apps are the point of tension.** The defensible reading is that a tenant-private
app is not "software offered in your app" in the sense of the guideline — it is configuration
provisioned by a customer's administrator, analogous to MDM.

That reading is defensible, **not confirmed**. And alongside it sits a question our research could
not close from primary sources: whether the App Review Guidelines apply equally to Custom Apps
distributed through Apple Business Manager. That is precisely the question that decides the
tenant-private route on iOS, and it is open.

Two enterprise dead ends are closed with evidence, at least: the **Apple Developer Enterprise
Program requires 100+ employees and is internal-use only**, so it cannot serve a vendor distributing
to many customers; and **Managed Google Play private apps cannot charge anything** and cannot
coexist with a public listing.

## Third-party service providers

WeChat operates a service-provider platform that authorises an external company to administer many
merchants' mini programs, through its own handshake (`component_verify_ticket` → `pre_auth_code` →
authorisation), where the effective scope is the **intersection** of what the merchant granted and
what the provider holds.

It is relevant here because a consultancy building mini apps for several tenants is an obvious case.
It is not in v1, but the permission model is designed knowing it is coming — `vendor_id` and
`actor_token` delegation already have the right shape.

## The China perimeter

Since September 2023, the MIIT's ICP filing (备案) applies to mobile apps and mini programs as well
as websites, and Tencent enforces it inside its own developer portal. Reported service levels:
platform review 1–2 days, SMS verification 24 hours, and the provincial telecommunications bureau
1–20 days.

If Sollar operates a mini app store in mainland China, each mini app needs its own filing, and the
provincial bureau's timeline sits on the developer's critical path. See [China](/compliance/china/).