Liftoff and Vungle are the same integration
Liftoff acquired Vungle in 2021, and Vungle's mobile ad network became the "Liftoff Monetize" product line. The creative-spec side of that business — the HTML5 playable format, the size caps, the click-through mechanism — carried over from Vungle rather than being rebuilt from scratch under the new brand. That's why PlayableKit labels this network option Vungle (Liftoff) in its network picker and API: it's one integration with two names attached to it depending on which part of the corporate history you're searching for. If you build a Playworks/Luna export to spec for "Vungle," it's the same output a Liftoff Monetize placement expects.
So the useful question isn't "does PlayableKit support Liftoff" — it's "what does the Vungle/Liftoff spec actually require," which is what the rest of this page answers.
The real Vungle (Liftoff) playable requirements
These are the actual rules PlayableKit's Vungle network target builds against, pulled straight from its network spec rather than paraphrased:
- Single self-contained HTML file. Output type is HTML, not a ZIP — one file, no companion assets sitting alongside it. PlayableKit's internal entry file for this target is named
vungle.html. - 5 MB maximum. The whole file — markup, script, and every embedded asset — has to fit under 5 MB.
- All assets embedded, zero external requests. Images, audio, fonts, and any library code must be inlined into that one file as data URIs or encoded blobs decoded at runtime. External network calls of any kind — a hosted image, a CDN script, an analytics ping — are prohibited outright, not just discouraged.
- CTA fires
window.parent.postMessage('download','*'). That's the primary click-through call for the Vungle/Liftoff container. MRAID'smraid.open(url)is the fallback for environments that expect the MRAID pathway instead. - No audio before user interaction. Sound can't autoplay; it has to wait for a tap or click.
None of this is unusually strict compared to the other networks PlayableKit builds for — AppLovin, Meta, and Unity Ads all require the same single-file, fully-embedded approach — but the CTA call is specific to Vungle/Liftoff. Wiring the wrong click-through API (say, an MRAID-only call with no postMessage fallback, or vice versa) is a common reason a creative that plays fine in a browser still gets bounced in review.
Why a raw Playworks/Luna export doesn't meet this out of the box
Playworks/Luna builds a working playable and exports it as a ZIP (typically under ProjectRoot\LunaTemp\stage4\create-hub). That export runs correctly when you open it in a browser, but it isn't packaged against any specific network's rules — Vungle/Liftoff included. Concretely, getting there from a fresh Playworks/Luna export means:
- Collapsing to one file. Playworks/Luna typically exports an HTML file alongside separate asset folders (images, audio, sometimes a JS bundle). Vungle/Liftoff wants all of that merged into a single HTML document.
- Encoding every asset. Each image, sound, and font referenced by a relative path has to become a base64 (or similarly encoded) data URI embedded directly in that file — the same asset-embedding work AppLovin and Meta require, done again for this target.
- Wiring the CTA. Whatever click-handling code Playworks/Luna generated by default needs to be replaced with a call to
window.parent.postMessage('download','*'), with anmraid.open()fallback wired in for good measure. - Checking the size budget after embedding. Base64 encoding inflates asset size by roughly a third. A build that was comfortably under 5 MB as separate files can land right at — or over — the cap once everything is inlined into one document.
This is exactly the same category of work covered in more general terms on our Unity Playworks/Luna alternative page — Vungle/Liftoff isn't a special case, it's one more network with its own specific CTA call and entry-file convention layered on the same underlying asset-embedding job.
Where PlayableKit fits
PlayableKit supports this today — it's not a roadmap item. Select Vungle (Liftoff) as a build target, upload your Playworks/Luna export ZIP, and PlayableKit produces a vungle.html output with every asset embedded, the CTA wired to postMessage('download','*') with MRAID fallback, and the file checked against the 5 MB cap — alongside whatever other networks (Google Ads, Meta, AppLovin, Mintegral, TikTok, Unity Ads) you're building the same source export for.
One thing worth knowing before you rely on it: Vungle/Liftoff builds are available on the Studio plan and above — the entry-level Starter plan is scoped to Google, Meta, AppLovin, and Unity Ads only. Check current plan details and network coverage on the pricing page before you plan a Vungle/Liftoff release around it.
| Step | Manual process | With PlayableKit |
|---|---|---|
| Merge to single HTML file | Hand-inline every asset folder into one document | Handled automatically for the Vungle/Liftoff target |
| CTA wiring | Replace default click code with postMessage + MRAID fallback | Applied automatically to spec |
| Size budget after encoding | Re-check manually once assets are inlined | Free size checker shows real post-encoding size |
| Structural sanity check | Upload and wait for network review to find out | Free validator flags issues before you submit |
Is this worth automating for one network?
If Vungle/Liftoff is the only network you ship to, doing this by hand once per creative is a manageable, if tedious, chore. It stops being manageable the moment you're maintaining the same creative across Vungle/Liftoff plus two or three other networks and re-doing the merge-and-rewire work by hand every time you ship a variant — which is the case this page, and PlayableKit generally, is built for.