Free Tool
Audit your mediation SDK versions before they break in production
Pick your mediation, add your demand networks, and get a per-package report: current vs outdated, deprecated, or hitting a known crash. AdMob, AppLovin MAX, and Unity LevelPlay. No signup.
Refreshed weekly
iOS + Android
No data stored
Common questions
What does this tool actually check?
We parse your build.gradle (Android) or Podfile (iOS) and look up every mediation SDK and adapter version against a database refreshed weekly from AppLovin's public adapter changelogs and Google Maven. For each entry we report whether it is current, behind by a few releases, deprecated, or hits a known compatibility issue with a documented fix. We also surface a manual checklist for items only you can confirm: Privacy Manifest, mediation debugger results, post-upgrade testing.
Which mediation platforms are supported in v1?
Google AdMob, AppLovin MAX, and Unity LevelPlay (formerly ironSource Mediation). Both iOS and Android. Common demand SDKs (Meta Audience Network, ironSource, Unity Ads, Vungle, Mintegral, Pangle, Chartboost, InMobi, BidMachine, PubMatic, DT Exchange) are tracked when they show up as adapters under those mediation platforms.
Where do I find my build.gradle or Podfile?
On Android, build.gradle lives at app/build.gradle in your project (the module-level file, not the top-level one). On iOS, Podfile lives in the project root next to your .xcodeproj. Paste the full dependencies block. Comments are fine. Version variables like ${admobVersion} cannot be resolved by the tool, so paste the resolved versions if your build uses them.
What do the severity tiers mean?
Current: you are on the latest published version. Behind by a release or two: not urgent, but worth scheduling. Deprecated: package is no longer maintained or the path forward is a different package. Critical known issue: this exact version triggers a documented crash, init failure, or Privacy Manifest violation. The tool links to the source of every critical finding so you can read the original issue thread.
How often does the data update?
A GitHub Actions workflow refreshes the version database every Sunday at 02:00 UTC by fetching AppLovin's public adapter changelogs (Android and iOS), Google Maven for AdMob package versions, and direct vendor GitHub releases for non-AppLovin-tracked SDKs. The hand-curated known-issues layer is updated as we encounter new operator pain points.
Do you store my dependency text or send it anywhere?
No. The check runs server-side, but we do not log the full input, persist it, or send it to third parties. Only the first 200 characters of the input are echoed back in the response for context. No accounts, no tracking of dependency contents.
Related reading
- Mediation SDK and Adapter Compatibility Guide. The full operator guide that backs every check above.
- AppLovin MAX vs Unity LevelPlay. Once you have settled on AppLovin MAX, this is the comparison that drives the next decision.
- AdMob Mediation vs AppLovin MAX. The decision framework for upgrading from default AdMob mediation to MAX.
- AdMob Approval Checker. Pre-submission audit for app developers preparing to apply to AdMob.
SDK versions are one piece. Is the rest of your stack tuned?
SDK and adapter compatibility is one layer. If you're running mediation and you're not sure your waterfall, floor prices, or demand partner mix are actually optimized, that's a separate question.
I help app developers find where revenue is leaking in their mediation setup. The first conversation is free.
Best for apps generating $10K or more a month in ad revenue.
Book a Free 30-Min CallAdvisory only. Output is a starting point, not a substitute for testing in a real build. Versions and known issues change between weekly refreshes. Always verify against the vendor's official documentation, GitHub, or release notes before integrating. We do not store the contents you submit. See the terms and privacy policy.