Mediation SDK & Adapter Compatibility Guide for Mobile Apps (2026)

Mediation SDK version mismatches break ad serving without throwing a build error. The risk is in the adapter layer: each mediation adapter is certified against a specific demand SDK version. Running an uncertified pair silently degrades fill or crashes on specific OS versions. Run the free Mediation SDK Checker to audit your dependency files before shipping.

Detecting your current versions

Before you can act on a version mismatch, you need to know what versions are actually running in your build. This sounds obvious, but there is a consistent gap between the version you declared and the version your dependency resolver actually installed.

On Android, your version declarations live in build.gradle, build.gradle.kts, or a libs.versions.toml file if your project uses Gradle version catalogs. But what Gradle resolves can differ from what you declared, especially if any dependency uses a version range or a + wildcard constraint. To see the resolved versions, run:

./gradlew dependencies --configuration releaseRuntimeClasspath

This shows the full dependency tree with the actual resolved artifact versions. Scan for your mediation SDK, each network adapter, and each demand SDK.

On iOS with CocoaPods, pod outdated compares your installed versions against the latest available. Your Podfile.lock contains the exact versions that were installed at the last pod install. The lock file is your source of truth, not the Podfile declarations themselves.

On iOS with Swift Package Manager, Package.resolved holds the resolved versions. Check it directly.

For Unity projects, adapter versions are declared in mainTemplate.gradle for Android and in the Unity Package Manager manifest. The Unity Integration Manager (available through the AppLovin or AdMob Unity plugin) gives a dashboard view of which adapter versions are installed and whether they are current.

The mediation platform dashboard is not a reliable version source. AdMob's and AppLovin MAX's dashboards show which networks are configured, not which adapter versions are installed in your build. You can have a network configured in the dashboard and a months-old adapter in your build at the same time.

If you want to skip the CLI steps, the free Mediation SDK Checker runs these version checks automatically against your uploaded dependency files.

Adapter vs SDK version

This is the concept most developers understand informally but have never had named clearly. There are three separate layers in a mediation setup, and they each have their own version:

The Mediation SDK is the orchestrator. AppLovin MAX SDK, IronSource LevelPlay SDK, and the AdMob mediation framework are mediation SDKs. This is the layer that runs your waterfall or bidding logic and decides which network to call for each ad request.

The Mediation Adapter is the bridge between the mediation SDK and a specific demand source. Every network you add to your mediation setup has its own adapter. The MAX adapter for Google, the MAX adapter for Meta Audience Network, and the MAX adapter for IronSource are three separate packages with their own version numbers and their own release cadence.

The Demand SDK is the actual partner SDK that loads and renders the ad. Google Mobile Ads SDK, Meta Audience Network SDK, and IronSource SDK are demand SDKs. The demand SDK handles the actual ad request, creative loading, and rendering. The mediation adapter speaks to both the mediation SDK above it and the demand SDK below it.

The version that causes the most confusion is the adapter version, because it often encodes the demand SDK version it was certified against. The MAX adapter for Google versioned 25.2.0.0 was certified with Google Mobile Ads SDK 25.2.0. The first three segments of the adapter version number map to the base demand SDK version. The fourth segment is the adapter's own patch revision.

What this means in practice: if you upgrade GMA to 25.3.0 but your MAX adapter is still at 25.2.0.0, you are running an uncertified pair. The build compiles. The ad unit loads in testing. But on specific device and OS combinations, the adapter may fail to initialize, report zero fill, or crash in edge cases that do not surface in your mediation debugger. The only signal is a fill rate or eCPM dip on that network's line in your reporting, and that has a dozen possible explanations.

The practical rule: when upgrading either the demand SDK or the mediation adapter, upgrade both together and confirm the pair appears on your mediation platform's certified compatibility matrix before shipping.

For more background on the adapter architecture, see what mediation adapters actually do.

AppLovin MAX version strategy

AppLovin MAX publishes changelogs for the main MAX SDK and for each network adapter separately. The main SDK and the adapter changelogs are different documents, and a GMA release will typically have a corresponding MAX adapter update within one to two weeks.

