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

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.

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: 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/ 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.

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.