Side by side, field by field
| Requirement | Mintegral | AppLovin |
|---|---|---|
| Package format | ZIP archive | Single self-contained HTML file — no ZIP |
| Entry file path | mintegral/mintegral.html, exactly | applovin.html, and it is the whole package |
| Naming rule | Archive name, top-level folder, and HTML filename must all match | No naming-match rule — there's no folder or archive to match against |
| Asset packaging | Images/audio can ship as ordinary separate files inside the ZIP | Every asset must be inlined as base64/base122 inside the one file |
| File count | No stated file-count cap beyond the size limit | Exactly 1 file — no companions of any kind |
| Size cap | 5 MB for the whole package | 5 MB for the whole file |
| External requests | Not prohibited by spec — separate in-ZIP assets are the norm | Prohibited entirely — zero external JS/CSS/images/fonts/network calls |
| Ad interface | Its own SDK context; no stated MRAID version requirement | MRAID 2.0, explicitly |
| Click-through API | window.install(), with an mraid.open(url) fallback | mraid.open(url) — nothing else, no fallback needed |
| Completion callback | window.gameEnd() required at end of play — reviewed and tested by Mintegral | No equivalent callback in the spec at all |
| Orientation | No forced-orientation requirement stated | Must render correctly in both portrait and landscape |
| Auto-play / auto-click audio | Not separately named in the spec | Explicitly prohibited before user interaction |
| MRAID ready-state gating | Not applicable to its primary click path | Must wait for MRAID ready before any API call or layout decision |
Why they diverge this much
Mintegral treats a playable like the rest of its interactive inventory: a ZIP with an SDK layer underneath expecting specific calls (window.install(), window.gameEnd()) at the right moments, plus a naming convention its ingestion pipeline parses mechanically. AppLovin, running through MAX and AppDiscovery's shared MRAID surface, wants zero ambiguity about what gets loaded — everything collapses into one file, nothing external, nothing to unzip. Neither is more "correct"; they're built for different review pipelines, and that makes their failure modes different too. A Mintegral submission fails on structure — wrong folder name, missing gameEnd() — even when it renders perfectly. An AppLovin submission fails on isolation — a relative-path reference, an early MRAID call — even when the creative's logic is fine.
What this means in practice: rework, not a re-label
Other network-pair comparisons on this site (AppLovin vs Unity Ads, for instance) land on near-identical specs, which makes it tempting to assume any two-network comparison ends the same way — swap a filename, ship both. That assumption breaks completely here.
Going from a Mintegral-ready build to AppLovin means: discarding the ZIP/folder structure, inlining every previously-separate asset as base64/base122 into one HTML file, replacing the window.install()/mraid.open() pair with a single ready-gated mraid.open(url) call, dropping window.gameEnd() entirely, and adding a landscape check Mintegral never required. None of that is a rename.
Going the other direction — AppLovin to Mintegral — means rebuilding a ZIP whose archive name, top-level folder, and HTML filename all agree, moving the entry to the exact path mintegral/mintegral.html, adding a window.gameEnd() call the AppLovin build never needed, and making window.install() the primary click handler with mraid.open() only as fallback. "Two builds for MRAID-flavored networks" isn't the same claim as "two builds for these two networks" — Mintegral isn't MRAID-first the way AppLovin is.
How PlayableKit handles both from one source export
Because the specs genuinely don't overlap, PlayableKit builds each package from scratch against its own spec, from the same source. Upload a Unity Playworks/Luna export once and select both: for Mintegral it assembles a ZIP with archive, folder, and HTML name matching, entry at mintegral/mintegral.html, window.install() wired with the mraid.open(url) fallback, and window.gameEnd() inserted at the right point. For AppLovin, from that same source, it produces a single applovin.html with every asset embedded as base64/base122, a ready-gated mraid.open(url) handler, and a check against both orientations — no external references anywhere. Both come from one upload; neither is a copy of the other with a file extension changed.