AI & TechnologyGoogle Mobile Ads SDK Sunset Dates and Versions 2027

Google's Mobile Ads SDK timetables list the following sunset dates: on Android, v23.x.x on June 30, 2027 and v24.x.x and v25.x.x on June 30, 2028; on iOS, v11.x.x in Q2 2027, v12.x.x in Q2 2028 and v13.x.x in Q2 2029. The iOS dates are quarters only, and Google says a more specific v11 date will come with two months' notice. At sunset, Google says ad requests return a no fill with an error saying the version is sunset, so the app keeps running but earns nothing from that placement. If you ship AdMob in a native or Flutter app, find your SDK version now and update well before the date.

I checked Google's pages on October 19, 2026. Both deprecation pages show "Last updated 2026-10-16 UTC". Google can change a date, so open the linked page before you plan around it.

Disclosure: App369 is my studio. I build and fix Flutter and Firebase apps, and the last section mentions what I sell. Google doesn't pay me for anything on this page.

The dated table

These are the rows exactly as Google's timetables state them, with the status column as shown on October 19, 2026.

Sources: Android timetable, iOS timetable.

A few things to read carefully:

• Quarters, not dates. For iOS v11, v12 and v13, Google gives a quarter for the sunset. Footnote 1 says: "A more specific sunset date will be announced on the Google Ads Developer blog and updated on this page with two months' notice." I can't tell you which day in Q2 2027 it is, because Google hasn't said.
• iOS v10. The table still lists v10.x.x as "Deprecated" although its June 30, 2026 sunset date has passed. Treat it as already sunset and leave it.
• Dates can move. Both pages say a version may be sunset earlier than the schedule, with advance communication.
• The lifecycle rule. Both pages say a major version is generally supported for about two years, deprecated for one more year, then sunset. When version N ships, N-2 becomes deprecated immediately and N-3 sunsets about two months later. The iOS page says Google plans one major release per year, in Q1.

What sunset means

Google's pages define three states.

• Supported: ads serve, and technical support is available.
• Deprecated: ads still serve, but technical support is limited (Android) or no longer provided (iOS). You may be asked to reproduce issues on a supported version.
• Sunset: ads are at risk of not serving. When Google disables ad serving for a version, ad requests return a no fill with an error indicating that the version is sunset. Google says it disables serving gradually, starting with the oldest, lowest-usage versions.

So sunset is not a guaranteed switch-off on the date. It is the point where Google may turn your version off at any time, and there is no notice I could find for a given app. When it happens, your app does not crash because of Google. The ad slot just fails to fill, and your code sees a failed ad load. If you handle that as a normal failure, you will see empty ad spots and falling revenue, not an error screen. I have not tested the exact error string, so check your own logs for it.

My advice: do not plan around the sunset date. Plan around deprecation, when support ends. A version in the Deprecated row is already the one to move off.

How to check which version you ship

The version lives in your dependency line. I did not find an official command to print it, so I'd read the files below and then confirm in a release build.

Android (Gradle). Google's quick start shows the dependency as implementation("com.google.android.gms:play-services-ads:25.5.0"), with the Groovy form implementation 'com.google.android.gms:play-services-ads:25.5.0'. To update, change the version number and sync. The page says the Android SDK needs a minimum SDK version of 24 or higher, and a compile SDK version of 35 or higher. The migration page says the firebase-ads and firebase-ads-lite artifacts are no longer distributed from 24.0.0.

iOS (CocoaPods). Google's quick start line is pod 'Google-Mobile-Ads-SDK', followed by pod install --repo-update. Check Podfile.lock to see the resolved version.

iOS (Swift Package Manager). Add the package in Xcode from https://github.com/googleads/swift-package-manager-google-mobile-ads.git. For new projects the page recommends "Up to Next Major Version". The page says to use Xcode 16.0 or higher and target iOS 13.0 or higher, and that Xcode 27 requires a minimum deployment target of iOS 15.0, so CocoaPods builds need a post_install hook that sets IPHONEOS_DEPLOYMENT_TARGET to 15.0. For the Xcode side of that, see my iOS 27 SDK guide.

Flutter (pubspec.yaml). The plugin is the google_mobile_ads package, and pub.dev lists 9.1.0 as the latest, installed with google_mobile_ads: ^9.1.0. In Flutter you don't set the native version directly. The plugin pulls it in, so you read the version from pubspec.lock and look it up in the plugin changelog below.