Certified adapter lag. When Google releases GMA 25.3.0, the MAX adapter certified for 25.3.0 may not be available for 7-14 days. Updating GMA immediately after a Google release means your MAX adapter is temporarily running against an uncertified GMA version. This is not always a problem, but it is the window where the issues in Issue 2 and Issue 4 in the next section have historically appeared.

MAX Integration Manager. AppLovin's Integration Manager tool (available in the MAX dashboard and as a Gradle plugin) tracks which adapter versions are certified for your current MAX SDK version and flags outdated ones. If you manually pin adapter versions rather than letting the Integration Manager manage them, version drift is the expected outcome over time. Most of the "my fill dropped after an update" cases I see involve manually pinned adapters that were not updated when the mediation SDK moved.

Even/odd patch cadence. AppLovin MAX iOS and Android tend to have more in-cycle changes in odd-numbered minor releases (e.g., 13.1.x, 13.3.x) and more stable behaviour in even-numbered minor releases (e.g., 13.0.0, 13.2.0, 13.4.0). This is a pattern observed in the release notes and GitHub issue reports, not an official AppLovin policy. For production builds, waiting for the even-numbered minor releases before upgrading is a lower-risk cadence.

MAX 13.0.0 ad experience change. AppLovin MAX 13.0.0 changed the interstitial ad experience: duration extended from approximately 8 seconds to 15 seconds or longer, and the skip button mechanism changed. This is an intentional product decision. For apps where interstitial completion rate or post-interstitial retention is a key metric, evaluate the experience change before upgrading to the 13.x line. Holding at 12.x until the new experience is validated against your retention data is a defensible choice.

The free Mediation SDK Checker flags MAX SDK and adapter versions that are outside the certified compatibility range for each demand partner you use.

If you are evaluating whether AppLovin MAX is the right mediation platform for your setup, the full comparison is in AppLovin MAX vs Unity LevelPlay.

Google AdMob version strategy

Google Mobile Ads SDK versioning for Android and iOS runs on separate version tracks. Android follows a X.Y.Z Maven artifact version. iOS follows a separate X.Y.Z CocoaPods or Swift Package Manager version. The two tracks are not numerically synchronized. GMA Android 25.2.0 and GMA iOS 11.x.x are current at the same time. Do not try to keep them on matching version numbers.

Major version breaks. GMA major version upgrades typically carry integration-level breaking changes. GMA Android 23.0.0 bumped the minimum SDK requirement to API 23 (Android 6.0), breaking builds that targeted older Android versions. GMA Android 24.0.0 changed the initialization API for mediation adapters. Before any GMA major version upgrade, check the migration guide and check every adapter's certified version range for the new GMA version. Not just AppLovin. Every adapter in your build.

The certified adapter matrix. Google publishes a compatibility matrix for AdMob mediation adapters at developers.google.com. This is the authoritative source for which adapter version to use with each GMA version. The matrix is updated when new adapter versions are certified. Check it before upgrading GMA, not after.

AXON participation. Google's ML-based bidding layer, AXON, was updated in 2024. Older GMA SDK versions may not participate fully in the current AXON auction, which has a direct eCPM impact. This is a revenue-side reason to keep GMA reasonably current even if your current version is technically stable. The eCPM effect of running an old GMA version is not visible in any single dashboard, but it compounds over time.

Privacy Manifest for iOS. GMA iOS 11.2.0 was the first version to include the PrivacyInfo.xcprivacy file required for App Store submissions on iOS 17.4+, enforced by Apple in May 2024. If you are running GMA iOS below 11.2.0 and you submit a new build or update to the App Store, the submission will be rejected. This is not a recommendation to upgrade at some point. It is a hard submission blocker.

The Mediation SDK Checker checks your GMA SDK version against the current Privacy Manifest requirement and the certified adapter range for each network you use. You can also cross-reference with the AdMob Approval Checker for the account-side configuration requirements.

For a broader comparison of AdMob as a platform versus running MAX alongside it, the decision framework is in AdMob vs AppLovin MAX. For the approval process specifically, see the AdMob Approval Guide.

Privacy Manifest and SKAdNetwork

