Two tools solving two different problems
Playworks/Luna is Unity's own in-engine tool. You build a scene, wire up gameplay logic, and Playworks/Luna compiles that scene down into a browser-runnable export — HTML, JS, and embedded assets that behave like the game you built, minus a Unity runtime. That export is the deliverable of the build step. It runs. It looks right. It plays correctly in a browser.
What it isn't is a finished ad. Every network you submit to — Google Ads, Meta, AppLovin, Mintegral, TikTok, Unity Ads, Vungle — has its own click-through API, its own file-size ceiling, its own rules about external requests, and its own required package shape. Playworks/Luna has no reason to know any of that; it's an export tool for one Unity scene, not a compliance tool for seven ad networks with conflicting rulebooks. That's a separate job, and it's the one PlayableKit does: take the Playworks/Luna export ZIP as input and produce one correctly wired, correctly sized, correctly shaped package per network.
Side-by-side: who's responsible for what
| Responsibility | Unity Playworks/Luna | PlayableKit |
|---|---|---|
| Build the playable from a Unity scene | Yes — this is its entire job | No — needs an existing export as input |
| Export a browser-runnable ZIP | Yes (e.g. LunaTemp\stage4\create-hub) | No — consumes that export |
| Wire clickTag / MRAID / SDK per network | No — ships one generic build | Yes, per network's actual click API |
| Inline all assets as base64/base122 for zero-external-request networks | No | Yes, where the network requires it |
| Enforce each network's size ceiling (5 MB, or 2 MB recommended) | No | Yes, per network before submission |
| Validate package shape (folder/HTML naming, config.json, orientation meta) | No | Yes, per network's spec |
| Produce a separate package per ad network from one source build | No — one export, one shape | Yes — up to 7 network-specific packages |
Where Playworks/Luna' job actually ends
A Playworks/Luna export is a single build tuned for nothing in particular. It doesn't know whether you're about to submit it to Google Ads or Vungle, and it shouldn't have to — that's not a limitation, it's scope. The export is engine-agnostic to the ad network layer by design, which is exactly why the same export can feed every network's packaging step rather than needing a different Unity build per network.
That also means Playworks/Luna can't be blamed for a creative getting rejected by AppLovin or Meta for containing an external font reference, or by Google for exceeding 512 files, or by Mintegral for a mismatched archive/folder/HTML name. Those are packaging-stage failures, not build-stage failures — they happen after Playworks/Luna has already done its job correctly.
Where PlayableKit's job starts
PlayableKit opens the Playworks/Luna export ZIP and, per selected network, applies the wiring and structure that network's review process checks for: Google's clickTag plus its ExitApi script and an orientation meta tag inside a flat ZIP capped at 512 files; AppLovin's single self-contained HTML file with MRAID 2.0 and zero external requests; Meta's single-file HTML calling FbPlayableAd.onCTAClick(), 5 MB max (2 MB recommended); Mintegral's window.install() plus window.gameEnd() with matching archive/folder/HTML names; TikTok's first-level index.html, a config.json declaring orientation, its own Playable SDK, and window.openAppStore(); Unity Ads' single-file MRAID 2.0 build; and Vungle's single-file build calling window.parent.postMessage('download','*') with MRAID open as fallback. None of that exists in a raw Playworks/Luna export — it's generated at the packaging step, per network, every time.
PlayableKit cannot build a playable from nothing. It has no scene editor, no gameplay logic, no way to originate a creative — it only transforms an existing Playworks/Luna export. If you don't have that export yet, PlayableKit has nothing to work on. That's the honest boundary, and it's the reason this isn't really a "vs."
Pricing isn't actually comparable — and that's worth saying plainly
Unity doesn't sell Playworks/Luna as a standalone product with its own price tag. It's bundled into your Unity Editor subscription tier, so what it costs you depends on which Unity plan you're already on — for current tier details and pricing, that's a question for unity.com, not something we can quote here without guessing.
PlayableKit's pricing is a flat monthly fee for packaging, independent of whatever you pay Unity: Starter at $400/mo (Google Ads, Meta, AppLovin, and Unity Ads, 50 builds), Studio at $560/mo (every network, 100 builds), Scale at $800/mo (every network, 300 builds, 2 seats), and custom Enterprise pricing for larger volume or infrastructure needs. See the full breakdown on the pricing page.
Because these solve different problems, the honest way to think about total cost is additive, not either/or: whatever Unity tier gets you Playworks/Luna, plus whichever PlayableKit plan matches how many networks you're shipping to and how many builds you run a month.
When this distinction actually matters
If you're only building for one network and shipping infrequently, the Playworks/Luna export alone might get you most of the way there with a bit of manual clickTag wiring — the packaging gap is small enough to close by hand. The distinction starts to matter once you're maintaining the same creative across three or more networks, or shipping new variants often enough that re-doing per-network wiring, encoding, and shape fixes by hand becomes the actual bottleneck. At that point you're not choosing between Playworks/Luna and PlayableKit — you're deciding whether to keep doing PlayableKit's job manually or hand it off.