mraid.open() call. Everything below reflects InMobi's actual published spec.
What kind of network InMobi is
InMobi operates its own demand-side platform and exchange, serving mobile ad inventory across a large publisher network rather than acting as a single walled-garden app (the way Meta or TikTok do). For playable ads specifically, InMobi's DSP documents its requirements in a dedicated creative specifications and guidelines section, separate from its standard banner and video specs. That distinction matters: a playable submitted to InMobi is evaluated against MRAID-based interactive-creative rules, not the static image or video checks that cover the rest of InMobi's format catalog.
InMobi's playable ad specification
The technical requirements below come directly from InMobi's DSP creative specifications and guidelines documentation:
| Requirement | InMobi's documented spec |
|---|---|
| Maximum file size | 5 MB |
| Media format | HTML5 with JavaScript tags |
| Dimensions | Fullscreen, portrait and landscape; responsive design recommended |
| Submission format | A single index.html with all assets inlined as data URIs, or a zipped folder containing index.html plus assets in structured subfolders |
| MRAID compliance | MRAID 3.0, with <script src="mraid.js"></script> in the HTML <head> |
| Playable start trigger | Gated on the mraid.viewableChange event, not fired on page load |
| Click tracking | FbPlayableAd.onCTAClick() or $HTML_ESC_CLICK_URL as placeholders |
| Redirect to store | mraid.open(url), gated on user action rather than automatic |
| External requests | None permitted — no HTTP calls, no XMLHttpRequest, no dynamic asset loading at runtime |
InMobi accepts either a single file or a ZIP
Most networks pick one packaging shape and stick to it. InMobi's spec explicitly permits two: a fully self-contained index.html with every image, audio clip, and font inlined as a data URI, or a zipped folder with index.html at the root next to structured asset subfolders. The one rule that applies regardless of which shape you choose is that nothing may load from outside the package at runtime — the HTML should also be minified.
Why the CTA placeholder mentions a rival network's SDK
One detail in InMobi's own documentation surprises people the first time they see it: the listed click-tracking placeholder is FbPlayableAd.onCTAClick() — a function name that originated in Meta's playable ad SDK, not InMobi's. InMobi's spec lists it alongside $HTML_ESC_CLICK_URL as one of two accepted placeholders for the CTA hook. This is a genuine artifact of InMobi's published spec, not a documentation error someone should second-guess — it's a naming quirk carried over into InMobi's own creative guidelines, and it means a playable already wired for Meta's CTA hook may need less rework than expected when adapting it for InMobi. The actual redirect to the app store still goes through the standard MRAID call, mraid.open(url), and InMobi is explicit that this has to be gated on user interaction rather than firing automatically.
A separate, account-linked ingestion path exists too
Distinct from the custom-coded HTML5 route above, InMobi's documentation also describes a direct submission path for advertisers exporting from a Unity account: log into Unity, open the Creatives tab, select InMobi as the ad network, download the playable, and hand it to your InMobi account contact. That flow — along with similar integrations InMobi documents for Craftsman Plus and PlayTurbo — is account-rep-driven, not a self-serve upload dashboard, and it's separate from hand-packaging a standalone export yourself. The spec above is what applies to that second, self-serve case.
How InMobi compares to networks PlayableKit already exports to
If you're weighing InMobi against a network you already ship to, the shape of the requirements is broadly similar — MRAID, a click-through hook, a size ceiling, a self-contained package — but the specifics differ enough that a build passing one network's review won't automatically pass another's:
- Size ceiling — InMobi's 5 MB matches the cap most other networks use, though a build within budget for one network can land over the limit for another once assets are properly embedded rather than loaded on demand.
- MRAID version — InMobi specifies MRAID 3.0 explicitly; AppLovin and Unity Ads also lean on MRAID's
open()call for click-through, so a build already using MRAID correctly is closer to InMobi-ready than one built around a network-specific SDK call. - Click-through call — Google expects a
clickTagvariable and its ExitApi; Vungle's primary CTA is apostMessagecall with MRAID as fallback; Mintegral expectswindow.install(); TikTok expectsopenAppStore()from its own SDK. InMobi's placeholder convention, borrowed from Meta's SDK naming, sits in its own category. - Packaging — Mintegral wants matching archive/folder/HTML names; TikTok wants a first-level
index.htmlwith aconfig.json. InMobi's either-single-file-or-ZIP flexibility is more permissive than most.
None of that is a reason to avoid InMobi — it's the same category of work as adapting to any additional network, just with InMobi's particular rules substituted in.
What's automated today
PlayableKit turns one Unity Playworks/Luna export into network-compliant packages — clickTag/MRAID/SDK wiring, asset encoding, and package shape, all generated per network's actual rules, InMobi included. Two tools are also free regardless of which networks you target:
- The Playable Ad Validator checks a Playworks/Luna export for structural problems — missing entry files, broken inline scripts, missing engine assets — before you convert it for InMobi or anything else.
- The size checker reports exactly how large your build is and what's driving the weight, which is directly useful against InMobi's 5 MB ceiling.
For the step-by-step conversion workflow, see the export walkthrough. Found an InMobi requirement that doesn't match what you're seeing in production? The fastest way to reach the team is the contact page.