The Google Mobile Ads API Demo apps for Android and iOS are now available. These new apps contain advanced examples for both AdMob and DoubleClick for Publishers (DFP) that demonstrate features of the Google Mobile Ads SDK that can help you improve the user experience and maximize ad revenue. Whether you’re a new publisher or a seasoned veteran of the SDK, the API Demo apps showcase new ways to customize ad requests, experiment with multiple ad sizes, and compare AdMob and DFP technologies.

Download the API Demo apps for Android and iOS today and explore new ways to improve your integration with the Google Mobile Ads SDK!

If you have any questions regarding the new API Demo apps, feel free to contact us through our forum.

 - Tristan Emrich, Mobile Ads Developer Relations

The rollout of iOS 9 is expected to come this Fall and will introduce a new privacy feature called App Transport Security (ATS) to enforce best practices in secure connections between an app and its back end. This change may need your action if you are developing with the Google Mobile Ads SDK and building an app against the iOS 9 SDK.

We recommend using HTTPS exclusively if you’re developing a new app. If you’re working on an existing app, we suggest using HTTPS as much as possible and creating a plan to migrate the rest of your app toward ATS compliance.

All iOS 9 devices running apps built with Xcode 7 that don’t disable ATS will be affected by this change. The following log message appears when a non-ATS compliant app attempts to serve an ad via HTTP on iOS 9:

