Store compliance
Sollar ships through the App Store and Google Play. Everything a mini app can do is bounded by what those two stores permit a host app to offer, and the two are not symmetric in the way most people expect.
| Page | |
|---|---|
| Apple App Store | Guideline 4.7 clause by clause, plus 2.5.6, 3.1.1 and 3.1.3(c) |
| Google Play | The interpreter exemption, and the missing B2B carve-out |
| China | ICP filing, and why it sits on your critical path |
The asymmetry
Section titled “The asymmetry”Apple has a policy that names mini apps and permits them. Guideline 4.7, “Mini apps, mini games, streaming games, chatbots, plug-ins, and game emulators”, is an explicit authorisation with explicit conditions.
Google does not. There is no Play policy for superapps or mini apps. Android’s legality runs through a generic exemption in the Device and Network Abuse policy, which exempts from the downloaded-code prohibition anything running “in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a webview or browser).”
This is the reverse of the usual intuition — iOS is the side with explicit permission, Android the side depending on a generic reading. It constrains the architecture: every execution path on Android must terminate in interpreted JavaScript with indirect, mediated access, never a native code loader.
What it means for you
Section titled “What it means for you”Everything runs in a WebView, and that is not negotiable
Section titled “Everything runs in a WebView, and that is not negotiable”Guideline 2.5.6 requires WebKit, worldwide. The entitlement that would allow otherwise is EU-only and out of reach. So a mini app is a web application — see Architecture.
The bridge stays small
Section titled “The bridge stays small”Guideline 4.7.2: “Your app may not extend or expose native platform APIs or technologies to the software without prior permission from Apple.”
Every native capability added to the Sollar bridge requires Apple’s prior approval. That is a
business-development timeline, not a sprint. It is why camera, geolocation and files are standard
Web APIs here and not bridge methods, and why sollar.getDeviceContacts() does not exist.
There is no payment API
Section titled “There is no payment API”A mini app cannot take money inside Sollar. No sollar.requestPayment(), no equivalent of
WeChat Pay or my.tradePay. If you arrive from WeChat you will look for it, so it is stated here
rather than left as silence.
Money works through a contract and an invoice, outside the app — and the rules for that differ by platform:
| iOS | Android | |
|---|---|---|
| Baseline | 3.1.1 requires In-App Purchase; licence keys, QR codes and crypto are prohibited | Play Billing required |
| B2B exemption | Exists — 3.1.3(c) Enterprise Services, for sales direct to organisations for their employees | Does not exist — the policy explicitly covers “business productivity software” and “cloud software and services” |
The exemption that supports the business model on iOS has no Android equivalent. On Android, the sale must be entirely outside the app — a contract, an invoice — and never an unlock inside a mini app. This is counter-intuitive and it is load-bearing, so it appears on every page where it matters.
Permissions do not inherit
Section titled “Permissions do not inherit”Guideline 4.7.3: permission granted to the host does not flow to a mini app. Each asks for its own. Sollar enforces this on both platforms — see Permissions.
Reporting, blocking and age ratings
Section titled “Reporting, blocking and age ratings”Guideline 4.7.1 requires content filtering, a reporting mechanism, timely response, and the ability to block abusive users. 4.7.5 requires an age rating per mini app.
Sollar provides reporting and blocking in the host’s chrome, so they do not depend on a mini app implementing them. You provide the content rating.
The public index
Section titled “The public index”Guideline 4.7.4 requires an index of the software available in the app, with universal links to all of it. That is the public catalogue, and it means the catalogue cannot be closed or invitation-only.
What this section is not
Section titled “What this section is not”It is a working interpretation by the Sollar team of published store guidelines, based on primary sources quoted where they are quoted. It is not legal advice, and several questions here remain open — most importantly whether the App Review Guidelines apply equally to Custom Apps distributed through Apple Business Manager, which our research could not close from a primary source. Open questions are marked as open on the pages where they arise.