AppLovin playable ad orientation requirements explained

Why orientation matters more for AppLovin than you'd think

A playable built for a network that only ever serves in one context — say, a rewarded slot that's always full-screen portrait on a specific app — can get away with hardcoding layout for that one orientation. AppLovin's inventory doesn't work that way. MAX and AppDiscovery serve the same creative into whatever app happens to win the auction, and that app can be portrait or landscape, a hyper-casual game held one-handed or a puzzle game played sideways on a tablet. The ad unit itself can also rotate mid-session on some devices.

That means an AppLovin playable can't assume an orientation. It has to declare that it supports both, and it actually has to render correctly in both — not just avoid crashing, but keep the tap targets, the CTA, and the core gameplay loop usable regardless of which way the host app happens to be oriented when the ad loads.

The exact requirement

PlayableKit's network spec for AppLovin sets requiresBothOrientations: true, separate from — and stricter than — the plain requiresOrientationMeta flag used for networks like Google. The distinction matters: a generic orientation meta tag only has to be present and non-empty to pass a basic check. AppLovin's flag requires the declared value to explicitly cover both orientations, not just one.

Concretely, PlayableKit's validator reads the creative's ad.orientation meta tag:

The rule is checked as: the meta tag's content must contain the string portrait and the string landscape. That's what "supports both orientations" means in AppLovin's spec — it's a specific, testable condition, not a vague suggestion to "make it responsive."

This sits alongside AppLovin's other core requirements worth keeping in mind at the same time: a single self-contained HTML file (5 MB or smaller), MRAID 2.0 as the click-through API via mraid.open(url), zero external requests, no auto-play audio before user interaction, and waiting for MRAID ready before making any API calls or layout decisions — that last one is its own frequent source of bugs, covered in AppLovin MRAID "not ready" timing issues.

Common mistakes

• Building and QA-ing in only one orientation. The playable started life in Unity as a portrait scene (or landscape), it looks right in the editor and on the one test device someone grabbed, and it ships. Nobody rotates the device or resizes the webview before submission, so the failure never surfaces until AppLovin's own review — or a live user — hits it.
• Hardcoding pixel dimensions instead of a responsive layout. Fixed-width canvases, absolutely positioned UI anchored to specific coordinates, and font sizes tuned to one aspect ratio all fall apart the moment the webview's width and height swap. The gameplay area gets clipped, buttons end up off-screen, or the CTA overlaps the game.
• The meta tag says both, but the UI doesn't actually work in both. This is the sneakiest one: content="portrait landscape" is present, so an automated check passes, but nobody actually verified the untested orientation by hand. The tag is a promise to the network, not proof the layout holds up — the ad.orientation value should describe reality, not aspiration.
• Treating "responsive" as a one-time layout fix instead of an interaction fix. Even when the visuals reflow correctly, tap targets sized and positioned for a portrait thumb reach can end up in awkward spots in landscape, especially for a rewarded/interstitial playable where the CTA has to stay reachable and unambiguous.

How to fix it

1. Build the layout with relative units (viewport-relative sizing, flex/grid) rather than fixed pixel coordinates, so the scene reflows instead of clipping when the aspect ratio flips.
2. Actually rotate a device — or resize the browser window — and play through the full interaction in both orientations before calling it done: menu, core gameplay moment, and the CTA/end-card tap.
3. Set <meta name="ad.orientation" content="portrait landscape"> only once both orientations have been manually verified, not as a shortcut to get past a checklist.
4. Keep this validated alongside the other AppLovin fundamentals — single-file output, MRAID 2.0, no external requests, and waiting for mraid.viewableChangeEvent/ready state before touching layout — since a fix for one of these often interacts with the others.

For AppLovin-specific packaging beyond orientation — the MRAID version, the single-file/5 MB constraint, click-through wiring, and the review pitfalls that trip up otherwise-solid creatives — see AppLovin Playable Ads: Requirements, Formats & Common Errors.