Your Licensed HTML5 Catalogue Can Ship Inside an iOS App. Every Title in It Goes Through App Review.

Shipping a licensed HTML5 catalogue inside an iOS app puts every game through App Review: Apple's Guideline 4.7 covers mini games, and the 15% rate has terms. The wrapper build most licensees budget two sprints for is now a compliance project with a per-title checklist, and the discount everyone read about in the headlines may not be yours to claim.

The plan is always the same. You have licensed a few hundred HTML5 games, the web portal is live, and somebody in the room says the obvious thing: wrap it in a WebView, put it on the App Store, get a second distribution channel for the cost of a sprint.

That plan was defensible in 2023. It is not the same plan now, because Apple has spent the last two years writing rules specifically about the thing you were quietly doing.

🍏 November 2025 Closed the Grey Zone

Guideline 4.7 first grew teeth in the 25 January 2024 guidelines revision, which set out new requirements for mini apps, mini games, streaming games, chatbots and plug-ins. Plenty of operators read it as being about WeChat-style super apps and cloud gaming clients, and carried on shipping HTML5 catalogues in WebViews as though the rule were about somebody else.

The 13 November 2025 revision removed that reading. Apple's own change summary for that release states that 4.7 "clarifies that HTML5 and JavaScript mini apps and mini games are in scope of the guideline." Same day, Apple announced the Mini Apps Partner Program. The two are one move.

Read the opening of Guideline 4.7 as it stands, because the liability sentence is the whole post:

"You are responsible for all such software offered in your app, including ensuring that such software complies with these Guidelines and all applicable laws. Software that does not comply with one or more guidelines will lead to the rejection of your app."

One title out of three hundred. That is the exposure. Not a warning on the title, not a takedown of the title — rejection of the app. If you licensed a catalogue on a spreadsheet and have never played half of it, App Review is about to become your QA department, and it bills in review cycles.

📇 4.7.4 Wants an Index and a Universal Link for Every Game

The text is short: "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."

For a 300-title catalogue that means 300 universal links and a maintained index that stays true as titles rotate in and out. Most licensed portals already have per-game routes, so this is often a day of work rather than a rebuild. The portals that struggle are the ones rendering every game through a single player route with a query string, or worse, through a JavaScript-only state change with no addressable URL at all.

There is a real upside buried in the obligation. Once every title is individually addressable, it is deep-linkable — from a paid campaign, from a carrier portal, from an email, from search. Operators building HTML5 game catalogues tend to under-build per-title URLs and then wonder why acquisition only ever lands on the homepage.

One caution before you make all of it publicly addressable: check the platform grant in your licence. Non-exclusive HTML5 deals frequently limit distribution to web, and "web" does not automatically mean "inside a native iOS binary you charge for." That distinction is cheap to clarify before a build and expensive afterwards.

🔌 4.7.2 Sits Directly on Top of Your Ad Stack

This is the clause that should decide whether the iOS build happens at all: "Your app may not extend or expose native platform APIs or technologies to the software without prior permission from Apple."

Now describe the standard wrapper pattern honestly. A native shell hosts a WebView. A JavaScript bridge lets the game call out to a native ad SDK for interstitials and rewarded video, to native haptics, to native storage for save state, and sometimes to StoreKit. That bridge is the reason the wrapper earns anything at all — mediated native ad inventory is a deeper demand pool than whatever a web ad tag pulls inside a WebView.

As written, that bridge is exactly what 4.7.2 describes. "Without prior permission from Apple" is a real escape hatch, not a rhetorical one, but it is a request with an owner, a queue and a possible no. Plan for the no and the yes is upside.

If the bridge is off, your in-app monetization collapses back to web ad inventory rendered inside a WebView. I am not going to quote you an eCPM delta, because the public benchmarks for in-WebView web inventory against mediated native inventory are vendor-published and disagree with each other. What is not in dispute is the direction: it is worse, and the gap is large enough to invert the business case for an ad-funded wrapper. Model that scenario first, not last. If the numbers only work with the bridge, you do not have a plan — you have a permission request. Anyone reasoning about portal monetization should run this as the base case rather than the pessimistic one.

🔞 4.7.5 Needs Per-Title Age Data Your Licence Probably Doesn't Include

"Your app must provide a way for users to identify software that exceeds the app's age rating, and use an age restriction mechanism based on verified or declared age to limit access by underage users."

Your app carries one age rating. Every title that exceeds it must be flagged to the user and gated behind verified or declared age. Apple's Declared Age Range API is the intended mechanism.

Here is where licensing paperwork fails you. A typical catalogue delivery includes title, slug, thumbnail, description, category, orientation, dimensions and a build URL. It very rarely includes an age classification per title, and almost never one mapped to Apple's rating system. So the day you decide to ship on iOS, somebody on your side classifies several hundred games by hand, using judgement, and carries the consequences of getting it wrong.

That is not an argument against shipping. It is an argument for adding per-title age classification to the deliverables list in the licence, alongside the assets. It costs nothing to ask for at signature. It costs a month of somebody's life to retrofit. The same discipline pays off on the Android side, where every Android game you publish faces its own content-rating questionnaire.

