Publish

Sollar has two distribution gates, and the difference is not cosmetic.

	Tenant-private	Store
Who publishes	Your organisation, for its own staff	A developer, for anyone
Sollar review	None	Required
Verified entity	You are already a customer	Required
Visible to	Your organisation only	The public catalogue
Countersigned by	Your organisation’s CA	The Sollar store key

If you are building your own ERP for your own employees, you want tenant-private. Your release cycle should not depend on a vendor’s review queue, and it does not.

A package cannot be both. Declaring both channels is a validation error, not a warning.

Tenant-private

manifest.json

"distribution": { "channel": "tenant-private", "tenants": ["acme-corp"] }

sollar build
sollar upload
sollar submit --tenant acme-corp

There is no review. The package is countersigned by your organisation’s CA, so there is still a verifiable chain — Sollar’s client refuses a package without a countersignature from either the store or an organisation CA. What you skip is our queue, not the cryptography.

Your tenant administrator controls which mini apps are available and which permissions are allowed organisation-wide.

Store

manifest.json

"distribution": { "channel": "store" }

sollar submit

You will need a verified entity — an individual with verified identity for apps that touch no sensitive data, or a registered organisation for everything else. Sensitive categories (health, finance, education involving minors) require additional qualification documents.

Version states

Four states coexist:

development  →  trial  →  in review  →  published
(your latest    (named     (ONE at        (what users
 upload)         testers)   a time)        run)

Only one version can be in review at a time. Re-submitting overwrites the one in review rather than queueing behind it.

Trial builds reach named testers only — project members and testers you list explicitly. They must be members of your organisation.

Rollout

sollar release                # everyone at once
sollar release --phased       # 1% → 2% → 5% → 10% → 20% → 50% → 100%

The phased curve is fixed at one step per day, and you can pause at any step. A fixed curve is better than a free percentage because it takes the decision away from the worst moment to make it — nobody chooses a good percentage at 3am with the error graph climbing.

Rollback

sollar rollback 2.4.0

This republishes the code of 2.4.0 as a new version number — 2.4.2 — in about a minute, without review.

It is not a true revert, and that is deliberate: monotonic versions are how clients know they need to update. Moving the number backwards breaks that guarantee and creates ambiguity about what is installed.

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

Mandatory updates

Sollar can force an update independently of you. This is a security mechanism: a mini app with a known vulnerability cannot be left to its developer’s release schedule.

• Recommended — downloaded in the background, applied on next open.
• Mandatory — the client refuses to open the old version. Reserved for security revocation.

What review checks

Beyond the obvious:

1. The manifest validates, and every permission’s purpose is plausible for what the app does.
2. Every host in the network allowlist is justifiable.
3. The CSP meets the minimum — no remote script, no unsafe-eval.
4. An SBOM is present and no dependency carries a known high-severity CVE.
5. No remote script loading, no eval, no obfuscation that defeats review.
6. actions[] describe honestly what they do, and destructive is marked where it is destructive.
7. Report and block paths work; age rating is declared.

Common rejection reasons, several inherited from what WeChat learned the hard way: induced sharing or following (requiring a share before the app becomes usable), false or fraudulent content, auto-playing media, cross-promotion or ranking of other mini apps — and, specific to Sollar, a misleading manifest, actions that lie about being destructive, and any attempt to collect user credentials inside the runtime WebView.

Before you submit to the public store

Read Store compliance. Your mini app runs inside Sollar’s iOS and Android apps, and under Apple Guideline 4.7 Sollar is responsible for everything it hosts — a mini app that violates a guideline puts the whole host app at risk, not just itself.

The one that surprises people most: there is no in-app payment API, and the rules differ by platform. See Monetisation.