Luna vs PlayableKit: what each one actually does

Luna is Unity Playworks now — here's what changed

Unity rebranded Luna as Playworks. If you built playable ads under the old name, the workflow you remember is still the same underlying Unity-based tool: you build your playable inside a Unity project, and it exports as a ZIP through the same kind of staged pipeline — on a typical setup, that export lands somewhere like ProjectRoot\LunaTemp\stage4\create-hub, a path that's stuck around across the rename because the underlying build system didn't change, just the label on the box.

So if a colleague, a client brief, or an old internal doc says "Luna," they almost certainly mean what's now called Playworks. Nothing about the export format, the Unity Editor workflow, or the general shape of the tool needs to be relearned — it's the same tool, wearing a different name. The confusion mostly shows up in search results and documentation that hasn't caught up yet, not in the actual software.

What Luna/Playworks actually does (then and now)

Whichever name you know it by, this tool's job is narrow and specific: it builds a working, interactive playable from your Unity scene and hands you back a browser-runnable export. That export plays correctly on its own. What it was never designed to do — under either name — is satisfy the packaging rules of every ad network you might want to run that creative on.

Ad networks each define their own entry-file conventions, click-through APIs, size ceilings, and (for several of them) a hard rule that every asset be embedded inline with zero external network requests at runtime. Luna/Playworks exports a single generic build; it doesn't fork that build to match each network's own rulebook. That was never its job, and the rename didn't change that.

What PlayableKit does — a different layer, not a competing tool

PlayableKit picks up exactly where Luna/Playworks leaves off, and nowhere earlier. You upload the export ZIP that Playworks (or Luna, if you're on an older install) already produced. PlayableKit does not open a Unity project, does not touch your scene, and does not generate gameplay, animation, or UI from scratch — it has no builder in it at all. What it does is take that one finished export and repackage it correctly, per network:

• Click-through wiring — Google expects a clickTag variable plus its ExitApi script; AppLovin and Unity Ads expect MRAID's mraid.open(url); Vungle's primary CTA is window.parent.postMessage('download','*') with MRAID open as fallback; Mintegral expects window.install() falling back to mraid.open(), plus a separate window.gameEnd() callback; TikTok expects window.openAppStore() from its own Playable SDK; Meta expects FbPlayableAd.onCTAClick(). Wire the wrong one into the wrong network and the creative typically gets rejected in review, not silently ignored.
• Asset encoding — AppLovin, Meta, Unity Ads, and Vungle all require a single self-contained HTML file with no external requests permitted at runtime, so every image, sound, and font has to be embedded as inline data rather than loaded by path. PlayableKit handles this encoding automatically instead of it being a manual, error-prone pass over the exported HTML.
• Size limits — every network in this list caps creatives at 5 MB, and Meta, Unity Ads, and Vungle specifically recommend staying closer to 2 MB. A build that clears one network's limit can blow past another's once assets are inlined instead of referenced, which is exactly the kind of thing that's easy to miss until a network's review flags it.
• Package shape — Mintegral wants the archive name, top-level folder, and HTML filename to all match; TikTok wants a first-level index.html plus a config.json declaring Playable_orientation; Google wants an orientation meta tag and a flat ZIP capped at 512 files. None of this is negotiable, and none of it is something Luna/Playworks was ever supposed to produce on its own.

Put simply: Luna/Playworks answers "how do I build this playable," and PlayableKit answers "how do I get this one finished build into shape for every network I'm running it on." Those are sequential questions, not competing answers to the same one.

So is this actually "Luna vs PlayableKit"?

Not really — the "vs" in a search bar is doing more work than the tools actually do against each other. There's no scenario where PlayableKit replaces Luna/Playworks, because PlayableKit has no way to build a playable in the first place; it needs an existing export to work from. And there's no scenario where Luna/Playworks replaces PlayableKit, because per-network packaging was never part of what it exports. If you're deciding between them, you're not really deciding — you'd use Playworks (under whichever name your docs still call it) to build, and then decide whether hand-adapting that one export for every network you ship to is worth automating once you're doing it for three or more networks on a recurring basis.

If that manual per-network pass — clickTag here, MRAID there, re-encoding assets, renaming folders for Mintegral, writing a TikTok config.json by hand — is still a one-off task for you, doing it manually is a perfectly reasonable choice. It starts costing real time once you're repeating it for every new creative variant across several networks, which is the actual gap PlayableKit is built to close.