Version 12.0.0 of the Google Mobile Ads SDK is now available. We recommend upgrading as soon as possible to get our latest features and performance improvements.

Updated Swift APIs

We’ve updated the Google Mobile Ads SDK to define an NS_SWIFT_NAME for every API to follow the naming conventions from Apple’s Swift API Design Guidelines. For example, we have:

Version 12.0.0 of the Google Mobile Ads SDK is now available. We recommend upgrading as soon as possible to get our latest features and performance improvements.

Updated Swift APIs

We’ve updated the Google Mobile Ads SDK to define an NS_SWIFT_NAME for every API to follow the naming conventions from Apple’s Swift API Design Guidelines. For example, we have:

  • Removed the GAD prefix across names for all types.
  • Renamed the GAM prefix to AdManager.
  • Renamed the GADM prefix to Mediation.

For the full list of Swift API name changes, see Swift naming support.

Swift 6 Concurrency

Swift 6 concurrency support is being rolled out incrementally, starting this release with added support for our ad format delegate methods. Future SDK versions will include further improvements.

Changes to Xcode requirements

The minimum supported Xcode version has been bumped to 16.0.

For the full list of changes, check the release notes. Check our migration guide to ensure your mobile apps are ready to upgrade.

SDK Deprecation Reminder

Per the deprecation schedule, the release of version 12.0.0 means that:

  • iOS Google Mobile Ads SDK versions 10.x.x are officially deprecated, and will sunset in Q2 2026.
  • Versions 9.x.x and below will sunset on June 30, 2025.
    • While there are currently no plans to disable ad serving on version 9.x.x, we strongly recommend updating to a supported SDK version to avoid being impacted in the future.

As always, if you have any questions or need additional help, contact us via the developer forum.

We are pleased to announce the launch of the Google Ads API Research Group. As a Developer Relations team, we want to ensure your voice is not only heard, but that your suggestions are incorporated into product decisions. Our goal is to turn your feedback into real improvements to the Google Ads API developer experience.

We are pleased to announce the launch of the Google Ads API Research Group. As a Developer Relations team, we want to ensure your voice is not only heard, but that your suggestions are incorporated into product decisions. Our goal is to turn your feedback into real improvements to the Google Ads API developer experience.

As a member of the research group, we'll invite you to participate in user research opportunities, such as surveys and usability studies. These opportunities let you voice your opinions and ideas about the Google Ads API, inform product design and prioritization, and ultimately shape the Google Ads API developer experience.

To sign up for the Google Ads API Research Group, fill out the opt-in form. This form takes about 5 minutes to complete. We are deeply committed to improving developer experience and appreciate your feedback.

Starting on March 3, 2025, the Google Ads API and Google Ads scripts search term insight reports will return all search subcategories as empty. The Google Ads UI already removed this field, and the API is also rolling out this change to be consistent across Google Ads.

Starting on March 3, 2025, the Google Ads API and Google Ads scripts search term insight reports will return all search subcategories as empty. The Google Ads UI already removed this field, and the API is also rolling out this change to be consistent across Google Ads.

What do I need to do?

Starting March 3, 2025, it is expected that all values for segments.search_subcategory will be empty.

If you query segments.search_subcategory in the campaign_search_term_insight or customer_search_term_insight reports, then:

  1. Check that your code can handle an empty value in segments.search_subcategory. An empty string already is a catch-all, so your code should be already handling this.
  2. We recommend removing segments.search_subcategory from your query.

If you have any questions or concerns, you can reach out to us through our support form.

The IMA DAI SDK now supports passing the network code parameter when creating a full-service stream request. This change is specifically for IMA DAI integrations using either LiveStreamRequest or VODStreamRequest classes. Adding the network code is a one-time change that enables IMA DAI to respect your Ad Manager settings.

The IMA DAI SDK now supports passing the network code parameter when creating a full-service stream request. This change is specifically for IMA DAI integrations using either LiveStreamRequest or VODStreamRequest classes. Adding the network code is a one-time change that enables IMA DAI to respect your Ad Manager settings.

We recommend you provide the network code for IMA to apply your Ad Manager settings to the stream request. For example, if you turn off programmatic limited ads in Ad Manager, use the Google Ad Manager network code parameter to ensure local storage is also disabled for limited ads in DAI on your app.