Privacy Manifest enforcement. Apple began requiring PrivacyInfo.xcprivacy in App Store submissions in May 2024. The file must declare which required-reason APIs the app (and all its SDKs) access, what data types are collected, and which tracking domains are used. Every SDK in your build that accesses a required-reason API must include a compliant PrivacyInfo.xcprivacy or the App Store submission will flag it.

Most major SDKs added their privacy manifest declarations in 2024. The problem is that some mediation adapters have outstanding gaps. As of Q1 2026, the AppLovin MAX adapter for AdMob mediation on iOS has a documented unresolved issue where the CHHaptics RequiredReasonAPI is accessed but not declared in the privacy manifest. This causes crashes in the mediation debugger and may generate App Store warnings depending on Apple's current validation tooling. The issue is tracked at AppLovin-MAX-SDK-iOS/issues/318 and has been open since 2025. Check the status of that issue before your next App Store submission if you use the AppLovin MAX adapter with AdMob mediation.

How to audit your build's privacy manifest coverage. In Xcode, after building an archive go to Product > Archive > Distribute App and look at the privacy manifest report before submitting. This shows the aggregated privacy manifest from all frameworks in the build and flags any required-reason API usages that are not covered by a declaration. Do this after any SDK update that touches iOS adapters, not just at the start of a new submission.

SKAdNetwork ID maintenance. Ad network SDKs require their SKAdNetwork IDs to be declared in your app's Info.plist. Mediation platforms typically generate this list through their integration tools, and the AppLovin Integration Manager and Google's AdMob mediation setup both provide current SKAdNetwork ID lists. The issue is that this list is not static. When a network adds new IDs in a SDK release, those IDs need to be in your Info.plist or the SKAdNetwork attribution for that network's campaigns fails silently. There is no attribution error thrown. The signal is attribution volume dropping on that network's line in your MMP.

The maintenance cadence for SKAdNetwork IDs should match your adapter update cadence. When you update an adapter, regenerate or update the SKAdNetwork ID list from the mediation platform's integration tools at the same time.

The Mediation SDK Checker audits your dependency files for known Privacy Manifest gaps and flags SDK versions where the manifest declaration has documented outstanding issues.

Known version mismatch issues

This is the section where most of the real diagnostic value lives. Each issue below has a documented source, an affected version range, a description of what actually breaks, and the fix. If your build matches an affected version range, treat it as a high-priority item.

Issue 1: GMA Android 25.0.0, close-button off-screen on Android 15+

GMA Android 25.0.0 on Android 15+ devices renders the interstitial close button off-screen. Users cannot dismiss the interstitial, which is a direct monetization and UX problem. The close button position calculation changed in 25.0.0 and is incompatible with Android 15's edge-to-edge enforcement. Fix: upgrade to GMA Android 25.1.0 or later. Source: Google Mobile Ads SDK Android release notes.

Issue 2: AppLovin Android adapter 9.4.0 + GMA 24.x, initialization failure

AppLovin MAX Android adapter versions at or below 9.4.0 combined with GMA Android 24.x fail on initialization with "no fill error 3." The AppLovin demand source does not initialize, and AppLovin's fill goes to zero. This is a silent failure at the adapter layer. The mediation SDK reports AppLovin as configured, but the adapter never initializes. Fix: upgrade the AppLovin Android adapter to 9.4.2.0 or later, and confirm GMA is on 24.0.0 or later. Source: Google AdMob SDK Groups thread.

Issue 3: AppLovin MAX iOS 13.3.0, crash on initialization

AppLovin MAX iOS 13.3.0 crashes immediately on SDK initialization. The crash originates from CHHapticEngine before any ad request is made. This version should not be shipped in production. Fix: downgrade to 13.2.0 or skip directly to 13.4.0 or later. If you have 13.3.0 in production now, this is an urgent update. Source: AppLovin-MAX-SDK-iOS/issues/459.

Issue 4: GMA iOS 11.13.0 + AppLovin MAX iOS 13.0.1, interstitial crash on iOS 18

The combination of GMA iOS 11.13.0 and AppLovin MAX iOS 13.0.1 crashes when loading an AppLovin interstitial on iOS 18 devices, throwing "Unknown ad size." This affects a specific version pairing only, but iOS 18 device share is significant. Fix: upgrade AppLovin MAX iOS to 13.3.0 or later. Source: AppLovin-MAX-SDK-iOS/issues/417.

