What "it converts files" doesn't tell you

Almost any tool can take a Unity Playworks/Luna export and spit out something with a different filename. That's not the hard part, and it's not where playable-ad tooling actually earns its keep. The hard part is that major ad networks each enforce a different, non-interchangeable set of rules for what counts as a valid submission — and a tool that gets the wrong one silently isn't obviously broken. It opens fine in a browser during your own QA. It just gets rejected, or worse, approved and then the CTA doesn't fire in production.

So the honest question when evaluating any playable-ad tool isn't "does it convert my export." It's whether it gets the four things below right, per network, every time — not just on the network you happened to test against first.

Evaluation criteria: a checklist for any tool

These four checks apply regardless of which product you're looking at. Run them against a real export before you trust any tool's marketing copy, including ours.

1. Per-network click-API correctness

Every network has its own call for registering a tap as a click-through, and none of them are interchangeable. Google expects a clickTag variable plus its own ExitApi script. AppLovin and Unity Ads expect MRAID's mraid.open(url). Vungle's primary path is window.parent.postMessage('download','*') with MRAID open as a fallback. Mintegral expects window.install(), falling back to mraid.open(url), plus a separate window.gameEnd() callback. TikTok expects window.openAppStore() from its own Playable SDK and explicitly prohibits the MRAID pattern. Meta expects FbPlayableAd.onCTAClick() and also prohibits MRAID or a plain window.open. Ask any tool: does it wire the correct call per target, or does it assume one click pattern works everywhere?

2. Asset embedding, not just asset packaging

AppLovin, Meta, Unity Ads, and Vungle all prohibit external requests outright — every image, sound, and font has to be embedded directly in the HTML (data URI or an encoded blob decoded at runtime), with nothing loaded from a relative path or a remote host at render time. Google and Mintegral allow a ZIP of local resources instead of a single file, which is a meaningfully different packaging model. A tool that just zips up your existing folder structure and calls it done will pass on the networks that tolerate that shape and silently fail the ones that don't. Ask: does it actually inline assets for the networks that require it, or does it assume ZIP-with-local-paths is universally fine?

3. Size-limit compliance, measured after encoding

Most networks cap creatives at 5 MB, and Meta and Unity Ads specifically recommend staying closer to 2 MB. The number that matters is the size after assets are embedded — base64 and base122 encoding both add overhead versus the original binary asset size, so a build that measures comfortably under the cap in your source folder can come out over it once it's actually inlined the way a given network requires. Ask: does the tool check size after producing the final artifact per network, or does it check the input and hope the output stays under?

4. Package structure per network's actual rules

Beyond click APIs and embedding, each network has structural requirements that have nothing to do with the creative itself. Mintegral requires the ZIP archive name, the top-level folder name, and the HTML filename inside it to all match — a mismatch is a rejection independent of whether the ad works. TikTok requires a first-level index.html plus a config.json declaring Playable_orientation, and it also prohibits dynamic external asset loading and JS redirects. Google requires an orientation meta tag and caps the ZIP at 512 files. Ask: does the tool generate the exact folder/file shape each network expects, or does it produce one generic ZIP and leave the renaming and config authoring to you?

How to actually check: don't take a vendor's word for any of the four items above. Run a real export through whatever tool you're evaluating and inspect the output file by file — open the HTML, search for the click-call your target network requires, confirm there are no external src= or href= references where the network prohibits them, and check the final file/ZIP size. It takes a few minutes and it's the only way to know for sure.

Where PlayableKit lands on this checklist

PlayableKit takes one Unity Playworks/Luna export ZIP and produces a separately built, per-network package for each target you select, built directly against the rules above rather than a single generic template. Specifically:

CriterionHow PlayableKit handles it
Click-API correctnessApplies the correct call per network automatically — ExitApi/clickTag for Google, mraid.open() for AppLovin/Unity Ads, Mintegral's window.install() + window.gameEnd(), TikTok's openAppStore(), Meta's FbPlayableAd.onCTAClick(), and Vungle's postMessage('download','*') with MRAID fallback.
Asset embeddingAutomatic base64/base122 encoding for the single-file, zero-external-request networks (AppLovin, Meta, Unity Ads, Vungle), and local-resource ZIP packaging where a network allows it (Google, Mintegral).
Size-limit complianceChecks the final built artifact against each network's actual cap (5 MB across the board, with the 2 MB guidance flagged for Meta and Unity Ads) — measured after encoding, not before.
Package structureGenerates Mintegral's matching archive/folder/HTML naming automatically, writes TikTok's config.json with orientation, and adds Google's orientation meta tag and 512-file ZIP limit — no manual renaming or hand-written config.
Verify before you submitThe free Playable Ad Validator runs a compliance pass on any export — including ones not built with PlayableKit — with no signup required.

None of this replaces Unity Playworks/Luna — you still build the playable itself in Unity. PlayableKit's job starts after that export exists: turning one build into the correctly-shaped, correctly-wired package for each network you're actually shipping to. If you're weighing whether that's worth adopting versus continuing to adapt exports by hand, this breakdown of the manual work involved covers that trade-off in more detail.

Pricing, if that's the deciding factor

PlayableKit is priced by network breadth rather than by seat count or build volume alone: Starter is $400/mo covering four networks (Google, Meta, AppLovin, Unity Ads), Studio is $560/mo with broader network access, and Scale is $800/mo for teams running full multi-network campaigns at capacity. Enterprise is custom for organizations that need dedicated infrastructure or support beyond that. Full details are on the pricing page.

The one-sentence version

Don't evaluate playable-ad software by whether it produces a file — evaluate it by whether the file it produces is wired, embedded, sized, and packaged the way the specific network you're submitting to actually requires. Check that on any tool you're considering, PlayableKit included, before you commit a real campaign to it.