My advice: check all three files, not just one. A Flutter app has the plugin version in pubspec.lock, but the resolved native version also lands in android/ and ios/ build output. Confirm the native number there before you trust the plugin number.

The Flutter plugin and native SDK versions

Google's Flutter quick start lists Flutter 3.38.1 or higher as a prerequisite. It does not say which native SDK versions are bundled. The pub.dev changelog does, release by release. Here are the lines I read that name a native version:

Read against the timetables above, that gives you a rough guide for a Flutter app:

• Plugin 5.x lines up with Android v23 and iOS v11, the two majors whose sunsets Google lists as June 30, 2027 and Q2 2027.
• Plugin 4.0.0 lines up with Android v22, whose sunset in the table has passed, and iOS v10.
• Plugin 6.0.0 and 7.0.0 line up with Android v24 and iOS v12. Plugin 8.0.0, 9.0.0 and 9.1.0 line up with Android v25 and iOS v13.

The changelog lists the Android Next-Gen SDK too: 9.1.0 shows "Google Mobile Ads Next-Gen SDK version 1.3.1" and 9.0.0 shows 1.1.0. It does not say whether the plugin uses it instead of, or beside, the legacy SDK, so I can't tell you.

What I could not confirm: whether the plugin has its own support or sunset policy, and whether older plugin versions stop working at the native sunset dates. I take that to follow from the native SDK, because the plugin wraps it, but no Flutter page I fetched says so.

Updating

Google's Android and iOS migration pages are written as jumps from one major to the next. Read the page for each jump you make.

• Android to v25. Starting in v25.5.0, "Google Mobile Ads SDK (Legacy) requires all apps to run on a minimum Android API level 24." It removes the onFailure(String) and onAdFailedToShow(String) callbacks in favor of the AdError overloads, and it replaces the anchored adaptive banner methods with "Large" variants. com.google.android.gms.ads.mediation.VersionInfo is removed in favor of com.google.android.gms.ads.VersionInfo.
• iOS to v13. The minimum deployment target rises to iOS 13, and the anchored adaptive banner functions are replaced by "Large" variants. neighboringContentURLStrings now raises an exception if the array contains an item that isn't a String.
• GMA Next-Gen SDK (Android). Google's Next-Gen page shows implementation("com.google.android.libraries.ads.mobile.sdk:ads-mobile-sdk:1.5.0") and says it needs minSdk 24 and compileSdk 34 or higher. It requires initialization before you load ads, which was optional in the legacy SDK. The page covers Android only.
• Mediation. The Next-Gen page says: "Mediation adapters continue to depend on Google Mobile Ads SDK (Legacy)," and that you must exclude the legacy play-services-ads and play-services-ads-lite modules to avoid duplicate-symbol errors. The deprecation tables themselves say nothing about adapters.

I would not take the Next-Gen path unless you have a reason. The Android table lists v25 as Supported to June 30, 2028, and updating to v25 is a smaller change. That is my call, not Google's, and the Android page does tell you to migrate to Next-Gen.

My advice: do the update in one pull request, with only that change in it. Build a release, test an ad of each format you use on a real device, and watch the first week of fill rate in AdMob before you ship the next feature on top.

A short plan

1. Find your versions. Read build.gradle, Podfile.lock or your SPM resolution, and pubspec.lock.
2. Find the row. Match each version to the table. Any Deprecated row is your priority. Any Sunset row is already at risk.
3. Pick the target. Android v25 or the Next-Gen SDK. iOS v13. For Flutter, the latest plugin whose changelog names those versions.
4. Read the migration page for every major you skip, and note any minimum OS change.
5. Check mediation. If you use adapters, check each network's own pages. Google's deprecation pages say nothing about them.
6. Test a release build with real ads, on a real device, before you submit.

For every other dated Apple, Google Play and Firebase requirement in 2026 and 2027, see App Store and Google Play deadlines for 2026 and 2027.

Need a hand?

If your Flutter app still ships an old AdMob SDK and you want it updated before Google switches it off, the App Fix Ticket covers it in two fixed-price steps. A $450 Diagnosis gives you the root cause with evidence and a fixed repair quote within 3 business days, credited toward the fix. If you go ahead, the $1,200 Fix takes 5 business days and comes as a pull request. Or send me a short description.