Issue 5: AppLovin MAX iOS adapter for AdMob mediation, Privacy Manifest CHHaptics gap (outstanding Q1 2026)

The AppLovin MAX iOS adapter for AdMob mediation accesses the CHHaptics RequiredReasonAPI but does not declare it in its PrivacyInfo.xcprivacy. The mediation debugger crashes as a result. App Store submissions may receive Privacy Manifest warnings depending on Apple's validation tooling at time of submission. There is no available fix as of Q1 2026. Track AppLovin-MAX-SDK-iOS/issues/318 for resolution. Source: AppLovin GitHub, 2025.

Issue 6: Facebook SDK + AppLovin MAX iOS adapters, framework linking conflict

AppLovin MAX iOS adapters require "Link Frameworks Statically" set to true in Xcode Build Settings. The Meta Audience Network (Facebook) SDK uses dynamic framework linking in configurations where this setting conflicts. There is no clean general resolution. If your app combines these two, treat it as requiring a dedicated build configuration test pass before each release. The conflict varies based on your specific Xcode and SDK versions, but it is an active and documented issue. Source: googleads/googleads-mobile-unity/issues/2736.

Issue 7: GMA Unity Plugin 7.4.1+, archive fails with bitcode

GMA Unity Plugin 7.4.1 and later removed bitcode from the plugin. Any Unity project with bitcode enabled in Xcode Build Settings will fail to archive after updating the plugin. This is a build failure, not a silent runtime issue, so it surfaces immediately on the next archive attempt. Fix: disable bitcode in Xcode Build Settings under "Build Options." Source: googleads-mobile-unity/issues/2594.

Issue 8: Unity Mediation SDK deprecated

Unity Mediation was merged into IronSource LevelPlay in April 2024. The standalone Unity Mediation SDK is deprecated and will not receive further updates. Apps still using it as a mediation layer are on an unsupported codebase with no path to new demand sources. Fix: migrate to the IronSource SDK directly for LevelPlay mediation. Do not use the Unity Ads SDK as a mediation orchestrator. The Unity Ads SDK is a demand SDK, not a mediation layer. Source: Unity Discussions, 2025.

Issue 9: IronSource adapter, rewarded video completion callback silent failure

After certain IronSource adapter version updates, rewarded video completion callbacks silently fail to fire. The ad plays, revenue is attributed in the IronSource dashboard, but the app's server-side reward validation does not receive the callback. This is a data integrity problem for apps using server-side reward verification. Fix: match the adapter version to the corresponding IronSource SDK release date using the certified compatibility table. Mismatched adapter and IronSource SDK versions are the primary cause of this failure pattern. Source: Unity Discussions, 2025.

Issue 10: GMA iOS below 11.2.0, App Store submission rejected

GMA iOS below 11.2.0 does not include the PrivacyInfo.xcprivacy required by Apple for App Store submissions on iOS 17.4+, enforced since May 2024. Any new App Store submission with GMA iOS below 11.2.0 is rejected. This is not a deprecation warning. It is a hard submission blocker. Fix: upgrade to GMA iOS 11.2.0 or later before any new App Store submission.

Issue 11: AppLovin MAX 13.0.0+, interstitial experience change

AppLovin MAX 13.0.0 and later changed interstitial duration to 15 seconds or longer and changed the skip button mechanism. This is an intentional change, not a bug. It does not break ad serving. The impact is on interstitial-related retention metrics and reward logic tied to completion rates. Fix: there is no fix because it is not a bug. Monitor your retention and revenue metrics after upgrading to the 13.x line and adjust any reward logic that depends on completion timing. Source: AppLovin MAX SDK Android releases and AppLovin MAX SDK iOS releases.

Issue 12: GMA Android 24.0.0, minSdk bump to API 23

GMA Android 24.0.0 raised the minimum SDK version requirement to API 23 (Android 6.0). Apps with minSdkVersion set below 23 fail to build after upgrading to GMA 24.0.0. Fix: bump minSdkVersion to 23 in your build.gradle, or hold at GMA Android 22.x until your device support policy permits the change. Check your analytics for Android 5.x device share before deciding. For most apps this is below 0.5%, but verify against your own data.

