How to Export Playable Ads for AppLovin & Mintegral (and Where ironSource Went)

AppLovin and Mintegral together reach a large share of mobile game players. Mintegral is strong in APAC, and AppLovin is big in North American mid-core. Exporting both from one design saves a lot of time, but they do not read the same store-exit call, and each file has to match its network. Current specs: AppLovin and Mintegral playable ad specs.

What Happened to ironSource Ads

This guide used to cover ironSource as a third export. ironSource Ads stopped taking new creatives on 15 April 2026 and stopped serving on 30 April 2026; Unity asked its advertisers to move to Unity Ads (Unity's own guide to the ironSource Ads direct demand sunset). LevelPlay mediation carries on as a Unity product, but there is no longer an ironSource Ads campaign to upload a playable to, so Playable Ads Maker no longer offers an ironSource export. If you ran playables on ironSource, export the same project for Unity Ads instead: one inlined HTML file with MRAID, the store exit on mraid.open().

AppLovin MAX Requirements

AppLovin MAX uses MRAID 2.0 as its standard interface. The MAX SDK injects the mraid.js object at serve time. Your HTML should listen for the mraid ready event before initializing your creative, call mraid.open() on CTA tap, never send the player to the store on their first interaction, keep sound off until the first tap, and show a fallback if WebGL is not available. AppLovin end cards are static images, so it is the full playable you export for AppLovin. AppLovin also enforces file integrity checks: if any asset fails to load during their automated review, the creative is rejected with a 'failed to load' error.

AppLovin serves across its publisher network (MAX mediation) and its own first-party inventory. Staying under 1 MB matters on AppLovin because its publisher network includes apps whose users are on slow connections.

Mintegral Requirements

Mintegral does not use MRAID. It takes a ZIP with index.html, and its own JavaScript API provides the store exit: the creative calls window.install(), not mraid.open(), and signals its lifecycle with gameReady() when it can be played and gameEnd() once when the round ends. Mintegral's documentation lists a missing gameEnd on the win as a common rejection. This is the most common mistake when repurposing a creative built for AppLovin for Mintegral: the MRAID exit is simply not the one Mintegral reads. Unlike AppLovin, Mintegral takes interactive end cards as well as playables.

Mintegral's APAC inventory reaches markets with variable network speeds. A creative that loads in 1 second in North America might take 4 seconds on a 3G connection in Southeast Asia. Size optimization matters more for Mintegral than for any other network in most UA mixes.

Design Choices That Survive Both Networks

The export decides the wiring, but the design decides whether one creative can honestly be shipped to both. A few choices made at the start save you from building a second version later.

• Route every store exit through one place. If the CTA button, a tap on the game board after the round and a timed prompt all lead to the store, make them all call the same exit action in your editor. A creative with three separate exits is a creative where one of them gets missed when the wiring changes per network.
• Make the end of the round a real moment. Mintegral wants gameEnd once, when the round ends. If your creative has no clear end (it just loops) there is nothing honest to signal. Give it a win state, a fail state, or both, and put the CTA there.
• Never draw your own close button. The ad container supplies one, and a second close control painted into the creative is confusing at best and a review problem at worst.
• Do not exit on a timer or on the first tap. AppLovin does not allow a store redirect on the player's first interaction, and an auto-redirect is a poor experience on every network anyway.
• Design for silence. Audio may start muted or be blocked until the first touch, so the creative must make sense with no sound at all.

When One Network Rejects and the Others Accept

Because the builds share their content and differ only in wiring, a rejection on one network and an approval on the other narrows the cause quickly. Work through it in this order:

1. Confirm the right file went to the right dashboard. A Mintegral build uploaded to AppLovin, or an MRAID file uploaded to Mintegral, fails for reasons that have nothing to do with the creative. This is what the file naming in the callout below is for.
2. Check the exit call the rejection mentions. Mintegral reads window.install(); AppLovin reads mraid.open(). A message about the CTA not working almost always means the wrong one is present.
3. Check the lifecycle signals. On Mintegral, a missing gameEnd on the win is a listed rejection cause, so play the creative to the end of the round and make sure it gets there.
4. Check size against each network's own limit. AppLovin publishes 5 MB for its single HTML file and Mintegral 5 MB for its ZIP. If one build is close to a limit and the other is not, the packaging is the difference.
5. Run the file through a validator. The MRAID validator and the spec checker catch the mechanical problems before a human reviewer does.

For the broader list of causes, see playable ad rejection reasons and, for creatives that pass review but misbehave live, troubleshooting a playable that is not working.

Exporting Both From One Creative

Playable Ads Maker handles the differences for you. Selecting AppLovin in the export modal produces a single HTML file with mraid.js and mraid.open(). Selecting Mintegral produces a ZIP wired to window.install() with the gameReady and gameEnd calls. You design once and get correct files for each, with no HTML editing and no SDK documentation to read.

1. Design your playable in the Playable Ads Maker or the Video Playable Maker.
2. Set iOS and Android store URLs in the export modal.
3. Select AppLovin → export and download.
4. Select Mintegral → export and download.
5. Upload each file in the corresponding network dashboard.

Keeping Builds in Step

The fastest way to end up with different creatives that were meant to be one is to fix a typo by hand in one file. The next time you re-export, the fix is gone from that network and was never in the others. Treat the project as the only source of truth and the exported files as disposable output.

• Any change (copy, art, a store URL) means re-exporting every network, not patching the one that prompted the change.
• Keep the store URLs in the project, not in your head. Both iOS and Android links go in the export modal, and every network build picks them up from there.
• Re-test the CTA on a real device after every export, on both platforms. A correct file with a wrong store link passes review and sends paid traffic to the wrong place.
• Record which export is live where. A short log of file name, date and network makes it obvious which build a reviewer or an ad ops colleague is talking about.

If you are adding more networks to the same rollout, the AppLovin MAX guide covers that network in depth, and the size limits by network post sets out where each one draws its line.