A Mini-Game Platform Cannot Run Your iframe. Settle Adaptation Rights Before You License HTML5 Games.

Before you license HTML5 games for WeChat, Douyin or YouTube Playables, settle adaptation rights — none of those platforms will run the iframe a licensor ships.

This comes up in almost every catalogue conversation involving Asia, and it comes up backwards. Somebody reads a number about China's mini-game market, decides mini games are "just HTML5", and assumes a licensed catalogue can be pointed at WeChat the way it gets pointed at a portal. It cannot. A mini game is a different runtime with a different package format, a different regulatory gate, and — this is the part that lands in your contract, not your backlog — a requirement that somebody edits the inside of the build. If your licence gives you a hosted URL and an embed snippet, you own none of the things that job needs.

📈 The Number That Starts This Conversation

The pull is real, and worth stating with figures rather than adjectives. According to the China WeChat Mini Games Industry Report 2026, published by Meridian Play and JINKE in July 2026 and drawing on the 2025 China Game Industry Report, DataEye, QuestMobile and MoonFox data, China's mini-games market generated RMB 53.535 billion in 2025 — a 34.39% year-on-year increase — and is projected to pass RMB 70 billion in 2026.

The composition matters more than the total. In-app purchases accounted for RMB 36.464 billion, or 68.11%; advertising made up the remaining RMB 17.071 billion, or 31.89% — close to the inverse of how most licensed casual catalogues earn. The same report puts WeChat's mini-game penetration at 51.5% against Douyin's 18.4%.

A large market, growing fast, monetising primarily through purchases inside games rather than ads around them. Hold that last fact — it quietly decides whether any of what follows is worth doing with a licensed arcade catalogue at all.

🚫 A Mini Game Is Not a Web Page

This is the technical fact that ends most of these projects, and it is stated plainly in Tencent's own documentation rather than inferred from forum posts. The Weixin Adapter documentation says of the mini-game environment: "There are no running environments for BOM and DOM, and there are no global document and window objects." The consequence it spells out: "when you want to use the DOM API to create elements like Canvas and Image, it will incur an error."

Read that against what a licensed HTML5 title actually is. An index.html. A DOM canvas the engine grabs by ID. Image and Audio elements. CSS for the loading screen and the orientation prompt. A resize handler bound to window. In a mini game, none of those exist.

There is a bridge, and there is a catch. WeChat published weapp-adapter, a shim that fakes enough browser surface for engine code to stop throwing. The same official page now states that "the weapp-adapter will not be updated and maintained officially any longer" and that "developers should implement their own Adapter based on their own game engine." It also clarifies that the adapter is not part of the mini-game base library. So the compatibility layer everyone points at as the easy answer is an unmaintained reference implementation you are expected to fork.

In practice, engines carry this themselves. Cocos Creator, LayaAir, Egret and Unity all ship WeChat export targets, and those work well when you have the project — scenes, assets, engine version. A build compiled for the web and handed to you as files is not a project, and no export target will accept it.

📦 Four Megabytes Is the Number Everyone Agrees On

The second wall is size, and here the published sources genuinely disagree, so take the range rather than one figure.

• Main package: 4 MB. Every source I checked agrees. Weixin's own subpackage documentation, Cocos Creator's 3.0, 3.7 and 3.8 manuals, and LayaAir's guide all state a 4 MB ceiling on the main package.
• Total subpackages: 8 MB, 20 MB or 30 MB depending on who you read. The Weixin English subpackage page states 8 MB; Cocos Creator's 3.0-era manual says 20 MB; Cocos Creator 3.8 says 30 MB. The limit has risen over time and the English docs lag. Verify the current number in the developer console for your account rather than trusting any manual, including this post.

The 4 MB main package is the constraint that bites, because it is the number nobody disputes and it covers code plus everything loaded at startup. Weixin's guidance is to keep scripts in the package and pull assets remotely — with the hard restriction that you cannot download script files from a remote server. Your logic ships in the package. Your art does not.

