Why a stock Unity WebGL build fails as a playable ad

Many teams' first playable is a stock Unity WebGL build with a store link on the end. It almost always fails network review. Here is why, and what a playable-specific engine does differently.

A WebGL build carries the whole engine

Unity's WebGL export ships the engine runtime compiled to WebAssembly: physics, animation, UI, audio, networking, input, whether or not the game uses them. Even an empty scene lands at several megabytes before any of your assets are added. Playable networks cap you at 5 MB and expect a first frame in under two seconds, so the engine alone has spent the budget.

It expects a server

A WebGL build loads its .wasm, .data and framework files from separate URLs. Playable networks forbid external requests and most want a single self-contained HTML file. Getting a WebGL build into one file means base64-inlining tens of megabytes, which makes the size problem worse.

It does not speak the network's API

Each network expects the ad to call its own hooks: ironSource's dapi, Mintegral's gameReady(), Meta's FbPlayableAd.onCTAClick(). A stock build knows none of them, and it will start playing before the ad is visible, which reviewers reject immediately.

What a playable engine does instead

• Compiles only the subsystems the playable touches; a match-3 with no physics ships no physics.
• Strips assets not referenced by the tagged scene and re-encodes what is left per network.
• Injects the correct network callbacks at export time, so one project produces a valid build for each network.
• Produces a single inlined HTML file or a zip, depending on what the network wants.

That is the whole reason PlayableForge exists. Same Unity project, same C#, but a runtime built for a 5 MB budget rather than a 500 MB one.