The problem: one playable, seven incompatible specs
A studio running UA campaigns rarely ships to just one network. But a Playworks/Luna export that plays perfectly in a browser doesn't automatically satisfy any network's actual submission requirements — and those requirements don't agree with each other. Google wants a ZIP with an orientation meta tag; AppLovin wants a single self-contained HTML file with nothing external at all. Meta expects a specific CTA callback; TikTok expects a different SDK entirely.
Without tooling, "supporting multiple networks" means manually re-wiring the same creative once per target: renaming files, inlining assets by hand, swapping click-through code, and re-testing each variant before submission. Do that for one campaign and it's tedious. Do it every time a creative changes, across five or six networks, and it becomes the actual bottleneck in the release cycle — not the creative work itself.
How PlayableKit's multi-network export actually works
PlayableKit's converter is built around a single conversion pass, not a series of separate jobs. When a build runs, the source ZIP is extracted once into a working directory, then the converter loops over every network selected for that job and runs each network's dedicated packaging function against that same extracted source — Google's ZIP builder, AppLovin's single-file inliner, Mintegral's folder-matching packager, and so on. Each network either succeeds or fails independently (a bad TikTok config doesn't take down the Google output), and every result — pass/fail, file size, entry file, spec notes — lands in one combined conversion-report.json written at the end of that same run.
Practically, that means uploading a Playworks/Luna export once, choosing the networks you're shipping to, and getting back a separately packaged, network-compliant creative for each one — from a single upload, a single job, and a single report to review before you submit anywhere.
The real per-network differences it's reconciling
"Multi-network export" isn't just repackaging the same file seven times with different names. The underlying specs genuinely conflict, and PlayableKit's per-network converters exist specifically to reconcile these differences:
| Difference | How it actually varies |
|---|---|
| Output shape | Google, Mintegral, and TikTok expect a ZIP archive; AppLovin, Meta, Unity Ads, and Vungle require a single self-contained HTML file with every asset embedded — no separate files at all. |
| Click-through API | Google uses ExitApi.exit(); AppLovin and Unity Ads use MRAID's mraid.open(url); Mintegral uses window.install() with an MRAID fallback; TikTok uses its own window.openAppStore() from a required Playable SDK; Meta uses FbPlayableAd.onCTAClick(); Vungle uses window.parent.postMessage('download','*') with MRAID as fallback. None of these are interchangeable — the wrong call is a common cause of outright rejection. |
| Size ceiling | Every network caps creatives at 5 MB, but Meta and Unity Ads specifically recommend staying near 2 MB, and Google additionally caps a ZIP at 512 files. |
| Package/file naming | Mintegral requires the archive name, top-level folder, and HTML filename to all match; TikTok requires a first-level index.html plus a config.json declaring orientation; AppLovin, Meta, Unity, and Vungle each expect their own fixed entry filename (applovin.html, meta.html, unity.html, vungle.html). |
Every one of those rules is applied automatically, per network, from the same source export — asset encoding for the single-file networks, ZIP structure and orientation metadata for the archive-based ones, and the correct click-through call wired in for whichever network the output is destined for.
Which plans include which networks
Multi-network export is real, but it isn't unlimited on every plan — network access is gated by plan tier. Be aware of this before assuming full seven-network export is included by default:
| Plan | Networks included |
|---|---|
| Starter | Google Ads, Meta, AppLovin, Unity Ads (4 of 7) |
| Studio | All networks — adds Mintegral, TikTok, and Vungle ✓ |
| Scale | All networks — adds Mintegral, TikTok, and Vungle ✓ |
| Enterprise | All networks, custom terms ✓ |
In other words: Starter covers the four networks most small teams ship to first — Google Ads, Meta, AppLovin, and Unity Ads. If a campaign needs Mintegral, TikTok, or Vungle in the same run, that requires Studio, Scale, or Enterprise. A build request for a network outside the org's plan is rejected before conversion runs, so it's worth confirming your target network list against your plan up front rather than after an upload.
Is this worth it over doing it by hand?
If a team ships to a single network, the manual rework each time is a fixed, tolerable cost. It stops being tolerable once a creative needs to go out to several networks on the same day, or gets iterated often enough that redoing per-network packaging by hand becomes the actual release bottleneck. That's the specific case multi-network export is built for: one source build, uploaded once, producing every network-compliant package your plan allows in a single run.