What a playable ad converter has to do
A Playworks/Luna export is a real, playable build — it runs correctly the moment you open it in a browser. The problem is that "runs in a browser" and "accepted by Google Ads" (or Meta, or TikTok) are different bars. Each network defines its own packaging contract, and a converter's job is to satisfy all of them from the same source build without you re-authoring the creative seven times.
Three parts of that contract change on every network:
- Click-through wiring. Google expects a
clickTagvariable and its own ExitApi script; AppLovin and Unity Ads expect MRAID'smraid.open(url); Vungle's primary CTA iswindow.parent.postMessage('download','*')with MRAID open as a fallback; Mintegral expectswindow.install(); TikTok expectswindow.openAppStore()from its own Playable SDK; Meta expectsFbPlayableAd.onCTAClick(). Wire the wrong one in and the creative doesn't error — it just gets rejected in review, often with a vague reason. - Asset packaging. AppLovin, Meta, Unity Ads, TikTok, and Vungle all prohibit external requests outright — every image, audio clip, and font has to be embedded as inline data rather than loaded by path. Google and Mintegral allow a folder of resources inside a ZIP instead. Get this backwards and a build that renders fine locally shows a blank white frame in a network's ad viewer.
- Package shape and size. Every network here caps creatives at 5 MB, and Meta and Unity Ads specifically recommend staying near 2 MB. AppLovin, Meta, Unity Ads, and Vungle each want exactly one HTML file. Google wants a flat ZIP capped at 512 files with an orientation meta tag. Mintegral wants the ZIP name, top-level folder, and HTML filename to match. TikTok wants a first-level
index.htmlalongside aconfig.jsondeclaring orientation.
None of this is exotic — it's just a different set of rules per network layered on top of one creative. Handling it by hand for a single network per build is manageable. Handling it correctly every time you ship a variant, across every network you actually advertise on, is where manual conversion starts producing rejected creatives, missed launch windows, and a growing pile of hand-edited HTML files that nobody wants to touch again.
What PlayableKit's converter does end-to-end
PlayableKit's core product is a conversion engine, not another editor for building playables — you still build the creative in Unity with Playworks/Luna exactly as you do today. You upload that one export ZIP once, pick the networks you're targeting, and the engine does the rest: it reads the build, applies each selected network's click-through API, encodes assets the way that network requires (embedded data URIs for the single-file networks, a resource folder for the ZIP-based ones), enforces that network's size cap and file-count limit, and writes the output in the exact package shape that network's upload form expects — right down to matching filenames for Mintegral and a generated config.json for TikTok.
The output is one properly named, independently compliant package per network, generated from the same source build in a single run — not seven manual edits of the same HTML file.
| Network | Package | Click-through API | Size cap | What makes it different |
|---|---|---|---|---|
| Google Ads | ZIP, ≤512 files | ExitApi.exit() | 5 MB | Orientation meta tag; only Google-hosted libraries allowed externally |
| Meta (Facebook) | Single HTML | FbPlayableAd.onCTAClick() | 5 MB (2 MB recommended) | Fully self-contained; no external requests, no auto-redirect |
| AppLovin | Single HTML | mraid.open(url) | 5 MB | MRAID 2.0; must support both orientations |
| Unity Ads | Single HTML | mraid.open(url) | 5 MB (2 MB recommended) | MRAID 2.0; must wait for MRAID ready before API calls |
| Vungle (Liftoff) | Single HTML | postMessage('download'), MRAID fallback | 5 MB | Fully self-contained, no external requests |
| Mintegral | ZIP | window.install() / MRAID fallback | 5 MB | Archive name, top folder, and HTML filename must match; window.gameEnd() callback |
| TikTok | ZIP | window.openAppStore() | 5 MB | Requires TikTok's Playable SDK plus a config.json declaring orientation |
Real pricing
PlayableKit is priced per workspace, based on how many builds you run per month — every paid plan includes every supported network:
| Plan | Price | Builds / month | Seats | Network access |
|---|---|---|---|---|
| Starter | $129/mo | 15 | 1 | All networks |
| Studio | $319/mo | 50 | 1 | All networks |
| Scale (most popular) | $499/mo | 100 | 1 | All networks |
| Enterprise | Custom | Custom | Custom | All networks + dedicated support |
Every paid plan, including Starter, unlocks every network the converter supports — Mintegral, TikTok, and Vungle included. What scales with the plan is your monthly build ceiling, for teams shipping creative variants continuously. There's also a free workspace tier for exploring the dashboard before committing to builds.
Who this is for
If you're only ever submitting to one network, hand-editing a single HTML file per creative is a one-time cost you can absorb. The converter earns its keep the moment you're maintaining the same creative across three or more networks, or shipping enough new variants that redoing per-network wiring, encoding, and packaging by hand becomes the actual bottleneck between "build finished in Unity" and "creative live in the ad account."