HTML5 mini-app and downloaded-code App Review checklist
Remote content can be useful, but it cannot hide unreviewed core functionality, unsafe content, or digital commerce outside the reviewed app bundle.
Map which features are in the binary and which are remote HTML5, web, script, or server-driven content. Apple has emphasized that core app features and functionality should be contained in the software binary rather than made possible by referring users outside the approved app, including through HTML5. AppReviewReady interpretation: make the reviewable binary boundary explicit before submission.
Draw the binary boundary
List every feature the app can show after install, then mark whether the logic, UI, commerce, safety controls, and moderation live in the binary or arrive from a server, web view, script, plug-in, configuration, or content package.
Remote configuration is common, but a remotely delivered app store, game platform, gambling surface, donation flow, or digital commerce system can create review risk. The reviewer must be able to evaluate the core product submitted to Apple.
Separate content updates from feature replacement
- Remote articles, catalogs, lessons, menus, events, and media can be ordinary content when the app behavior is stable.
- A remote mini-app platform changes risk when it adds new executable behaviors, purchases, games, or user interaction models.
- A web view should not be used to bypass App Store rules for digital goods, gambling, lotteries, donations, or unsafe content.
- Server-driven UI should still respect privacy labels, age rating, metadata, and review notes.
Make remote content reviewable
Reviewers should see the same remote feature set that users will see at launch. If content depends on flags, regions, accounts, or time windows, provide a deterministic review account and avoid turning on restricted features after approval without a new review decision.
AppReviewReady interpretation: keep a launch flag freeze. Changing remote modules after approval can invalidate the evidence that justified the submission, especially for commerce, social, health, finance, or child-facing experiences.
Audit remote content for policy-sensitive areas
- Check whether remote modules introduce purchases, subscriptions, external payment links, donations, gambling, contests, or random rewards.
- Verify remote content does not exceed the app's age rating or privacy disclosures.
- Test UGC reporting, moderation, blocking, and takedown for web-delivered community surfaces.
- Confirm scripts cannot expose private data, credentials, or unsupported device capabilities.
- Record who can publish remote modules and what approval workflow they follow.
Document the remote-content model
The note does not need to expose internal architecture unless it helps review. Internally, the model is critical because it tells growth and content teams which remote changes are safe and which require release review.
Log every remote module release with owner, policy-sensitive areas, and rollback plan. This gives the team a way to prove that post-approval content updates stayed inside the reviewed boundary rather than silently shipping a different app.
Remote content review model: Core features in binary: [list] Remote content types: [articles, lessons, HTML5] Restricted features excluded: [commerce, gambling] Flag freeze date: [date] Review account state: [details] Publisher approval workflow: [owner] Post-approval change policy: [when new review is required]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check remote feature risk
Review binary boundaries, remote content, commerce, and safety controls before submission.
Open the tool