Unity Ads playable requirements: a 2026 checklist

A playable for Unity Ads is one self-contained HTML file under 5 MB, built for MRAID 3.0, with no network requests, one responsive build for portrait and landscape, and a store redirect only after a tap on a call to action (CTA). The checklist below follows Unity’s docs and is grouped so you can run through it before every upload. Gaps in the docs are listed at the end.

Where these rules come from

Unity’s What’s new in User Acquisition page lists the playable requirements among its October 2026 entries, as new or changed. The detail is on the playable specifications page and the playable best practices page.

File and size checklist

According to the specifications page, the build must meet all of these:

• A single HTML file named index.html.
• Less than 5 MB. The best practices page and the moderation checks repeat this limit.
• Every image, audio and video asset inlined as base64 data.
• No references to other files, folders or assets through relative paths or remote URLs. The device downloads only the HTML file from the CDN, and Unity Ads ignores anything outside it.
• Minified: whitespace removed and names shortened.
• Works on Android 5 or later and iOS 13 or later.

The same page says a playable that works locally but shows a blank screen in the ad unit usually still references an asset by path or URL. That is the first thing to check when a build looks fine on your machine.

Network and attribution checklist

• No network requests (XHR). The playable can’t load images, configuration or other content from a server at runtime.
• Analytics calls only, and only the ones Unity permits. They can’t contain personal data.
• No attribution events of your own. Unity’s docs say it handles start, view and click attribution server-side.

Layout and orientation checklist

• Portrait and landscape from a single responsive build. Per the docs, separate horizontal and vertical uploads are marked for deprecation and all new playables must be responsive. Single-orientation playables in existing creative packs or campaigns keep working.
• The layout adjusts when the screen is resized or rotated.
• Text and buttons stay out of the top and bottom areas where Unity draws its own controls: the countdown, the close button and privacy or consent UI. Unity’s docs say these controls can change over time, so leave margin.
• Nothing blocks the close button.
• No custom close buttons, fake close buttons, fake system UI or deceptive alerts.

MRAID and viewability checklist

• The playable supports MRAID 3.0. Unity’s webview injects it, so you don’t need an MRAID script tag.
• Only full-screen behavior. Unity’s docs list expand, resize, custom close buttons, sms, tel, calendar and storePicture as unsupported.
• Gameplay starts only after the MRAID ready event and only when the ad is viewable. It does not start on page load.
• Gameplay pauses when the ad isn’t viewable.

For a working layout of these steps, see our MRAID 3.0 playable skeleton.

Audio and video checklist

• The playable is silent when the iOS mute switch is on. Unity’s docs say to use the Web Audio API as the primary audio path and HTMLAudioElement only as a fallback, because HTMLAudioElement ignores the iOS mute switch.
• Audio stops when the ad isn’t viewable. The docs say to mute and resume from the viewableChange handler.
• Sound stops when the device locks and returns when it unlocks (this one is from the rejected page).
• Native video controls are hidden.

Store redirect and CTA checklist

• The store opens through mraid.open, triggered by a player tap on a CTA after the player has interacted with gameplay.
• The first tap never opens the store. Redirects without player interaction aren’t allowed.
• No gameplay element opens the store. Unity’s docs call that a deceptive redirect.
• The CTA opens the right store page on iOS and on Android. For platform detection, the docs say newer iPadOS versions report Macintosh in the user agent, so test for Android and treat everything else as iOS.
• If you build your own end screen, one CTA stays visible and nothing recreates Unity’s end card.

When a player skips or closes the playable, Unity shows its own end card with the app icon, rating, game name and a download button. The best practices page says you don’t build it and can’t change its style.

First seconds: Unity’s best-practice targets

These come from the best practices page and are targets, not stated limits:

• The playable loads and reaches the first interaction in less than 2 s on a mid-tier device.
• The core mechanic is clear within 3 to 5 s, because the Unity close button can appear after only 5 s.
• It opens on a state the player can act on at once: no logos, studio splashes or cinematic intros.

What moderation checks

Two Unity pages matter here: Rejected creative packs and Moderation checks. The checks page covers all creatives, not only playables. The items that map onto playables:

• Specification: code is minified, file size is under 5 MB, content works on iOS 13 or later and Android 5 or later, no polyfill issues for older Android versions.
• Compatibility: scales to the screen, handles orientation changes, the install button leads to the iOS or Android store, respects the physical mute button on iOS.
• Functionality: performs without slowdowns or stuttering, no network requests beyond permitted analytics, no console log errors, the install button is accessible and not obstructed.
• Content: not too difficult for the audience, a reasonable length before the end screen and CTA.

The rejected page lists three playable-relevant reasons: the ad breaks when switching between portrait and landscape, it ignores device lock, and it ignores the iOS mute button. Fix the issue and submit again. A campaign needs at least one approved creative pack to go live, and pending packs in a live campaign run automatically once approved. Unity’s docs also state that gambling advertisers need managed accounts and that gambling creatives from unmanaged partners are rejected in moderation.

Test before you submit

Unity’s best practices page asks for a build that also runs without MRAID, so you can test the full playable in a desktop browser at mobile resolution. It also asks for a real-device check: the User Acquisition dashboard generates a QR code for each creative pack when you select Show QR code, and the Ad Testing app opens the preview. Rotate the device while it plays. Per the docs, a desktop browser or simulator doesn’t run your playable in the real ad unit, and many common rejection reasons only appear on a real device.

What the docs don’t say

The pages we read are silent on these points, so don’t treat any of them as known:

• The size limit for a single asset, or any base64 limit beyond the 5 MB total.
• Audio and video codecs, frame rates and duration limits.
• Exact pixel sizes of the reserved control areas.
• Which SDK or webview versions inject MRAID.
• How moderation tests a playable, how long review takes, how to appeal, or the exact text of a rejection reason.
• How loading time is measured, or what counts as a mid-tier device.
• A blank-screen, MRAID or redirect check named as such on the moderation checks page.

Other networks set different limits, which is why a build that passes here may fail elsewhere. See playable ad specs by network for the side-by-side.

Doing this in DarkCore Ramet

DarkCore Ramet includes a Playable Builder. This checklist covers Unity’s rules, not the builder, so run any build through it before upload. For video, a file uploaded once in creatives goes to every app that needs it.