Side by side, field by field

RequirementAppLovinUnity Ads
File structureSingle self-contained HTML fileSingle self-contained HTML file
Size cap5 MB5 MB
Size recommendationNo stated soft target below the cap5 MB hard cap, 2 MB recommended
Ad interfaceMRAID 2.0MRAID 2.0
External requestsProhibited entirelyProhibited entirely
Click-through APImraid.open(url)mraid.open(url)
MRAID ready-state handlingMust wait for ready before any MRAID call or layout decisionMust wait for ready before any MRAID call or layout decision
OrientationMust render correctly in both portrait and landscapeNo forced-orientation requirement
Auto-play audioProhibited before user interactionProhibited before user interaction
Auto-clickExplicitly prohibited alongside auto-play audioNot separately called out in the spec
Worth being straight about: of the ten fields above, eight are identical. Same MRAID version, same single-file packaging, same 5 MB ceiling, same click API, same external-request ban, same audio rule, same ready-state gating. If a build already passes AppLovin's spec, it is very close to passing Unity Ads' spec too, and vice versa — this is not a case where two "MRAID networks" turn out to secretly have incompatible rendering contracts. They mostly don't.

The differences that actually exist

1. Orientation

AppLovin requires a playable to render correctly in both portrait and landscape — its inventory serves both, and a layout that only makes sense one way has to still be usable in the other. Unity Ads has no equivalent requirement in its spec; there's no forced-orientation rule to satisfy. In practice this means an AppLovin-compliant build that's been orientation-tested is already over-engineered for Unity Ads on this specific point, not under.

2. The size recommendation

Both cap at 5 MB hard. Unity Ads' spec goes further and states a recommended target of 2 MB for consistent load performance across devices — a softer, stated goal beyond the pass/fail line. AppLovin's spec doesn't carry that same explicit recommendation; its rule is the 5 MB ceiling and nothing softer stated beyond it. A build sized for Unity Ads' 2 MB guidance will always clear AppLovin's cap comfortably; the reverse isn't guaranteed.

3. Auto-click, as a named rule

AppLovin's notes explicitly prohibit auto-clicking the CTA in the same breath as auto-playing audio. Unity Ads' stated rule only names audio autoplay. This is a narrow difference — programmatically firing a CTA without a real tap is bad practice everywhere and likely to cause problems on any network — but as a matter of what's literally written into each spec, only AppLovin calls it out by name.

That's the full list. There's no divergence in click API, MRAID version, file shape, or the external-request rule — those four are the ones most likely to actually break a build, and they're identical.

What this means if you're building for both

If you already have a compliant AppLovin build, the only real work to also satisfy Unity Ads is dropping the size target down toward 2 MB if you were riding close to 5 MB, and renaming/re-pointing the output — the orientation and auto-click handling you already did for AppLovin doesn't hurt anything on Unity Ads' side. Going the other direction, from a Unity Ads build to AppLovin, means adding a landscape check you may not have done and confirming nothing auto-fires the CTA — everything else carries over untouched.

How PlayableKit handles both from one source export

Because the two specs are this close, it's tempting to assume one output file could just be reused for both networks. It can't, safely — a build within AppLovin's untested-orientation blind spot, or one sitting at 4.8 MB, will pass AppLovin and get flagged as a soft-fail risk on Unity Ads. PlayableKit doesn't rely on the overlap; it treats each network as its own target from the same source. Upload one Unity Playworks/Luna export once, select both AppLovin and Unity Ads, and PlayableKit generates two separate single-file HTML packages — each with assets embedded as base64/base122, MRAID 2.0 wiring gated behind ready-state, and its own size check against the right threshold (5 MB for AppLovin, 2 MB target for Unity Ads) — rather than shipping one file and hoping the near-identical specs cover both cases completely.

For the individual full specs, common errors, and best practices for each network on its own, see AppLovin Playable Ads and Unity Ads Playable Ads. If you're targeting more than these two from a single export, Multi-Network Playable Export covers the same one-upload-many-outputs approach across the full set of supported networks.