Apple App Store

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 — 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/ 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, 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.

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.