“App Transport Security has blocked a cleartext HTTP (http://) resource load since it is insecure. Temporary exceptions can be configured via your app’s Info.plist file.”

While Google remains committed to industry-wide adoption of HTTPS, there isn’t always full compliance on third party ad networks and custom creative code served via our systems. To ensure ads continue to serve on iOS9 devices for developers transitioning to HTTPS, the recommended short term fix is to add an exception that allows HTTP requests to succeed and non-secure content to load successfully.

Publishers can add an exception to their Info.plist to allow any insecure connection:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

If you have any questions regarding these changes, feel free to contact us through our forum.

Update (8/27/2015): We've received important feedback about this post and wanted to clarify a few points. We wrote this because developers asked us about resources available to them for the upcoming iOS 9 release, and we wanted to outline some options. To be clear, developers should only consider disabling ATS if other approaches to comply with ATS standards are unsuccessful. Apple has provided a tech note describing different approaches, including the ability to selectively enable ATS for a list of provided HTTPS sites.

We’ve strongly advocated for HTTPS protection for many years and we continue to roll it out across our products.

 - Tristan Emrich, Mobile Ads Developer Relations

In response to the growing popularity of Swift development, we’ve added Swift samples for the Google Mobile Ads SDK to our GitHub repo. To make it easier for developers to get started using Swift, we’ve also added Swift code snippets to our Get Started and Interstitial guides.

If you have any questions about using Swift with the Google Mobile Ads SDK, you can reach us on our forum. Remember that you can also find us on Google+, where we post updates on all of our Google Ads developer products.

 - Ram Parameswaran, Mobile Ads Developer Relations

Today we’re announcing two new versions of the Google Mobile Ads SDK: version 7.8 for Android, and version 7.4.1 for iOS. Those of you using Android Studio can download Google Repository (Rev. 20) to get the latest Gradle artifacts. Eclipse developers will find it listed as Google Play services (Rev. 26) in the Android SDK manager. Publishers with iOS apps can get the latest SDK for that platform by updating their CocoaPods Podfile to pull version 7.4.1 or by downloading it manually. These releases contain a number of stability and performance improvements, as well as some new features — including beta support for MRAID v2.0 on iOS and Android!

MRAID v2.0 Beta

MRAID v2.0 offers a number of new methods that advertisers can use to improve their creatives. Ads using the new standard can store photos, resize themselves on the fly, query screen dimensions, and make calendar events using calls like this:

mraid.createCalendarEvent({
    description: “A big sale at our store!”,
    location: ‘123 Savings Street’,
    start: ‘2015-9-01T09:00-05:00’, 
    end: ‘2012-12-22T10:00-05:00’
});

The new standard creates some great opportunities for increased engagement, so for more info about MRAID, see our iOS MRAID guide, our Android MRAID guide, or the IAB’s specifications document.

Checking ad loading status on Android

In the new Android release, we’ve added an isLoading method to the AdLoader, AdView, and InterstitialAd classes so publishers can check whether an ad request is in progress. If you’re using an AdLoader to fetch a native ad, for example, you can use a call like this to see if the request has completed:

if (!myAdLoader.isLoading()) {
    /* The AdLoader isn’t busy making a request. */
    myAdLoader.loadAd(new AdRequest.Builder().build());;
}

iOS global settings

This SDK release introduces the GADMobileAds class, which provides global settings for controlling certain information collected by the SDK. In-app purchase reporting and crash reporting are enabled by default. However, if you’d like, you can disable these settings in most instances by using the disableAutomatedInAppPurchaseReporting and disableSDKCrashReporting methods. See the global settings guide for more information.

For a full list of Mobile Ads SDK changes, check out our release notes. For technical questions, post them on our forum.

 - Andrew Brogdon, Mobile Ads Developer Relations

Last week, we released beta version 15 of the IMA SDK for iOS. This release includes two new features:

• Ad buffer events via IMAAdsManager delegates
• Debugging mode

Ad buffer events

We’re providing more information on ad buffering by introducing new buffering events via the following optional IMAAdsManagerDelegate methods:

• adsManagerAdPlaybackReady:
• adsManagerAdDidStartBuffering:
• adsManager:adDidBufferToMediaTime:

Collectively, these delegate methods provide more transparency into buffer events, giving you more control over the user’s ad experience. For more detailed information on these new methods, take a look at the reference documentation.

Debugging mode

We’ve introduced a new debugging mode setting to allow for more verbose logging to the console. You can now set IMASettings.enableDebugMode to YES to enable debug mode. This should not be used in production, as it will show a watermark on the ad player.

A note about CocoaPods

If you’re using CocoaPods with the IMA SDK, please make sure to use at least version 0.38.

As always, if you have any questions, feel free to contact us via the support forum.

 - Yury Pavlotsky, IMA SDK Team

Today we’re announcing the availability of three new reporting dimensions created specifically for AdMob publishers: APP_ID, APP_NAME, and APP_PLATFORM.

Here’s how they work:

• APP_ID - This dimension matches the store ID of an application. It will be prefixed with “1:” for an App Store ID (iOS) and “2:” for a Google Play ID (Android). For example, “1:476954712” or “2:com.labpixies.lineup”.
• APP_NAME - Matches the name of an application, like “Flood-It!” or “Line Up”.
• APP_PLATFORM - This dimension can partition results by platform (e.g. “Android” or “iOS”).

These new dimensions are available now in the AdSense Management API. If you’re unfamiliar with it, the AdSense Management API is a web-based API that you can query to get information about your AdSense account. There are client libraries for a number of platforms, though any standard HTTP client can send requests to it and parse the responses. With a little code and these new dimensions, you can create custom reports about a single app, a family of them, or even your entire platform lineup!

For more information on building and customizing AdMob reports, check out the reporting section of the AdMob developer site. You can also use the API Explorer to test out queries that include these fields.

 - Andrew Brogdon, Mobile Ads Developer Relations

We’re excited to announce the addition of Swift samples to the IMA SDK! To view these samples check out our GitHub repo. Along with these new samples we’ve also added Swift snippets to our quick start guide.

As always, if you have any questions feel free to contact us via the support forum.

 - Shawn Busolits, IMA SDK Team

Today we’re pleased to announce two new versions of the Google Mobile Ads SDK: version 7.5 for Android, and version 7.3.1 for iOS. Included is a brand new way to monetize your apps with the Google Mobile Ads SDK: native ads!

With native ads, publishers can display ad assets directly in native views, using layouts and storyboards they design to fit their user experience. You now have the power to monetize with ads that are seamless with content!

Native ads are currently in a beta with a limited group of publishers, but the code is included in the latest releases of the Mobile Ads SDK for iOS and Android. Those of you using Android Studio can download Google Repository (Rev. 19) via the Android SDK Manager to get the latest Gradle artifacts, and developers with Eclipse projects can find it listed as Google Play services (Rev. 25). Publishers with iOS apps can snag the latest SDK for that platform by updating their Podfile to pull version 7.3.1.

For AdMob, DFP, and AdX publishers, there are two system-defined native ad formats: App Install and Content. Each provides a set of image and string assets that make up the ad. App Install ads contain assets named “price,” “star rating,” and so on, while Content ads have “body,” “logo,” and others. See the AdMob and DFP help center articles for more information about the formats.

Publishers using DFP can also take advantage of custom native ad formats. With a custom format, you can create your own set of asset definitions, and then upload creatives with a matching set of values.

Native ads are loaded using the new AdLoader and GADAdLoader classes, which can request a single format or several at the same time, helping you maximize the value of your impressions. Here’s an example showing how to request an App Install ad on Android:

AdLoader adLoader = new AdLoader.Builder(this, DFP_AD_UNIT_ID)
        .forAppInstallAd(new NativeAppInstallAd.OnAppInstallAdLoadedListener() {
            @Override
            public void onAppInstallAdLoaded(NativeAppInstallAd ad) {
                /* display the ad */
            }
        }).build();
adLoader.loadAd(new AdRequest.Builder().build());

And here’s the iOS equivalent:

self.adLoader = [[GADAdLoader alloc]
                   initWithAdUnitID:DFP_AD_UNIT_ID
                 rootViewController:rootViewController
                            adTypes:@[ kGADAdLoaderAdTypeNativeAppInstall ]
                            options:nil];
self.adLoader.delegate = self;
[self.adLoader loadRequest:[GADRequest request]];

Check out the native ads guide (Android | iOS) for more information about native ads. For a full list of Mobile Ads SDK changes, check out our release notes. For technical questions, post them on our forum.

 - Andrew Brogdon, Mobile Ads Developer Relations

Today we’re announcing the release of beta version 13 of the IMA SDK for iOS. This release includes two new major features:

1. The SDK can be included as a framework in your project.
2. The SDK now supports ad playing in the background.

Importing the SDK as a Framework

Prior to today’s release, importing the SDK involved manually adding every header file to your project, importing every header file individually in your source, and manually including the required frameworks. With the new framework model, you can add a single .framework file to your app and replace all of your header import source lines with a single import statement.

For CocoaPods Users

If you use CocoaPods, your build will fail after you update to beta 13. But fear not, you can fix this in a matter of seconds with the following steps:

1. Locate and remove each instance of an imported IMA header file in your source (these will look like #import “IMA<something>.h”).
2. Add the following line to the first header or implementation file to access an IMA object:

   @import GoogleInteractiveMediaAds;

For Manual Importers

If you don’t use Cocoapods, your path to upgrade is slightly different. You can update using the following steps:

1. Remove all of the IMA header files and the IMA library file from your project.
2. Under "Build Phases” > “Link Binary With Libraries”, click the plus sign, select “Add Other...”, and navigate to the downloaded and extracted SDK files. Select GoogleInteractiveMediaAds.framework from whichever folder applies to your implementation (with or without AdMob) and click “Open”.
3. Follow the two steps above for CocoaPods users.

Background Ad Playback

Since our launch, one of the most requested features has been background ad playback. Suppose, for example, you author a music streaming app, and you want to be able to request and play ads in the background. With today’s release, however, we now support requesting and playing ads in a background service. For more info and implementation instructions, see our Background Ad Playback guide.

As always, if you have any questions feel free to contact us via the support forum.

 - Shawn Busolits, IMA SDK Team

When announcing version 7.0.0 of the Google Mobile Ads SDK for iOS, we mentioned that developers could roadblock creatives and prevent competing ads in mobile apps.

The launch of the roadblocks feature in version 7.0.0 had an unintended side effect for DFP reservations. By default, ad requests from the same device were getting frequency capped for 30 seconds unless the app called the updateCorrelator method between requests.

To restore the default behavior, we have rolled back the roadblocks feature. What this means is that updateCorrelator effectively does nothing in version 7.0.0. We will relaunch support for roadblocks and competitive exclusions in a future iOS SDK release after improving the feature to preserve the default behavior.

If you have any questions about this change, leave us a note on the forum.

 - Eric Leichtenschlag, Mobile Ads Developer Relations

Today we’re releasing v7.0.0 of the Google Mobile Ads SDK for iOS. For this release, we focused on making the SDK easier to use, including distributing it as a framework. We’re also showing our DFP publishers some love by launching new first-class APIs to support the common DFP features they’re already using with Google Publisher Tag. A detailed list of these and other changes can be found on our release notes page.

SDK as a framework

The SDK is being distributed as a framework in this release. This comes with the following benefits:

• You only have to add one item to your project. No more worrying about adding headers separately!
• The SDK automatically links frameworks it depends on. No more manually adding framework dependencies!
• Classes that use the SDK can now automatically import the necessary headers files with a single line of code:

  @import GoogleMobileAds;

  Previously, you had to import header files separately.

  #import "GADBannerView.h"
  #import "GADBannerViewDelegate.h"
  #import "GADRequest.h"
  

If all that wasn’t awesome enough, we also removed the need to include the -ObjC linker flag in your project! Just drag in the library to start using it.

If you’re using CocoaPods, you automatically get all of these changes by referencing version 7.0.0 of the Google-Mobile-Ads-SDK podspec. Since this is a major release, make sure you update your Podfile to grab major version 7:

pod 'Google-Mobile-Ads-SDK', '~> 7.0'

Introducing new friendly DFP APIs

Version 7.0.0 also adds first-class support for custom targeting and category exclusions in a brand new DFPRequest object.

DFPRequest *request = [DFPRequest request];
request.customTargeting = @{
  @"gender", @"male"
};
request.categoryExclusions = @[@"cars", @"sports", @"pets"];

New to 7.0.0 is the ability to roadblock creatives and prevent competing ads in mobile apps. The SDK does this by adding an updateCorrelator method with similar functionality to the same method in GPT:

[DFPRequest updateCorrelator];

All subsequent DFP ad requests will use the new correlator value until the correlator is updated again. Requests with the same correlator are capable of being roadblocked, and will not serve competing ads.

For more information on the DFP API improvements, see the developer docs.

Dropping support for iOS 5

With this release, we are also dropping support for iOS 5. We’ve noticed that almost all users are running iOS 6 or higher, and dropping support for older versions means the library can take advantage of the newer iOS APIs and offer more stability for you and your users. The SDK now supports only iOS 6.0 and up.

Sounds great! Where can I download the SDK?

As always, the latest SDK can be found on our downloads page. If you have any technical questions about these updates, drop us a line on the forum.

 - Eric Leichtenschlag, Mobile Ads Developer Relations

As you know, interstitials are a great way to monetize your app while still providing a great user experience, with natural "commercial breaks" in your user flow. However, interstitials can take a while to load, and we know that this can make it tricky to implement since you must explicitly call loadAd() before calling show().

A common mistake is to call interstitial.show() in the onAdLoaded() callback. This makes the show() call not dependent on the app state, but on the asynchronous loading. Since the developer doesn't control when the onAdLoaded() callback happens, this provides a terrible user experience; the ad will show as soon as it's finished loading, which could be in the middle of another user interaction. This can result in policy violations due to accidental clicks.

Instead, we recommend loading the ad earlier in the lifecycle of the application, then polling interstitial.isLoaded() to see if the ad is ready to be shown. If it isn't ready, we recommend moving to the next state in the application.

We provide an example of proper interstitial loading in our sample "Impossible" game. When the game begins, we call loadAd() on the interstitial. When the user loses and clicks the button to try the game again, we check to see if the ad is loaded with isLoaded(). If it is, then we show an ad before starting the new round. Otherwise, we show a toast message that the ad isn't loaded and begin a new round.

This example focuses on the Android experience, but the same ideas apply to iOS. We hope our new interstitial example can help you create the best user experience as you integrate the Mobile Ads SDK into your apps. Check out this video for more on interstitial best practices. And as you're adding interstitials to your app, hit us up with technical questions on our developer forum!

 - Amy Quispe, Mobile Ads Developer Relations

Today, we’re happy to announce the launch of Google Mobile Ads SDK v6.12.0 with support for iOS 8. Specifically, it includes the following iOS 8 updates:

• Less time is spent on the main thread while loading ads
• Smart Banner ads are displayed correctly in landscape

New Framework Dependencies

Version 6.12.0 also requires that your app link to two additional frameworks:

• EventKit
• EventKitUI

If you’re using CocoaPods, simply run pod update to grab the update, and these new frameworks will be automatically linked for you. If you’re not using Cocoapods, the getting started guide has the full list of required frameworks.

See the release notes for a full list of updates. You can grab the latest SDK from the downloads page. If you have any technical questions about the new release, post them on the developer forum. Also follow our Google+ page to keep abreast of the latest developments for the Mobile Ads SDK.

 - Eric Leichtenschlag, Mobile Ads Developer Relations

When you make an ad request using the Google Mobile Ads SDK, you’re probably setting an AdListener or GADBannerViewDelegate to listen for ad events. The click events for these listeners are slightly different on Android and iOS, so today we’ll take a deeper look at what events get invoked when an ad click:

• opens an overlay, for example an in-app browser
• launches an external application, for example an external browser or app store

Ad Opens an Overlay

Here are the ad events that get called when an ad opens an overlay:

Event	Android Callback(s)	iOS Callback(s)
Ad Opens Overlay	onAdOpened	adViewWillPresentScreen
Ad Overlay is Closed	onAdClosed	adViewWillDismissScreen adViewDidDismissScreen

These events are pretty straightforward. When the ad overlay opens, you get a single callback. When the ad overlay closes, Android notifies you the moment the event happens, while iOS notifies you right before and after the event happens.

Ad Launches an External Application

When an ad launches an external application, the ad events are slightly different:

Event	Android Callback(s)	iOS Callback(s)
Ad Launches External App	onAdOpened onAdLeftApplication	adViewWillLeaveApplication
User relaunches App	onAdClosed	-----

Notice how on Android you still get the onAdOpened and onAdClosed events even if an ad leaves an application. But on iOS, the adViewWillPresentScreen and adViewWillDismissScreen/adViewDidDismissScreen events are only invoked when presenting and dismissing modal views.

So how do you know when the user returns to your iOS app? You can listen for the applicationWillEnterForeground delegate method that iOS provides.

Testing The Different Click Behaviors

Hopefully you’re already requesting test ads during application development. If you’re making test requests, you should already see these ads showing up in your development environment:

On iOS, you can use these ads to test both ad click behaviors. If you click the banner, the Google Mobile Ads SDK will launch an external web browser and call adViewWillLeaveApplication. If you click the icon in the bottom-left corner of the ad, the SDK will launch an overlay and adViewWillPresentScreen will get called.

Hopefully this clears up any confusion regarding any ad click events. If you have any additional questions, we’ll field them on our forum. You can also find us on Google+.

 - Eric Leichtenschlag, Mobile Ads Developer Relations

Today, we’re excited to announce a new release to both our Android and iOS Google Mobile Ads SDKs. The key new features added in these releases are in-app purchase ads for both platforms and new mediation APIs for Android.

In-App Purchase Ads

In this release we’ve added SDK-level support (front-end support coming soon!) for running house ads that can initiate an in-app purchase. In-app purchase ads require that you set an in-app purchase listener on your interstitial ad. If an in-app purchase ad is shown, it will present the user with an option to buy one or more items that you have configured:

When the user clicks Buy now, the SDK will invoke your in-app purchase listener with the purchase information necessary to start a transaction for that product. You are responsible for implementing the in-app purchase flow from this point. Full implementation details can be found in our Android and iOS documentation.

Note: Front-end support for this feature is not available yet, but is coming soon.

New Mediation APIs

As part of our Google Play services API revamp, we’ve added new mediation APIs (which we’re calling mediation v2) to make it easier for ad networks to create mediation adapters.

Don’t worry! We’re still supporting mediation adapters written against mediation v1 APIs. This change won’t require any immediate updates to your apps.

If you previously passed extra parameters to third party networks, note that this process has changed for mediation v2. You’ll now pass a bundle to the ad network, keyed by its mediation v2 adapter class. Here is an example of passing extra parameters to AdMob:

Bundle adMobBundle = new Bundle();
adMobBundle.putString("color_bg", "AAAAFF");
AdRequest request = new AdRequest.Builder()
    .addNetworkExtrasBundle(AdMobAdapter.class, adMobBundle)
    .build();

You can also use this snippet to check for the existence of mediation v2 support. If this snippet compiles, then the adapter supports mediation v2. If there is a compilation error saying that the arguments don’t match the arguments for addNetworkExtrasBundle(Class, Bundle), then that adapter class does not support mediation v2.

See the documentation for more information on passing parameters to mediation v2.

Dropped Support for iOS 4.3

The 6.9.2 iOS SDK release has dropped support for iOS 4.3. By dropping iOS 4.3, the SDK can take advantage of automatic reference counting (ARC) weak references to provide a more stable release. The SDK still supports iOS 5.0 and above.

Check out the downloads page to grab the latest iOS release. A new Google Play services revision will soon be available in Android’s SDK Manager.

For a full list of SDK changes, see the release notes. If you have any technical questions about these changes, we’re available on the forum. Finally, stay tuned for an update on front-end support for in-app purchase ads on our Google+ page.

 - Eric Leichtenschlag, Mobile Ads Developer Relations

Calling all Unity app developers! We are excited to announce the launch of version 2.0 of the Google Mobile Ads Unity Plugin. The new version comes with a completely rewritten, but much more flexible, API. It includes the following new features:

• A single package supporting both Android and iOS
• Support for running apps in the Unity editor
• Ability to create multiple banner instances
• Ability to create banners of any size
• Flexible ad request targeting
• and much more!

Taking a closer look at how to integrate the plugin, a typical banner request in v2.0 looks like this:

BannerView bannerView = new BannerView(
    "YOUR_AD_UNIT_ID", AdSize.Banner, AdPosition.Top);
AdRequest request = new AdRequest.Builder().Build();
bannerView.LoadAd(request);

For custom banner sizes, simply pass in an AdSize object into the BannerView constructor:

AdSize adSize = new AdSize(250, 250);
BannerView bannerView = new BannerView(
    "YOUR_AD_UNIT_ID", adSize, AdPosition.Top);

Want to pass additional targeting parameters? No problem! Set your custom targeting when building the AdRequest:

AdRequest request = new AdRequest.Builder()
        .AddTestDevice(AdRequest.TestDeviceSimulator)
        .AddTestDevice("0123456789ABCDEF0123456789ABCDEF")
        .AddKeyword("unity")
        .SetGender(Gender.Male)
        .SetBirthday(new DateTime(1985, 1, 1))
        .TagForChildDirectedTreatment(true)
        .Build();

Listening for ad events is also extremely straightforward. Register for the callbacks you care about:

bannerView.AdLoaded += HandleAdLoaded;
bannerView.AdFailedToLoad += HandleAdFailedToLoad;
bannerView.AdOpened += HandleAdOpened;
bannerView.AdClosing += HandleAdClosing;
bannerView.AdClosed += HandleAdClosed;
bannerView.AdLeftApplication += HandleAdLeftApplication;

…

public void HandleAdLoaded()
{
    print("HandleAdLoaded event received.");
}

You can also manage the lifecycle of each BannerView by calling show(), hide(), or destroy().

To get access to these awesome features, check out the source code. Also stay tuned for upcoming support for interstitial ads.

If you have any feature requests or bug reports against the plugin, track it! If you have questions about how to use the plugin, speak up! And if you just want the latest news on what’s going on in the wonderful world of Google Ads, circle us!

 - Eric Leichtenschlag, Mobile Ads Developer Relations

Today, we’re excited to announce version 6.6.0 of the iOS Google Mobile Ads SDK. Highlights include:

• Added support for arm64 and x86_64 architectures
• Significantly reduced library size
• Added adNetworkClassName property on GADBannerView and GADInterstitial
• Fixed a bug where DFP app events were not firing for interstitials

The new adNetworkClassName property tells you which ad network class served an ad during mediation. This value will be GADMAdapterGoogleAdMobAds for ads coming from the AdMob or DFP network, and GADMAdapterCustomEvents for custom event classes. For other ad networks, this property will return their adapter’s class name.

Check out the release notes for a full list of updates. The latest SDK can be found on our downloads page. You can reach us on our forum with any questions or concerns about the new SDK, and stay tuned for updates on our Google+ page.

 - Eric Leichtenschlag, Mobile Ads Developers Relations

Today we’re releasing version 6.5.0 of the Google AdMob SDK for iOS developers. This version of the SDK includes a variety of changes including:

• Allows you to specify if you would like your app to be treated as child-directed by calling the tagForChildDirectedTreatment: method in GADRequest or by setting the value of tag_for_child_directed_treatment to 1 in extras for older versions of the SDK. More details on this API are available here.
• Passes Apple's advertising identifier (IDFA) to Google Ad Exchange buyers. This enables buyers to more effectively measure their marketing campaigns on Ad Exchange iOS inventory.
• We’ve updated the warning messages that are displayed when using mediation with incorrect linker flags. The SDK now requires only the -ObjC linker flag.
• A number of other bug fixes and maintenance updates.

Check out the release notes for a full list of updates. You can download the latest SDK from our downloads page. If you’ve got any questions or concerns about the new SDK, please post to our forum or check out our G+ page.

 - Raj Parameswaran, AdMob Team

Unity is a game development framework that makes it very easy to develop games for mobile platforms. Today we're releasing a plugin to help developers show AdMob banner ads in Unity games developed for iOS and Android. This plugin is packaged as a Unity Package so integration with a Unity project should be very easy. The included README has a step-by-step walkthrough on getting started.

We remind developers to follow AdMob best practices when integrating ads into their games. In particular, we advise that you put ads on screens only where they won’t cause a dip in your app’s frame rate.

You can check out the AdMob Unity plugin on our samples page (Android | iOS). Please direct any questions or general feedback to our forum. You can also follow our Google+ page to stay up to date on all of Google's ads products.

 - Raj Parameswaran, AdMob Team

We have just released version 6.4.1 of the Google AdMob SDK for both Android and iOS. The Android release includes:

• The ability to resize a DfpAdView using dfpAdView.resize(AdSize)
• A fix for the ANR errors seen in v6.3

The iOS release fixes a crash that occurs if the Advertising Identifier is nil.

You can get the latest SDKs from our downloads page. Find us on the forum if have questions about the new Google AdMob SDKs. You can also check out our Google+ page for ads-related updates.

 - Eric Leichtenschlag, AdMob Team