A licensed casual title of 8–15 MB is not a mini game that is slightly too big. It needs its asset pipeline rebuilt: atlases re-cut, audio re-encoded, a remote CDN loader wired in, subpackage boundaries drawn by hand. That is engineering work inside the build, per title, and it recurs whenever the licensor ships an update.

🧾 The Approval Number Is a Different Company's Problem

Suppose you solve the runtime and the size. There is still a licence above your licence. Mainland China gates commercial online games behind a publication approval number — the banhao — issued by the National Press and Publication Administration. Per a 2026 regulatory summary by Magist, the approval is required before a game can charge users, run in-app purchases, display monetised advertising or accept virtual-currency payments, and a foreign developer cannot apply for one directly: applications are filed by a domestic entity holding an Online Publishing Service Licence. The same summary puts typical import-title timelines at six to eight months or longer, with import approvals issued in discrete batches roughly every two months.

Douyin works the same way from a different direction. AppInChina's developer guide states that Douyin's supported operating entities are "primarily legally registered operators in Mainland China", and that a game ISBN is required before a developer can activate virtual payments — with an alternative filing route for ad-funded titles without in-app purchases.

So you are not buying a distribution channel. You are buying a relationship with a Chinese publisher who holds the approval, files the title, and sits between you and the platform — and who will want rights you may not hold, on titles you licensed from someone else, in a territory your agreement probably does not name.

🌐 Even the Web-Native Destination Wants Code Changes

It would be convenient if the non-China equivalents were plug-and-play. They are closer, and still not that. YouTube Playables is the clearest case, because it genuinely is a web runtime — real HTML5, real browser APIs. YouTube's own May 2024 announcement on the YouTube Blog launched it with "more than 75 games" playable directly in the app and on desktop. But Google's Playables SDK getting-started guide requires that the SDK script be loaded before any of your game code — its words: "The SDK MUST be loaded before any of your game code" — and that the title call ytgame.game.firstFrameReady() and ytgame.game.gameReady(), with ytgame.game.loadData() and others for save state.

Those are small changes. They are still changes to the first bytes of the HTML document and to the game's boot sequence, and you cannot make them from outside an iframe or on a build you may embed but not modify. Access is gated too: Google runs an onboarding and review process rather than open self-service submission.

The generalisable rule: every mini-game and instant-play destination requires an edit inside the build. The cheap ones want a script tag and two function calls. The expensive one wants a different runtime, a different package format and a Chinese publisher.

🔑 The Four Rights That Decide Whether Any of This Is Possible

Here the topic stops being technical and becomes a licensing question. Four things in your agreement determine whether a mini-game port is available to you at all, and none are standard in a portal licence.

1. Source or project access, not builds. An embed URL is unusable and a compiled web bundle close to it. A port needs the engine project. If mini games are in your future, the licence conversation is about game source code access from the start, not a later amendment.
2. The right to make derivative works. Most licences grant distribution and display. Re-packaging a title for a different runtime is adaptation, and adaptation is a separate grant. Silence here is not permission.
3. Territory that names mainland China explicitly. China is the most commonly carved-out territory in casual game licensing. Check whether it is included, excluded, or simply unaddressed — the third is the most dangerous, because it feels like a yes.
4. Ownership of the ported build, and the right to sublicense it. You pay for the adaptation — who owns the result, and can you pass it to a Chinese publisher who must operate it under their approval? A no-sublicensing clause ends the project after you have paid for the port.

🧮 When This Is Worth Doing, and When It Plainly Is Not

I would talk most operators out of this, and the honest version is more useful than a pitch.

Do not do it if you are a portal operator with an ad-funded arcade catalogue and no Chinese entity. The market monetises 68% through IAP; your catalogue earns from ads you will not be permitted to serve without an approval you cannot hold. Porting 200 titles to clear that gate is a large bill against a revenue model the market does not reward.

Do not do it if the goal is one title in one campaign. If a brand wants a mini game on WeChat for a Chinese push, the right answer is usually to commission a native mini game from a Chinese studio that already holds the toolchain and the publisher relationship — faster and cheaper than adapting a licensed title. A licensor who tells you otherwise is selling.