💬 4.7.1 Assumes Your Games Are Social

4.7.1 requires software offered under the rule to follow the privacy guidelines in 5.1, to follow Guideline 3.1 for digital goods, and to "include a method for filtering objectionable material, a mechanism to report content and timely responses to concerns, and the ability to block abusive users."

A single-player match-3 has no abusive users to block, and reviewers apply guidelines to what an app actually does. But read your catalogue again before you assume the clause is inert. Leaderboards with player-entered nicknames are user-generated content. So are in-game chat, custom avatars, drawing games and anything with a shareable player-made level. If any of that is in the catalogue, you have inherited a moderation obligation for content you licensed and did not build.

Note the phrase "timely responses to concerns." That is not a feature you ship. It is a rota, an inbox and a response-time commitment — a running cost, paid monthly, forever.

💸 The 15% Rate, and the Word "Independent"

The headline from 13 November 2025 was the commission. Apple's Mini Apps Partner Program page states that participating developers "earn 85% of qualifying In-App Purchase sales within qualifying mini apps" — a 15% commission against the standard 30%. The same page notes that the App Store has supported mini apps and games since 2017; what is new is the rate and the rulebook, not the format.

The entry requirements are substantial. Per Apple's program page, a host app must be on the App Store for iOS and iPadOS, support the Advanced Commerce API, the Declared Age Range API, Apple's In-App Purchase system and specific App Store Server API endpoints, provide an approved manifest of hosted mini app metadata, and comply with 4.7 throughout.

The Advanced Commerce API is its own gate. Apple announced it in January 2025 for developers running exceptionally large content catalogues, subscription libraries from multiple creators, and subscriptions with add-ons; TechCrunch's coverage that month, and Apple's own documentation, both make clear that eligibility is granted per app, on request. It is not a checkbox in App Store Connect. Classic App Store Connect products cannot be used for these transactions at all.

Then there is the qualifying condition that matters most to anyone in licensing. PocketGamer.biz, reporting on the launch in 2025, describes the reduced rate as applying where "mini apps are independent and not controlled by the host app developer, and that purchases are tied to a single mini app." Apple's program materials frame qualifying mini apps the same way: independent third parties, not software the host developer controls.

Point that at a licensed catalogue and the answer is genuinely unclear. The games were made by independent third-party studios — that is the entire premise of a licensing deal. But you host them, you often reskin them, you set the storefront, and in a source-code or exclusive arrangement you may own the build outright. Whether that reads as "independent" is Apple's determination, made per app, and I have not seen a published decision covering a licensed games catalogue either way. Treat the 15% as a question to ask Apple in writing, not a line in your model.

And notice the asymmetry. If your catalogue is ad-funded with no in-app purchases at all — which describes most licensed arcade portals — you carry the entire 4.7 obligation and qualify for none of the reduced rate, because there are no qualifying purchases to discount. The compliance load is unconditional. The discount is not.

🧾 What to Fix in the Licence Before You Budget the Build

None of this makes an iOS build a bad idea. It makes it a thing to buy correctly. Before signing your next catalogue deal, get these into the agreement:

• An explicit platform grant covering native app distribution on iOS and iPadOS, not a generic "web" or "digital" grant that a licensor can later read narrowly.
• Per-title age classification as a delivery item, supplied with the assets, ideally mapped to a named rating system rather than the licensor's internal categories.
• Content warranties and an indemnity that contemplate store rejection — not just IP claims. The failure mode here is a store pulling your app over one title, and your contract should say who wears that.
• A stable, addressable public URL per title, contractually permitted, so 4.7.4's universal-link requirement is not a renegotiation.
• A defined takedown window: when Apple flags a title, how many days does the licensor have to supply a fix or authorise removal? Put a number on it.
• Clarity on who else ships this catalogue. Not a legal risk — a store-level one. Ten licensees shipping the same 300 games into the same store is a pattern reviewers notice.

🧭 Ship It, or Keep It on the Web?

The honest decision frame is narrow. An iOS wrapper around a licensed HTML5 catalogue earns its build cost when three things hold: you have a subscription or paid model that clears IAP economics rather than an ad-only model, your licence genuinely grants native distribution, and you can either live without the native ad bridge or you have asked Apple and been told yes. Miss any of the three and the honest answer is that the catalogue belongs on the web, where you keep the ad revenue net of your own stack and nobody rejects your homepage over one title.

The concrete next step costs a day and no engineering. Take your twenty highest-traffic titles, open 4.7.1 through 4.7.5, and mark each title against each clause on paper: does it have UGC, does it need an age flag above the app rating, does it call anything native, does it have a stable URL, does it sell anything. If twenty titles produce more than a handful of unknowns, you have your answer about three hundred — and you have the exact list of questions to send your licensor before anyone opens Xcode.

🌲 Where Forestry Games Fits

Forestry Games licenses HTML5 and Android catalogues and builds white-label portals, so these questions land on us from the buyer's side regularly. If an iOS build is anywhere in your roadmap, ask about the platform grant and per-title metadata during the licensing conversation rather than after it — it is a different conversation before a contract is signed than after.