Issue 13: IronSource adapter below 8.5.0.1 + GMA Android 23.x build failure

IronSource Android adapter versions below 8.5.0.1 conflict with GMA Android 23.0.0 and later at the dependency declaration level, causing a build failure. The fix is to upgrade the IronSource adapter to 8.5.0.1 or later before upgrading GMA to 23.x. Do not upgrade GMA first and expect to fix the adapter after. The build will fail.

Issue 14: Yandex Ads Android adapter, ANR on main thread

Yandex Ads Android adapter versions prior to the fix release had a "Input dispatching timed out" ANR (Application Not Responding) issue on the main thread. This generates Android Vitals flags and affects app quality ratings on Google Play. Fix: upgrade to the latest Yandex Ads Android adapter. Check the Yandex Ads Android changelog for the specific release that resolves the ANR.

Issue 15: Defold + IronSource + AdMob manual combination crash

Apps built on the Defold game engine that manually combine IronSource and AdMob SDKs crash on build. The native dependency resolution in Defold does not handle the manual combination cleanly. Fix: use Defold's native mediation plugin rather than manually including both SDKs. Source: Defold developer forum, 2024.

The Mediation SDK Checker flags the version ranges in Issues 1, 2, 3, 4, 7, 10, 12, and 13 automatically. Issues 5, 6, 8, 9, 11, and 15 require either manual assessment or a more specific dependency audit beyond what automated version checking can do.

How to test after an upgrade

The sequence for a safe SDK upgrade has three stages. Do not collapse them.

Stage 1: Dependency validation (before building)

Run the Mediation SDK Checker against your updated dependency files before building. Confirm the new SDK version, its adapters, and the corresponding demand SDK versions all appear on the certified compatibility matrix. If any adapter is lagging, update it before building. This is the fastest stage and the cheapest place to catch a mismatch.

Stage 2: Build validation (after building, before canary release)

Run your mediation platform's debugger tool on a physical device with the new build installed. AppLovin MAX's mediation debugger, Google's AdMob mediation debugger, and IronSource's test suite each report adapter initialization status, SDK version, and whether a test ad loads successfully. These tools surface hard initialization failures and adapter connectivity issues.

For iOS, after building the archive, run the Privacy Manifest report before submitting to App Store Connect: Product > Archive > Distribute App, then review the manifest. Confirm that all required-reason API usages are covered. This catches Privacy Manifest gaps before Apple's reviewer does.

Stage 3: Production canary (after release)

Push the updated build to 5-10% of traffic first. Watch the following for 48-72 hours before expanding:

• Per-network fill rate (not total fill rate). A fill drop on the upgraded network's line is the primary signal of a version mismatch.
• Per-network eCPM. A significant eCPM shift on one network after an upgrade points to an adapter running in an uncertified pair.
• Crash rate from Android Vitals or Xcode Organizer, filtered to the OS versions where the known issues above are relevant (Android 15 for Issue 1, iOS 18 for Issue 4).

If Stage 3 shows clean numbers after 72 hours, expand to full traffic. If it shows a fill drop or eCPM decline on one network, roll back the upgrade for that network's adapter and investigate before expanding.

When to hold vs upgrade

The default position is to upgrade on a cadence, not reactively. Waiting for a problem to appear before upgrading is the pattern that creates the version drift in the first place. But not every upgrade warrants the same urgency.

Upgrade immediately:

• Privacy Manifest gaps that block App Store submissions (Issue 10 is the current example)
• Crash bugs on a currently dominant OS version (Android 15 or iOS 18). Revenue impact is immediate and the crash affects your Android Vitals / App Store ratings.
• Security vulnerabilities disclosed in a SDK release note.

Upgrade on next sprint (within 2 weeks):

• New GMA major version with a certified adapter matrix update, once the new adapters are available.
• Breaking API changes that require code-side updates, batched to avoid emergency releases.
• Any issue in the known-issues list above where your version is in the affected range.

Hold until the next stable release:

