The problem
You upload a build that plays perfectly in your own browser test — it looks and sounds great, the CTA fires cleanly. Then AppLovin's review rejects it, or worse, it passes review but gets pulled or flagged after live traffic starts. In both cases the underlying issue is usually the same: something in the creative fired automatically, without waiting for a real tap or click from the person viewing it.
That "something" isn't limited to audio. Unlike some other networks' playable policies, which focus specifically on sound, AppLovin's rule covers a broader category of unprompted behavior.
The exact restriction in AppLovin's spec
AppLovin's playable requirements state it plainly:
Read that carefully — it's two prohibitions in one line, not one:
- No auto-click. The creative must not simulate a click, fire an
mraid.open()call, or otherwise trigger a store redirect on its own — for example on a timer, on load, or on the first frame of gameplay. The click-through has to be initiated by the user's own tap. - No auto-play audio. Sound must not start until the user has done something. A muted autoplay on load, followed by audio after a genuine tap, is fine; audio firing immediately on load is not.
The rest of AppLovin's playable spec sits alongside this: a single self-contained HTML file (5 MB or smaller, entry file named applovin.html), every resource embedded with no external JS/CSS/image/font/network calls, MRAID 2.0 support with both orientations, and MRAID ready fired before any MRAID API call or layout decision. Autoplay and auto-click issues are frequently tangled up with that last point — see our breakdown of MRAID-not-ready timing errors if your rejection also mentions layout or API-call timing.
Why this rule exists
Ad networks build playable specs around one assumption: the user should be in control of what happens next. A playable that redirects to the App Store the instant it loads — before the viewer has decided they're interested — isn't really letting anyone "play" anything. It converts a rejected tap, a distracted glance, or even just the ad finishing its load sequence into an unintended store visit. That produces angry uninstalls, inflated and misleading click-through numbers, and complaints back to the network from both advertisers and users. Auto-playing audio has a related but distinct problem: sound starting without warning, especially in public or quiet settings, is one of the most common reasons people immediately dismiss or report an ad. AppLovin polices both because both erode trust in the ad unit and, by extension, in the network carrying it.
The fix
The fix is the same shape for both prohibitions: nothing that resembles a click, redirect, or sound should fire from a timer, an animation completing, a level ending, or the page simply finishing load. It has to be wired to a genuine tap or click event on an element the user actually touches.
- Gate the CTA behind a real tap. The
mraid.open(url)call (AppLovin's click API) should only ever run from inside a click/touch event handler on a button or interactive element — never called directly from a game-state callback like "level complete" or "timer expired," even if that callback happens to run after the user has been playing for a while. - Gate audio behind interaction, not load. Keep audio muted or simply not started until the first tap/click anywhere in the creative, then unmute or start playback from inside that same event handler. If you want ambient sound during gameplay, start it muted and only enable it after the user's first interaction.
- Watch for indirect triggers. A common mistake is wiring the CTA to fire automatically once an end-card or "game over" screen renders, on the theory that the user has already engaged with the ad by that point. AppLovin's rule doesn't carve out an exception for this — the click event itself still has to come from the user, on that end card, not from your code deciding the moment has arrived.
- Test it like a reviewer would. Load the build locally, load it, and deliberately do nothing for 10–15 seconds. If audio starts or the click-through fires without you touching anything, it will fail review the same way.
Check it before you resubmit
Before uploading a fixed build back to AppLovin, run it through PlayableKit's free Playable Ad Validator. It flags AppLovin-specific structural issues — single-file packaging, embedded-asset compliance, MRAID readiness — for free with no signup, so you're not spending another review cycle to find out a second issue was hiding behind the first. For the full set of AppLovin packaging and format requirements beyond autoplay, see AppLovin playable ads: requirements, formats & common errors.