It can be worth doing in a narrow band: you already operate in China through an entity or publisher, you have identified a handful of titles with proven retention in a comparable market, and you can get the engine projects. Five to ten titles, ported properly, with the IAP economics designed for the platform rather than inherited from your web portal. That is a product decision, not a catalogue decision.

Playables and comparable web-native destinations are a different calculation — hours of integration per title and no regulatory gate. There, the binding constraint really is just whether your licence lets you touch the file.

🚫 Five Ways This Goes Wrong

• Budgeting a port as a conversion. Teams price this as a build step. It is a per-title engineering project with an asset-pipeline rebuild inside it, and it repeats on every licensor update.
• Signing the catalogue first and asking about source later. Source access changes the price and sometimes the availability of a title. Ask before the deal closes, not after the roadmap promises China.
• Treating "HTML5" as one compatibility class. A telecom portal, a Playables submission and a WeChat mini game make three incompatible demands of the same file. A title that passes one can fail the others.
• Assuming the ad revenue transfers. Your web mediation stack does not exist inside a mini game. Platform ad units, platform rules, platform reporting — and only once you are cleared to monetise.
• Letting an unmaintained shim be the plan. weapp-adapter is a starting point that Tencent has said it will not maintain. If the proposal in front of you says "we'll use the adapter", ask who owns it after the first engine upgrade.

📋 Questions to Put to a Licensor Before You Sign

1. For these specific titles, can we get the engine project, or only builds? Which engine and which version?
2. Does the licence grant adaptation and derivative-work rights, in writing, distinct from distribution?
3. Is mainland China inside the territory, outside it, or unaddressed?
4. Can we sublicense an adapted build to a local operating partner?
5. Who owns a port we pay to create, and what happens to it at the end of the term?
6. When you update a title, do we receive the updated project or only the updated build?
7. Are any of these titles already licensed to a Chinese operator in a way that conflicts with ours?
8. For web-native destinations, are we permitted to insert a platform SDK into the build ourselves?

🎯 What You Get When You License HTML5 Games From a Direct Licensor

The reason this post keeps returning to the contract is that everything above is decided there. Forestry Games licenses HTML5 and Android titles directly and has been doing it since 2017, across a catalogue of 1,049 games, so the scope conversation happens with the party that can actually answer it rather than through a reseller relaying questions.

A licence scope is built around the use case: HTML5 builds for web and portal delivery, APK builds where Android distribution is the target, source where the arrangement supports it, branding and white-label options, and hosted or self-hosted delivery. Where a plan involves adaptation — a different runtime, a platform SDK, a rebuilt asset pipeline — that belongs in the scope discussion from the start, because it changes what you receive, not just what you pay. If you are sizing a catalogue, browse the HTML5 games catalogue and pick the titles the plan depends on before asking for terms across all 1,049.

🧸 Licensing Branded Games for Portals, Campaigns and Apps

Forestry Games also works with branded IP and has brand partnerships including Disney, Nickelodeon, Cartoon Network and Warner Bros, so businesses can license branded game content through it for campaigns, portals, events and apps alongside a generic catalogue.

Branded titles carry a second layer of approval above the ordinary licence, and that is where the questions in this post get sharper: a rights holder has a view on what may be modified, where a title may appear, and which territories are in scope. Settle those before an adaptation plan, not during one. The next step is to browse the catalogue, mark the titles a specific destination depends on, and ask for a licence scope written against that destination — or request a white-label portal demo if the need is a running storefront rather than a port.

✅ Ask the Runtime Question at the Next Renewal

The mistake here is not choosing wrong about China. It is discovering, eighteen months into a term, that a distribution option you assumed you had was never in the grant. The fix costs nothing today: take your current agreement and find the sentence saying whether you may modify a build. If there isn't one, you have a portal licence, and portals are all it can do.

Then decide honestly whether mini games belong in your plan at all. For most operators reading this they do not, and knowing that is worth more than a port. For the few where they do, the sequence is fixed: confirm the entity and publisher route first, pick five titles rather than five hundred, and secure the project files and adaptation rights before a single line of engineering is scheduled. Either way, put the adaptation clause in the next agreement you sign. It costs nothing to have and everything to want later.