• Odd-numbered minor releases of AppLovin MAX iOS/Android where the GitHub issue thread shows active in-cycle reports.
• Any adapter version where the certified demand SDK version is not yet available (i.e., the demand SDK you use has released but the adapter has not).
• First-week releases of any major SDK version. Let the first patch cycle clear before upgrading production.

Hold until a migration path is clear:

• Deprecated SDK families (Unity Mediation is the current example). Do not ship deprecated SDKs for a new feature or app. Migrate on a defined timeline.
• Adapters with an active documented compatibility issue where no fix is published (Issue 5 as of Q1 2026).

The hold decision is not free. Holding GMA iOS below 11.2.0 means App Store submission failures. Holding a MAX adapter below the certified GMA version means running an uncertified pair with silent fill risk. Every hold has a cost. The question is whether the cost of upgrading now is higher than the cost of holding. In most cases for Issues 1-4 and Issue 10, the upgrade is the lower-cost option.

If you are managing more than one app, or a mediation stack that involves coordinating adapter upgrades across multiple platforms at once, a structured review of your dependency files against the known-issues list is the right starting point. The free 30-minute call covers that kind of stack review.

For a full comparison of mediation platforms and their version management tooling, see AdMob vs AppLovin MAX.

Frequently asked questions

What is the difference between a mediation SDK, a mediation adapter, and a demand SDK?

The mediation SDK (e.g., AppLovin MAX or IronSource LevelPlay) is the orchestrator that manages your waterfall or bidding logic. The mediation adapter is the bridge between the mediation SDK and a specific demand source, with its own version number and release cadence. The demand SDK (e.g., Google Mobile Ads SDK) is the partner SDK that actually loads and renders ads. Version mismatches between the adapter and the demand SDK cause silent fill degradation even when the build succeeds.

How do I know if my mediation adapter is compatible with my demand SDK version?

Check the certified compatibility matrix published by your mediation platform. For AppLovin MAX adapters to Google, the adapter version encodes the certified base GMA version in the first three segments: MAX adapter 25.2.0.0 is certified with GMA SDK 25.2.0. For IronSource, AdMob, and other platforms, the compatibility matrix is in the mediation platform's developer documentation. Check it before upgrading either the adapter or the demand SDK.

Why did my fill rate drop after a GMA SDK upgrade?

The most likely cause is a version mismatch between the updated GMA SDK and adapters that were not updated at the same time. When you upgrade GMA without upgrading the adapters certified for that GMA version, adapters run in an uncertified pair and may silently degrade or fail to initialize. The signal is a per-network fill rate drop on the affected network's line. Run the Mediation SDK Checker to identify which adapters are running outside their certified range.

Does the Privacy Manifest requirement affect all mediation SDKs on iOS?

Yes. Apple has required PrivacyInfo.xcprivacy in App Store submissions since May 2024 for iOS 17.4+. GMA iOS 11.2.0+ includes the required manifest. Several mediation adapters still have outstanding gaps in their declarations as of Q1 2026. The most significant open issue is the CHHaptics RequiredReasonAPI in the AppLovin MAX adapter for AdMob mediation on iOS (AppLovin-MAX-SDK-iOS/issues/318).

What changed in AppLovin MAX 13.0.0?

AppLovin MAX 13.0.0 introduced two separate changes that are often conflated. First, the interstitial ad experience changed: duration increased from approximately 8 seconds to 15 or more seconds, and the skip button mechanism changed. This is intentional, not a bug. Second, AppLovin MAX iOS 13.3.0 (a later release in the same major version line) had an unrelated crash on initialization from CHHapticEngine. Do not ship 13.3.0. For the experience change in 13.0.0, monitor retention and revenue metrics after upgrading.

How do I fix my setup after Unity Mediation was deprecated?

Unity Mediation was merged into IronSource LevelPlay in April 2024. The standalone Unity Mediation SDK is no longer supported. If your app uses it, migrate to the IronSource SDK directly for LevelPlay mediation. The Unity Ads SDK is a demand-side SDK, not a mediation orchestrator, and should not be used as a replacement for mediation functionality. Use IronSource SDK with the LevelPlay mediation layer.