The following example constructs an IMA DAI HTML5 LiveStreamRequest class with the network code in the request to Ad Manager:

function requestLiveStream(assetKey, apiKey, networkCode) {
  var streamRequest = new google.ima.dai.api.LiveStreamRequest();
  streamRequest.assetKey = assetKey;
  streamRequest.apiKey = apiKey;
  streamRequest.networkCode = networkCode;
  streamManager.requestStream(streamRequest);
}

You can pass the network code using the IMA DAI SDK for full-service DAI on all of the platforms:

For more information, see the programmatic limited ads Ad Manager article. Additionally, follow Find your Ad Manager network code. If you have any questions, feel free to reach out using the IMA technical forum.

As part of our goal of aligning more closely with industry standards, we previously announced the sunset of the Authorized Buyers Real-time bidding protocol on February 15th, 2025. After the deprecation period, OpenRTB will be the only supported protocol for Authorized Buyers, Open Bidding, and SDK Bidding. Since the announcement, we have worked closely with migrating partners to provide guidance and technical assistance, as well as an A/B experimentation framework.

As part of our goal of aligning more closely with industry standards, we previously announced the sunset of the Authorized Buyers Real-time bidding protocol on February 15th, 2025. After the deprecation period, OpenRTB will be the only supported protocol for Authorized Buyers, Open Bidding, and SDK Bidding. Since the announcement, we have worked closely with migrating partners to provide guidance and technical assistance, as well as an A/B experimentation framework.

We have seen a lot of enthusiasm and progress from many partners migrating to OpenRTB, as well as significant improvements in bidding performance for a number of partners compared to Google RTB integrations. However, to provide additional support and further optimize bidding integrations with the OpenRTB protocol, we have decided to extend the Authorized Buyers Real-time Bidding protocol's deprecation period.

The sunset date is now April 30th, 2025. Following this date, bid requests will no longer be sent with the Authorized Buyers Real-time bidding protocol, and the only supported protocol will be OpenRTB.

If you have any questions about how OpenRTB differs from Authorized Buyers Real-time Bidding protocol, we recommend that you reference the OpenRTB migration guide. If you have other questions or feedback concerning your migration, feel free to contact us using the Authorized Buyers support forum, or adxbuyerapi-support@google.com.

Google Ads API v16 will sunset on February 5, 2025. After this date, all v16 API requests will begin to fail. Migrate to a newer version prior to February 5, 2025 to ensure your API access is unaffected.
Google Ads API v16 will sunset on February 5, 2025. After this date, all v16 API requests will begin to fail. Migrate to a newer version prior to February 5, 2025 to ensure your API access is unaffected.

Here are some resources to help you with the migration: You can view a list of methods and services your project has recently called using the Google Cloud Console:
  1. Open the APIs & Services in the Google Cloud Console.
  2. Click Google Ads API in the table.
  3. On the METRICS subtab, you should see your recent requests plotted on each graph. You can see which methods you've sent requests to in the Methods table. The method name includes a Google Ads API version, a service, and a method name, such as google.ads.googleads.v18.services.GoogleAdsService.Mutate.
  4. (Optional) Choose the timeframe you want to view for your requests.
If you have questions while you’re upgrading, reach out to us on the forum or at googleadsapi-support@google.com.

Ad inspector is an in-app overlay that enables authorized devices to perform real-time analysis of Google Mobile Ads SDK test ad requests directly within your mobile app. It is included with the Google Mobile Ads SDK and you can enable it with no coding required.

Ad inspector is an in-app overlay that enables authorized devices to perform real-time analysis of Google Mobile Ads SDK test ad requests directly within your mobile app. It is included with the Google Mobile Ads SDK and you can enable it with no coding required.

Ad inspector empowers you to thoroughly test all your ad sources before releasing those changes to your users so you can verify everything is working properly. To help you understand and utilize ad inspector effectively, we published a 7-part ad inspector video series on our Google AdMob YouTube channel.

Each video focuses on a specific challenge in testing your ad integration, offering in-depth tutorials and demonstrations on how to:

Check out our ad inspector documentation (Android, iOS, Unity, Flutter) to learn more. If you have questions, comments, or general feedback about ad inspector, contact us in the developer forum. And remember to subscribe to our Google AdMob YouTube channel for more technical content.