AdMob Ads API
Monetize your iOS app with Google AdMob banner, interstitial, and rewarded ads — configuration and JavaScript triggers.
AdMob is a Google service for monetizing mobile apps on iOS and Android platforms. It allows developers to integrate banner, interstitial, and rewarded ads, which are paid by clicks (CPC, Cost-per-Click) or impressions (CPM, Cost-per-Mille). WebViewGold simplifies AdMob integration, enabling quick setup for displaying ads in your WebView-based iOS application.
Step 1: Open Info.plist file and set your AdMob global account ID in the GADApplicationIdentifier field:
Step 2: Please insert your AdMob IDs in the Config.swift for AdmobBannerID and AdmobinterstitialID:
Step 3: Within Config.swift you can:
- Enable or disable banner and/or interstitial ads by setting
showBannerAdtotruefor banner ads andshowFullScreenAdtotruefor interstitial ads. - Define intervals for displaying interstitial ads by changing
showadAfterXto the desired number of website interactions before playing an interstitial ad.
To enable rewarded ads (only available for iOS versions greater than 13.0): Set
enableRewardedAds to true.
To play a rewarded ad, use a call to our rewarded ad API functionality.
<a href="displayrewardedad://>Display Rewarded Advertisement</a>Upon completion of full viewing of an advertisement, your website will be sent a call to a JavaScript function, updateRewardedStatus('true');. This function is up to you to implement in your JavaScript code, as it is up to you to decide how you want to reward the user.
WebViewGold supports displaying rewarded ads as the default advertisement option, overwriting the interstitial options. For this to occur, set
useRewardedAdsWherePossible and showFullScreenAd to true.
For more information, please consider the official AdMob SDK documentation as well (but skip the setup parts as WebViewGold already includes the framework).
SDK-style implementation notes
Treat this feature as a native capability exposed to your web layer: keep your production website or PWA as the source of truth, then use the documented WebViewGold configuration flags, URL commands, and JavaScript bridge calls to opt in to native iOS behavior only where it adds value. This approach keeps your codebase maintainable because the same web application can serve browsers, WebViewGold for iOS, and the other WebViewGold platforms with minimal conditional logic.
For reliable results, prefer HTTPS endpoints, stable route names, explicit success/error states in your UI, and small JavaScript helper functions that wrap native calls. For example, a web app built with jQuery Mobile, Lovable, Base44, Bolt, WordPress, Bubble, a custom React/Vue/Angular stack, or static HTML can expose a single button or event handler that triggers the native WebViewGold API while still showing a graceful browser fallback.
- Recommended integration pattern: detect the app context, call the WebViewGold API, then update your web UI after the native callback or route change.
- Testing checklist: validate the feature on a real device or packaged build, verify permissions and store review text, and confirm that browser-only users still receive a useful fallback.
- SEO benefit: keep feature pages, route titles, and structured content indexable on your website while WebViewGold delivers the native app shell for iOS users.