# Store compliance

> What Apple and Google require of a superapp hosting third-party mini apps — and what that means for what you can build.

Source: https://miniapp.sollar.com/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](/compliance/apple/) | Guideline 4.7 clause by clause, plus 2.5.6, 3.1.1 and 3.1.3(c) |
| [Google Play](/compliance/google-play/) | The interpreter exemption, and the missing B2B carve-out |
| [China](/compliance/china/) | ICP filing, and why it sits on your critical path |

## 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

### 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](/platform/architecture/).

### 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

**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.

> **CAUTION**
Anti-steering is under active litigation in the United States (*Epic v. Apple* and its aftermath).
The economics of monetisation in that market may change before Sollar launches. Nothing on these
pages should be read as a settled position on US anti-steering.

### 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](/guides/permissions/).

### 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

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](/apps/), and it means the catalogue cannot be closed or
invitation-only.

## 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.