# Apple App Store

> Guideline 4.7 clause by clause, plus the WebKit requirement, in-app purchase and the enterprise exemption.

Source: https://miniapp.sollar.com/compliance/apple/

---

Apple is the platform with an **explicit** mini app policy. Guideline 4.7 names the category and
authorises it under conditions. Those conditions shape the whole platform.

Quotations are from the App Review Guidelines. Read them at
[developer.apple.com/app-store/review/guidelines](https://developer.apple.com/app-store/review/guidelines/) —
the guidelines change, and the version in front of a reviewer is the one that counts.

## 4.7 — the authorisation

> *Apps may offer certain software that is not embedded in the binary, specifically HTML5 mini apps,
> mini games, streaming games, chatbots, plug-ins, and game emulators.*

HTML5 mini apps are named. That is the permission Sollar operates under, and it is why the runtime
is a WebView rather than anything more ambitious.

## 4.7.1 — moderation

> *…include a method for filtering objectionable material, a mechanism to report content and timely
> responses to concerns, and the ability to block abusive users.*

**Sollar's implementation:** report and block live in the **host's chrome**, reachable from inside
any mini app. They do not depend on the mini app implementing them — a malicious mini app would not.
A user can block a mini app; an administrator can block one organisation-wide. Response times are
published.

**Yours:** a monitored `vendor.contact` in the manifest. It is where reports about your app go.

## 4.7.2 — the constraint that shapes the bridge

> *Your app may not extend or expose native platform APIs or technologies to the software without
> prior permission from Apple.*

This single sentence is why the Sollar bridge is small.

Every native capability exposed to mini apps is a compliance question needing Apple's **prior
permission** — a business-development gate with a lead time, not an engineering decision with a
sprint.

So the rule is **web first**:

- Camera, microphone, geolocation, files, notifications, biometrics → standard Web APIs the engine
  already provides, with the engine's own prompts. These are capabilities of the web platform, not
  extensions of a native API.
- `sollar.*` covers **only Sollar's own domain** — identity, room context, sending a message, agent
  actions, Sollar file storage.

`sollar.sendMessage()` is not extending a platform API. `sollar.getDeviceContacts()` would be, and
that is why it does not exist.

## 4.7.3 — permissions do not inherit

> *…may not extend the permissions granted to your app to the software.*

Permission the user granted to Sollar does not flow to a mini app. Each mini app asks for its own,
declares a `purpose`, and can be revoked independently.

Sollar enforces this on Android too. It is a sound rule regardless of who requires it.

## 4.7.4 — the public index

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

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

Consequence: **the public catalogue cannot be closed or invitation-only.**

> **CAUTION**
**Tenant-private mini apps are the unresolved part.** The defensible reading is that a tenant-private
app is not "software offered in your app" — it is configuration provisioned by a customer's
administrator, analogous to MDM, and never offered to the public.

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

## 4.7.5 — age ratings

> *Software offered in your app must be rated with the appropriate age rating.*

Declared per mini app in the manifest. Sollar surfaces it in the catalogue and in the install prompt.

## 2.5.6 — WebKit, worldwide

> *Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript.*

The Embedded Browser Engine Entitlement that would permit an alternative exists **only in the
European Union** — not Japan, not the United States — and qualifying requires 90% on the Web
Platform Tests, 80% on Test262, a memory-safe implementation language and a 30-day CVE remediation
commitment. Out of reach, and geographically useless even if it were not.

This is the first of three reasons the runtime is a WebView. The other two are in
[Architecture](/platform/architecture/), and one of them is that WKWebView's WebContent process has
JIT while an in-process engine does not — so the alternative would be *slower*, not just illegal.

## 2.5.2 — no downloaded executable code

> *Apps should be self-contained… and may not read or write data outside the designated container
> area, nor may they download, install, or execute code which introduces or changes features or
> functionality of the app.*

A mini app is interpreted JavaScript running in the WebView, inside the container, mediated by the
bridge. 4.7 is the specific authorisation that makes this consistent with 2.5.2; the CSP floor of
`script-src 'self'` is what keeps a mini app from reaching outside its verified package for code.

## 3.1.1 — in-app purchase

> *If you want to unlock features or functionality within your app… you must use in-app purchase.*

The guideline also prohibits unlocking through licence keys, QR codes and cryptocurrencies.

**Therefore: Sollar has no payment API.** No `sollar.requestPayment()`, no equivalent of WeChat Pay.
A mini app cannot unlock features for money inside Sollar.

## 3.1.3(c) — the enterprise exemption

> *Enterprise Services: Apps that are sold directly by you to your organization or to other
> organizations for use by their employees…*

This is what supports the business model on iOS: Sollar sells to a company; the company's employees
use it. Money moves through a contract, outside the app.

> **DANGER**
**This exemption has no Google Play equivalent.** Play Billing's policy explicitly covers *"business
productivity software"* and *"cloud software and services"*. The carve-out that works on iOS does not
work on Android, and assuming symmetry here is the mistake this page exists to prevent.

See [Google Play](/compliance/google-play/).

## 5.3 — real money gaming, contests, lotteries

Applies per mini app. Anything in this territory needs its own licensing and geographic restriction,
declared at submission. Sollar's review refuses it without documentation.

## Dead ends, closed with evidence

| Route | Why it does not work |
|---|---|
| Apple Developer Enterprise Program | Requires 100+ employees and is **internal use only**. A vendor cannot distribute to many customers through it. |
| Ad-hoc distribution | 100 devices, one year. Not a distribution channel. |
| TestFlight as production | Builds expire after 90 days. Not a distribution channel. |

## Submission checklist

Before Sollar itself submits a client build:

1. The public index at `/apps/` is live, with a universal link per store mini app (4.7.4).
2. Report and block are reachable from inside any mini app, in the host's chrome (4.7.1).
3. Every mini app has a content rating (4.7.5).
4. No mini app permission inherits from the host (4.7.3).
5. The bridge exposes no native platform API beyond what Apple has approved (4.7.2).
6. Every runtime is WKWebView; no alternative engine anywhere in the binary (2.5.6).
7. No mini app can unlock paid functionality in-app (3.1.1), and the enterprise route is documented
   for review (3.1.3(c)).
8. Review notes explain the mini app model, name the guideline, and provide a demo account with at
   least one installed mini app.

Point 8 is not bureaucracy. A reviewer encountering a superapp without an explanation reaches for
2.5.2 and rejects it. Naming 4.7 in the review notes is what makes it a short conversation.