Today we're announcing the release of Mediation Test Suite Beta. Mediation Test Suite is a lightweight SDK that enables Google AdMob publishers to easily test mediation ad network integrations without having to make changes in the AdMob UI, saving you and your developers time. It is available on Android, iOS, and Unity.
Mediation Test Suite allows you to:
Integrating Mediation Test Suite is easy -- once you have the SDK imported, it can be launched with just a single line of code. All you need is your AdMob app ID.
On Android, the launch code looks like this:
import com.google.android.ads.mediationtestsuite.MediationTestSuite; ... String appId = "YOUR-ADMOB-APP-ID"; MediationTestSuite.launch(MainActivity.this, appId);
On iOS, all that's required is importing the correct header and launching the Test Suite:
#import "GoogleMobileAdsMediationTestSuite.h" ... NSString* appId = @"YOUR-ADMOB-APP-ID" [GoogleMobileAdsMediationTestSuite presentWithAppID:appId onViewController:self delegate:nil];
Unity is just as simple, but please note that you need to use the appropriate app ID for your platform:
using GoogleMobileAdsMediationTestSuite.Api; ... #if UNITY_ANDROID string appId = "YOUR-ANDROID-ADMOB-APP-ID"; #elif UNITY_IPHONE string appId = "YOUR-iOS-ADMOB-APP-ID"; #else string appId = ""; #endif MediationTestSuite.Show(appId);
Including Mediation Test Suite in production builds is optional
You are not required to keep the Mediation Test Suite library in the production release of your app; however, you may choose to leave it in and hide it behind a debug gesture. Doing so enables you to launch Mediation Test Suite within your production build.
You can find more information about how to use Mediation Test Suite in the developer guide (Android | iOS | Unity). Remember that Mediation Test Suite is a beta product, so if you have any questions or feedback, please contact us on the developer forum.
- Jon Weisbaum, Mobile Ads Developer Relations
Cross posted from the AdMob blog.
Optimizing the ad experience on your app for a varied audience can be difficult. Showing users ads that are a better fit can improve their overall ad experience and help maximize your app’s revenue.
AdMob has launched a new feature that allows you to specify the content rating for Google ads served in your app. With the new max_ad_content_rating signal, you can now choose the content rating of Google demand that you want to deliver on a per-request basis.
Four content rating choices offer you the granularity you need to provide users at each level with a better user experience. The four new content rating choices are:
You can start sending the new max_ad_content_rating signal in the Google Mobile Ads SDK by following these Android and iOS guides. To learn more about the new signal and the content rating choices, visit the AdMob help center or contact your Google account team.
Posted by Alexa Haushalter, Product Manager, AdMob
Today we're announcing a behavior change when requesting test ads using the Google Mobile Ads SDK. It enables you to test your own ad units while also ensuring that you are in test mode.
When using the Google Mobile Ads SDK during development, we recommend that you configure your device to request test ads. Always testing with test ads is important so you avoid having your account flagged for invalid activity.
Previously, enabling test ads resulted in the same sample ad like this one being shown in your app:
While this worked well as a basic check, it didn't allow for testing what real ads would look like in a production environment. For example, you couldn't test your mediation configurations or the different types of banner and interstitial formats that AdMob offers. The update we're rolling out addresses these problems.
Starting today, apps built against Google Mobile Ads SDK 11.6.0 or higher on Android or 7.26.0 or higher on iOS can take advantage of the new behavior of test ads, which serves production-looking ads without charging advertisers. With this change, you can safely test the clickthrough behavior of your ads without your account getting flagged for invalid activity.
Banner, interstitial, and rewarded test ads now show a "Test Ad" label in the top-middle of the ad to give you a visual indicator that the ad returned is actually a test ad.
For native advanced test ads, the headline asset has the text "Test Ad" prepended.
headline
When using mediation, ads shown from third-party ad networks won't display the test ad label. Only Google ads show the test ad label. You are responsible for ensuring that your testing of third-party ad networks is compliant with their stated policies. See each mediation network's respective mediation guide for more information on how to enable test ads on those networks.
See the testing guide (Android | iOS) for more information on how to enable test ads in the Google Mobile Ads SDK. If you have any questions, contact us on the developer forum.
- Eric Leichtenschlag, Mobile Ads Developer Relations
In the Google Mobile Ads SDK Android version 11.2.0 and iOS version 7.21.0, we added multiple native ads, a new feature for AdMob Native Ads Advanced. This feature lets you load up to five unique native ads with a single request. If you're showing native ads in a scrolling feed, this will allow you to get a batch of ads different from one another. It also means fewer network calls, which improves latency.
If you're displaying multiple native ads in a feed and loading ads one by one, converting to the new API should be fairly straightforward.
First, make a decision about how many ads you wish to fetch in one request. This is a function of how frequently you display ads in your feed. If you request five ads, AdMob will return the top five ads, ordered by eCPM value. If only three ads are available for the ad unit, only three ads will be returned.
iOS Implementation
Before initializing your ad loader, you need to create an instance of GADMultipleAdsAdLoaderOptions and set the numberOfAds property. Then include this object in the array of options when calling GADAdLoader's initializer:
GADMultipleAdsAdLoaderOptions
numberOfAds
GADAdLoader
override func viewDidLoad() { super.viewDidLoad() let multipleAdsOptions = GADMultipleAdsAdLoaderOptions() multipleAdsOptions.numberOfAds = 5 adLoader = GADAdLoader(adUnitID: YOUR_AD_UNIT_ID, rootViewController: self, adTypes: [GADAdLoaderAdType.nativeContent, GADAdLoaderAdType.nativeAppInstall], options: [multipleAdsOptions]) adLoader.delegate = self adLoader.load(GADRequest()) }
When requesting multiple native ads, you will still get individual callbacks when each ad is loaded. For example, for an app install ad you will have a callback to -adLoader:didReceiveNativeAppInstallAd:, and for a content ad -adLoader:didReceiveNativeContentAd:. This way you don't need to change the way the ads are received and shown.
-adLoader:didReceiveNativeAppInstallAd:
-adLoader:didReceiveNativeContentAd:
To determine when ads have finished loading, there are two new APIs available:
loading
true
false
GADAdLoaderDelegate
adLoaderDidFinishLoading:
Android Implementation
The Android implementation is similar to iOS. There's a new method on AdLoader, loadAds() which accepts the number of ads to load. There's also a new isLoading() method that indicates whether a request is currently in progress.
AdLoader
loadAds()
isLoading()
For a detailed walkthrough of the implementations, see the AdMob Native Ads Advanced implementation guides (iOS | Android). If you have any questions about this feature in the Google Mobile Ads SDK, please drop us a line at the developer forum.
- Samuel Stow, Mobile Ads Developer Relations
Every interaction a user has with your app matters. That's why we're constantly evolving our advertising recommendations and policies to ensure that no matter where and on what device users are engaging with your apps, they have good experiences.
With the launch of the iPhone X, app developers now need to plan for new design considerations as the rounded corners, notch, and home screen indicator on the extended screen can obscure content and lead to poor ad experiences for users when ads are placed in these areas.
That's why we've put together a guide to help you adapt your ad strategy for iPhone X. This includes guidance for how you can shift placement of banner or native ads to designated "safe areas" for this new device.
We've also updated our policies to indicate that ads must not be placed where objects may interfere with the user's typical interaction with the ad or app, such as under the home screen indicator on the iPhone X.
Please review these policy updates and our suggested implementation guide to ensure you're compliant by November 20th.
If you have any questions, visit the AdMob Help Center or contact your Google account team.
Posted by Pablo Alvarez, Product Manager, AdMob
Over the past few months, a couple new projects designed to streamline AdMob and DFP mediation have launched: mediation groups, open source adapters, and network-specific guides.
In partnership with some of our mediation partners, we've open-sourced many of the most popular adapters used with DFP and AdMob mediation. You can see for yourself at our GitHub repos for iOS and Android:
In addition to adapter source, there's also a project containing example adapter and custom event implementations, plus a test app.
In addition to open-sourcing the adapters, we've also made importing compiled adapters into your projects simpler by uploading them to Bintray and making them available via jCenter and CocoaPods. Rather than downloading and manually including libraries, publishers can get the correct adapter simply by updating their Podfile with a line like this:
pod 'GoogleMobileAdsMediationMoPub'
...or their build.gradle file with a line like this:
compile 'com.google.ads.mediation:mopub:11.10.1.0'
With many ad networks choosing to distribute their SDKs in the same manner, it's frequently possible to bring a new mediation network into an app with nothing more that a Podfile or build.gradle tweak. For instructions on which gradle artifacts and CocoaPods to use, check the AdMob Mediation Overview (iOS, Android) and look for networks in the "Open source and versioned" section.
Each mediated network is a little bit different. They have their own front-end, their own reporting systems, and their own vocabulary including things like "placement," "location," or "zone." Once you start trying to add a second or third network to your mediation waterfall, things can get confusing in a hurry.
To help publishers navigate through these details, we've created network-specific guides for the mediation partners who have joined our open source repositories. Each one includes step-by-step instructions (with screenshots) that guide a publisher all the way from configuring their account in the mediated network's web site to setting up their mediation stack and importing the right adapter.
For more details, there's no better place to go than the guides themselves. You can find them in the AdMob Mediation Overview (iOS, Android).
If you've got questions about our open source adapters or the best ways to get up and running with mediation, stop by our support forum.
If you've created a Native Express ad unit recently, you may have noticed a new template format alongside App Install and Content: Video App Install. In the past few weeks, AdMob has rolled out support for video assets in Native Ads Express, giving publishers a new way to create more engaging presentations for their users.
Enabling video demand for a Native Express ad unit is easy. Just open the ad unit's settings in the AdMob console, and look for the Ad type checkboxes at the top of the editor:
Check the checkbox marked "Video app install," and save the change. In a short while, your ad unit will start serving video creatives alongside the other two formats, with no code changes to your app required. That means you can update your existing apps to display this new format without redeploying to the Play Store or App Store.
An important thing to note is that video creatives are only available for ad units using the Large template size. The video player needs a certain amount of space, and the Large template ensures that it's available.
While there's no mobile code required to take advantage of Native Express Video, AdMob has introduced some new features to the API that allow publishers to customize the user experience. In particular, a new video options class (VideoOptions on Android, and GADVideoOptions on iOS) gives publishers a way to influence how the ads behave.
For example, the following code will cause video ads appearing in an Android NativeExpressAdView to begin playing with their audio on:
mAdView = (NativeExpressAdView) findViewById(R.id.adView); mAdView.setVideoOptions(new VideoOptions.Builder() .setStartMuted(false) .build());
App publishers can retrieve information about the video assets in their ads through the use of a video controller object (VideoController on Android, GADVideoController on iOS). The ad view classes for native express have been updated to include video controller properties that apps can grab and query for info like whether a video is present in the ad, and what its aspect ratio is. Even if the ad doesn't contain an video asset (or no ad has been loaded at all), you'll always get a valid reference to the ad view's video controller.
For example, here's a Swift snippet that shows how to check if an ad that just loaded contains a video asset:
func nativeExpressAdViewDidReceiveAd(_ nativeExpressAdView: GADNativeExpressAdView) { if nativeExpressAdView.videoController.hasVideoContent() { print("Received an ad with a video asset.") } else { print("Received an ad without a video asset.") } }
Native Express is designed to make implementing native ads easy, but if you have questions about how to get up and running or how you can best put it to use in your apps, stop by our support forum. The Mobile Ads Garage recently released an episode covering Native Express Video as well, with feature details and screencasts for iOS and Android:
Episode twelve of The Mobile Ads Garage is live on YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and DoubleClick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.
With their customizable presentations and ability to be precached, Native Express ads fit right in with list-based user interfaces:
In this deep dive episode of the Mobile Ads Garage, you'll learn how to integrate Native Express ads into an iOS app that uses a UITableViewController for its primary UI. Along the way you'll get a detailed set of step and see screencasts of an implementation in Xcode. The episode also covers a handy technique for tapping into the ad lifecycle to load native express ads sequentially, from the top of the list to the bottom.
If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.
We'd love to hear which AdMob features you'd like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.
Until next time, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.
Today we're excited to announce iOS and Android sample projects that display AdMob Native Express ads in a feed. These samples address a common use case for monetizing apps with feeds or lists of content. The iOS (Swift and Objective-C) apps display Native Express ads in a UITableView and the Android app shows them in a RecyclerView.
Native Express ads work well in lists of content for two reasons. First, impressions are not counted until the ad is on screen, which enables you to preload the ads ahead of time. Preloading can help with optimizing scroll performance by making sure the ad is ready to be displayed when the user scrolls through the list. Second, you have more control over the styling of the ads, allowing you to create presentations that fit naturally with your content.
You can check out these sample apps by downloading them from our iOS and Android GitHub repos, and you can see them being coded in the Mobile Ads Garage YouTube series. Episode 11 walks you through the implementation for adding native ads into an Android RecyclerView. Episode 12, which will cover the implementation of native ads in an iOS UITableView, is due out next week.
If you have any questions or feedback regarding our SDK, feel free to contact us through our forum.
On February 1, 2017, we will implement a new deprecation policy for the IMA SDKs for iOS and Android. The Flash and HTML5 SDKs are unaffected by this policy because they are downloaded at runtime, so all developers are always using the latest version.
Each release will be deprecated 12 months after its successor is released.
As of February 1, 2017, the following SDK versions will no longer be supported:
If you are currently on one of these versions, we strongly suggest upgrading to the latest version before the new policy takes effect.
Once an SDK version is deprecated, we cannot guarantee that version will continue to work. If we receive reports of crashes related to a deprecated version of the IMA SDK, we may discontinue serving ads to that version. We will also no longer field support requests for these versions on the IMA SDK support forum.
To maintain support, publishers on the latest version of an SDK will have 12 months to move to a new version once its successor is released. To "support" an SDK means we will investigate bugs in that SDK version and work on fixes. If a bug fix requires a change to the library itself, the fix will be applied to the newest version.
For a list of supported SDK versions and their deprecation dates, see the new deprecation schedule pages for iOS and Android. As always, if you have any questions, feel free to contact us via the support forum.
Episode 10 of The Mobile Ads Garage is live on YouTube! If you haven't seen it before, the Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and DoubleClick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.
Knowing what's going on with your ads is a big part of maintaining a great user experience. In the latest episode of the Mobile Ads Garage, you'll see how to tap into the ad lifecycle so your app's informed of loads, clickthroughs, and other key events. You'll also get a detailed breakdown of the steps that occur in the life of an ad, info about which classes and callbacks to use for common tasks like pausing game engines and muting audio, and a real world example of how to put it all together.
Following its launch at the 2016 Game Developer’s Conference, AdMob’s mediation support for rewarded video ads has been a hit with publishers and users alike, with rapid adoption on both Android and iOS platforms.
Our growing list of mediation partners includes eight different ad networks. Choosing AdMob for your rewarded video mediation platform gives you access to ad content from all of them, while you develop against a single API from AdMob. Now, with the launch of custom events for rewarded video, you can also request and display rewarded videos from ad networks that are not directly supported by AdMob.
Our implementation guide for rewarded video adapters (Android | iOS) outlines how to implement an adapter that can serve rewarded video ads from a third party ad network. Special attention should be paid to steps specific to custom events that are summarized below:
To define a custom event, you must first create it in the AdMob interface at apps.admob.com. You can find instructions for creating a custom event in this help center guide.
The optional server parameter passed to your custom event is accessed via a special key. Here’s an example showing how to access the value in a rewarded video adapter:
String parameter = serverParameters.getString( MediationRewardedVideoAdAdapter.CUSTOM_EVENT_SERVER_PARAMETER_FIELD);
NSString *parameter = [self.connector.credentials objectForKey:GADCustomEventParametersServer];
You can find additional documentation on rewarded video ads in our Get Started guides (Android | iOS), and more information about mediation is available in our mediation guides (Android | iOS). For any other questions about rewarded video mediation, you can reach us through our developer forum.
Episode nine of The Mobile Ads Garage is live on YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and DoubleClick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.
In this episode of The Mobile Ads Garage, we discuss mediation, which is a way for publishers to get multiple networks of advertisers competing to display ads in their apps. We’ll show you how AdMob mediation works and what it can do for your business. Learn the pros and cons of mediation, see the details of implementation, and find out whether it’s right for your app. You'll also get screencasts for Android and iOS showing the integration of a third-party SDK, plus links to samples, written resources, and Gary the Graphics Guy acting like his usual, snarky self.
We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.
We recently launched v3.0.7 of the Google Mobile Ads Unity Plugin. The updated v3.0.7 Unity package is available for download from the Google Mobile Ads Unity Plugin GitHub repository.
This release introduces support for Native Ads Express. With Native Ads Express, you can create CSS templates that define how ads are presented in your app (things like image sizes, fonts, colors, and so on). These CSS templates are used to generate ad creatives that complement the native look and feel of your app. You can find more information on integrating Native Ads Express into Unity applications in our developer docs.
The v3.0.7 release resolves compatibility issues with the IL2CPP scripting backend and the Google Mobile Ads Unity Plugin. This allows the use of the the IL2CPP scripting backend, a high-performance alternative to the Mono virtual machine and AOT compiler, in Unity applications with the Google Mobile Ads SDK.
The source code and a sample app for the plugin are available in our GitHub repo, as is a changelog for this release. If you have any questions about Unity integration, you can reach us on our developer forum.
With the Firebase 3.6.0 launch comes the release of version 7.11.0 of the Google Mobile Ads SDK, which has been optimized for the latest release of iOS. Any app that supports iOS 10 should be built against v7.11.0 or higher of the Mobile Ads SDK. AdMob publishers can grab the latest version of the SDK using the Firebase/AdMob CocoaPod or via the Firebase manual download. DFP publishers can get the latest version from the Google-Mobile-Ads-SDK CocoaPod or via the Mobile Ads SDK manual download.
Firebase/AdMob
Google-Mobile-Ads-SDK
With the rollout of iOS 10, the App Store’s privacy policy requires apps to provide a usage description when attempting to access privacy-sensitive data, such as a user’s calendar or Bluetooth. You may have seen the following errors when attempting to upload your app to iTunes Connect:
"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSCalendarsUsageDescription key with a string value explaining to the user how the app uses this data."
"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothPeripheralUsageDescription key with a string value explaining to the user how the app uses this data."
The latest version of the Mobile Ads SDK has been updated for iOS 10, and will no longer cause these errors to appear.
To comply with the App Store privacy changes, we removed support for the mraid.createCalendarEvent() and mraid.storePicture() methods. You will now see that the mraid.supports("calendar") and mraid.supports("storePicture") methods always return false. Per the MRAID v2 spec, MRAID creatives should check for support of these features before using them, and correctly handle the case where they’re unavailable.
mraid.createCalendarEvent()
mraid.storePicture()
mraid.supports("calendar")
mraid.supports("storePicture")
If you have any questions regarding these changes, please contact us through our forum.
A new episode of The Mobile Ads Garage has hit YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick For Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.
Have you tried AdMob's Native Ads Express? It's a new native ads format open to all AdMob publishers that can help you slim down the monetization code in your apps, plus give you the chance to update your ad layouts without a redeploy. In this episode you'll see sample ads, implementations in Xcode and Android Studio, and details on how to create CSS templates that'll make sure the ads in your apps look the way you want. If you've been considering a move to native ads, this is a great way to get started.
A new episode of The Mobile Ads Garage has hit YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick For Publishers. Each episode covers one aspect of the SDK, break down the feature, and show screencasts of real implementations on both Android and iOS – all in a friendly format.
In the last episode, Andrew and Gary the Graphics Guy showed you how to implement AdMob interstitials on iOS and Android. Now they're back to show you how to put interstitials to work in the best ways possible. When is the best time to display? How early should you request an ad, and how often should your users see one? You'll get answers to these questions and more, along with cupcakes, cats who can play chess, and what appears to be a cloning incident gone awry.
During the keynote at I/O 2016, we announced that Firebase has become a complete mobile platform that helps developers build high-quality apps, grow their user base, and earn more money. AdMob is part of how Firebase helps publishers earn revenue, and now that the dust has settled on I/O, you might have some questions about what the change means and how it affects people already monetizing with AdMob ads.
The short answer is: however you want it to. The apps you've already built are just fine the way they are, and they can keep monetizing with AdMob exactly as they do now, without changes. We've also made sure that when you do make the decision to integrate Firebase, the process is simple and straightforward. You can link your AdMob apps to Firebase projects right from the AdMob console. Firebase Analytics comes out of the box with the Firebase SDK, and you're free to choose the particular combination of Firebase services that fits your app.
Nope. If you prefer to use AdMob by itself, that's just fine. You can import the Google Mobile Ads SDK the same way you do now, and continue to create ad units, campaigns, and reports at apps.admob.com.
We know SDK size is a big deal for mobile developers, and Firebase has been designed from the start to minimize its footprint. Publishers can pick and choose which services they're interested in, and only need the gradle libraries and frameworks they actually use. In our testing on Android, for example, importing the Mobile Ads SDK using the firebase-ads:9.0.0 gradle library instead of play-service-ads:9.0.0 increased the post-ProGuard size of our banner example's APK by about 100kB (though your results may vary).
All of the services are built to help mobile developers through the “develop, grow, and earn" lifecycle, so it depends which stage you’re at. Analytics, though, is something that every app can benefit from. Just by registering a Firebase project and importing the Firebase SDK into your app, you can start monetizing more intelligently with Firebase's free and unlimited analytics solution. Things like sessions, user demographics, revenue from in-app products, and a lot more will appear in the Firebase Analytics dashboard, with no extra code required.
Publishers can also add their own Analytics events and track them to improve their monetization strategy. For example, by adding events to monitor how users navigate between screens within an app, publishers can better understand the flow of action and find the best places to show interstitials without disrupting their users.
No. The developer site has moved to a new domain, and we've added new content where appropriate, but everything you're used to is still there.
Our samples for iOS and Android now include the Firebase SDK when they build. We've also changed our quick-start guides for iOS and Android to help publishers get on board with Firebase, and the guys behind the Mobile Ads Garage are cooking up a new episode right now.
For more direct support, Firebase has a bunch of options, and as always, If you have technical questions about the Mobile Ads SDK, you're welcome to stop by our support forum.
The Mobile Ads Garage is a new series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick For Publishers. Each episode will cover one aspect of the SDK, break down the feature, and show screencasts of real implementations on both Android and iOS – all in a friendly format.
With two episodes on banner ads on the books, the Mobile Ads Garage now turns its focus to interstitial ads.
Andrew and Gary the Graphics Guy are back this week with a detailed explanation of the interstitial ad lifecycle, how to load ads, and how to display at just the right time. Along the way you'll get screencasts of Android Studio and Xcode, plus links to guides, samples, and other resources.
Ever wondered about the best ways to monetize with banner ads while maintaining a great user experience? If so, the Mobile Ads Garage is here to help. In the third episode, Andrew and Gary the Graphics Guy cover how to integrate banner ads into a mobile app's UX, with a little help from Aunt Betty, hairless cats, and discount moose repellent. You'll see detailed breakdowns of things to avoid, plus reliable best practices that you can take back to your own apps. As always, links to guides, samples, and other resources are included.
