--- title: An Alternative to the Capacitor Community AdMob Plugin description: Looking for a Capacitor Community AdMob alternative? Compare UMP consent, app open automation, revenue events and the Next-Gen SDK, plus an API mapping table. date: created: 2026-10-21 updated: 2026-10-21 authors: - robingenz categories: - Capacitor - Guides - SDKs links: - Capacitor AdMob: sdks/capacitor/admob.md faq: true --- # An Alternative to the Capacitor Community AdMob Plugin Most teams looking for a Capacitor Community AdMob alternative are not fleeing an abandoned plugin. `@capacitor-community/admob` shipped version 8.2.1 on October 6, 2026 and is downloaded about 53,500 times a week. The reasons to switch are narrower: its Android side still pins the legacy Google Mobile Ads SDK, which Google sunsets on June 30, 2028, its consent flow takes three calls where one would do, app open ads need your own foreground logic, and revenue data arrives on a different event per ad format. This post compares it with the [Capacitor AdMob plugin](../../sdks/capacitor/admob.md) along those four axes, lists what you give up, and maps every method, option and event of the community plugin to its counterpart. The Capacitor AdMob plugin is part of [Capawesome Insiders](../../insiders/index.md), a paid subscription, while the community plugin is free under the MIT license.
Ship a fix in one command with Capawesome Cloud Live Updates, no store review
**Key takeaways:** - `@capacitor-community/admob` is maintained: version 8.2.1 was published on October 6, 2026, the repository had 23 open issues on October 19, 2026, and the package sees about 53,000 weekly downloads. - Its v8 pins the legacy Android Mobile Ads SDK 25.4.x, deprecated on June 30, 2027 and sunset on June 30, 2028; the Capacitor AdMob plugin uses the Next-Gen SDK. - The community consent flow is `requestConsentInfo()`, a status check and `showConsentForm()`; the Capacitor AdMob plugin folds it into `requestConsent()` and refuses to load ads until consent is gathered. - `enableAppOpenAutoShow()` replaces the load, show and foreground-listener code that app open ads need with the community plugin, and adds a frequency cap. - The community plugin reports revenue per format with `valueMicros`, mediation network and impression ID; the Capacitor AdMob plugin reports one `adRevenuePaid` event for every format without the mediation fields. ## Maintenance status `@capacitor-community/admob` is actively maintained, so a switch is a trade between two working plugins rather than an escape. The numbers from its [GitHub repository](https://github.com/capacitor-community/admob){:target="_blank"} and its [npm page](https://www.npmjs.com/package/@capacitor-community/admob){:target="_blank"}, checked on October 19, 2026: | Fact | Value | | --- | --- | | Latest release on npm | 8.2.1, published 2026-10-06 | | Last push to `main` | 2026-10-06 | | Open issues | 23, plus 4 open pull requests | | Weekly downloads | about 53,500 (week ending 2026-10-18) | | License | MIT | | Requirements | Capacitor 8.5 or later, iOS 15, Android API level 24 | Version 8.2.0 landed the day before, and the plugin publishes beta builds per pull request under a `beta` dist-tag, so pull requests get tested before they merge. It has a dedicated documentation site with per-format guides, and a native ads format is available as a preview. None of that reads like a project winding down. The Capacitor AdMob plugin is younger. Its README still carries an experimental notice, the current version is 0.1.1, and it requires Capacitor 8. What it offers over the incumbent is a newer SDK generation and an API designed around the pain points that the community plugin's issue tracker documents, which the next four sections cover. ## SDK generations The Android SDK generation is the one difference that has a deadline. The community plugin's README states that its v8 pins Google Mobile Ads SDK 25.4.x on Android and 13.11.0 on iOS, and that Google's Next-Gen SDK for Android "waits until the next plugin major". The `build.gradle` confirms the pin: `play-services-ads` at `25.4.+` and `user-messaging-platform` at 4.0.0. Google's [deprecation schedule](https://developers.google.com/admob/android/deprecation){:target="_blank"} for the legacy Android SDK gives versions 24 and 25 a deprecation date of June 30, 2027, after which ads still serve but Google no longer provides technical support, and a sunset date of June 30, 2028, after which ads are "at risk of not serving". The successor is the [Next-Gen SDK](https://developers.google.com/admob/android/next-gen){:target="_blank"}, published as a separate artifact (`com.google.android.libraries.ads.mobile.sdk`) with a different API rather than as another major version of the old one. The Capacitor AdMob plugin runs on the Next-Gen SDK on Android from its first release, defaulting to `ads-mobile-sdk` 1.2.1 with the User Messaging Platform at 3.2.0, both overridable through `variables.gradle`. On iOS, both plugins use Google's regular Mobile Ads SDK, because Google has not published a Next-Gen variant for iOS. If your app only ships on iOS, this section does not apply to you. For an app already on the community plugin, the practical question is when, not whether, its Android ad code changes. The Next-Gen SDK is a different API on the native side, and the community README defers that move to its next major version, which is a breaking release by definition. Moving to the Capacitor AdMob plugin is also a rewrite of your JavaScript ad code. Either way, budget for a migration before mid-2027. ## Consent flow The User Messaging Platform (UMP) flow is where the two APIs differ most in shape, although both wrap the same Google SDK. With the community plugin, the recommended order from its consent documentation is three steps: call `requestConsentInfo()` on every launch, call `showConsentForm()` when the result says a form is available and the status is `REQUIRED`, then call `initialize()` once `canRequestAds` is `true`. Nothing stops you from loading an ad before that, apart from Google's policy. The Capacitor AdMob plugin runs the same sequence inside [`requestConsent(...)`](../../sdks/capacitor/admob.md#requestconsent): it requests the consent information, shows the form if consent is required, and resolves with `canRequestAds`, `privacyOptionsRequired` and the consent `status`. Every load method rejects with the `CONSENT_NOT_GATHERED` error code until the consent requirements are met, so a forgotten consent call fails in development instead of violating Google's EU User Consent Policy in production. [How to Handle AdMob GDPR Consent (UMP) in a Capacitor App](./how-to-handle-admob-gdpr-consent-in-a-capacitor-app.md) walks through the whole flow, including the privacy options form and App Tracking Transparency on iOS. The rest of the consent API matches one to one. Both plugins offer a privacy options form (`showPrivacyOptionsForm()` on both), a reset for testing (`resetConsentInfo()` versus `resetConsent()`), debug geography and test device identifiers. One parameter does not carry over. The community plugin passes `tagForUnderAgeOfConsent` into the consent request, which tells the UMP SDK to run the consent flow for a user under the age of consent. The Capacitor AdMob plugin accepts a `tagForUnderAgeOfConsent` flag only in `initialize(...)`, where its README documents it as a setting for ad requests, and `initialize(...)` runs after `requestConsent()` has already shown the form. If your app sets the flag on the consent request today, treat that as a migration limitation rather than a renamed option. The debug geography enums differ in shape: the community plugin uses numeric values (`EEA`, `NOT_EEA`, `US`, `OTHER`), the Capacitor AdMob plugin string values (`Eea`, `RegulatedUsState`, `Other`, `Disabled`). ## App open automation App open ads are the format where the plugins differ in how much code you own. The community plugin gives you `loadAppOpen(...)`, `showAppOpen(...)` and `isAppOpenLoaded(...)`, plus six lifecycle events. Showing an ad when the user returns to the app is your job: listen for the app state change, check whether a loaded ad exists, show it, load the next one after it closes, and track when the last one was shown so the user does not see one on every switch. Google's guidance on how often an app open ad may appear is yours to implement. The Capacitor AdMob plugin keeps the manual pair, [`loadAppOpenAd(...)`](../../sdks/capacitor/admob.md#loadappopenad) and [`showAppOpenAd(...)`](../../sdks/capacitor/admob.md#showappopenad), and adds [`enableAppOpenAutoShow(...)`](../../sdks/capacitor/admob.md#enableappopenautoshow). One call with an ad unit ID and a `minInterval` in seconds (default 14,400, four hours) makes the plugin load an ad, show it whenever the app comes back to the foreground, honor the interval, and never show it while a consent form or another full-screen ad is visible. `disableAppOpenAutoShow()` turns it off again. ## Revenue events Both plugins expose Google's impression-level paid events, but they shape the data differently. The community plugin emits revenue on a per-format event: `bannerAdPaid` for banners, and the `AdImpression` member of each full-screen format's event enum, which the README documents as emitting "impression-level ad revenue data when a paid event is recorded". The payload, `AdMobRevenueData`, carries `adUnitId`, `valueMicros` (1,000,000 micros per currency unit), `currencyCode`, a numeric `precision`, plus `networkName` (the mediation adapter class) and `impressionId`. The Capacitor AdMob plugin emits one [`adRevenuePaid`](../../sdks/capacitor/admob.md#addlisteneradrevenuepaid-) event for all five formats. Its payload carries `value` in the currency's standard unit, `currencyCode`, a string `precision` (`PRECISE`, `ESTIMATED`, `PUBLISHER_PROVIDED` or `UNKNOWN`), the `format` and the instance `id`. One listener feeds your lifetime value pipeline for every ad, and the `format` field replaces the need to know which event fired. What the Capacitor AdMob plugin does not report is the mediation network and the impression ID. If your analytics setup attributes revenue per mediation partner, the community plugin's payload is the richer one, and the API mapping below marks those fields as having no equivalent. ## What you give up Switching to the Capacitor AdMob plugin drops seven things the community plugin has, and two of them are features rather than options: - **Native ads**: the community plugin ships a native ads format as a preview, with the note that its API may change in a minor release. The Capacitor AdMob plugin has no native ad format. - **App Tracking Transparency helpers**: `trackingAuthorizationStatus()` and `requestTrackingAuthorization()` are built in. The Capacitor AdMob plugin delegates this to the separate [App Tracking Transparency plugin](../../sdks/capacitor/app-tracking-transparency.md), which is a second dependency. - **Banner margin and center position**: the `margin` option in dp or points and the `CENTER` position have no equivalent. The Capacitor AdMob plugin replaces the margin workaround with `mode: 'resize'` and inline placement by frame; [How to Fix AdMob Banner Overlap in a Capacitor App](./how-to-fix-admob-banner-overlap-in-capacitor.md) explains why the fixed margin broke under edge-to-edge layouts anyway. - **Per-request flags**: `npa` (non-personalized ads), `isTesting` and `immersiveMode` are not options of the Capacitor AdMob plugin. Non-personalized ads come out of the UMP consent result, and test ads come from Google's test ad unit IDs. - **Mediation fields in revenue events**: `networkName` and `impressionId`, as described above. - **A free license**: the community plugin is MIT licensed. The Capacitor AdMob plugin needs a Capawesome Insiders subscription. - **A stable version number**: the Capacitor AdMob plugin is at 0.1.1 and marked experimental in its README. In return, you get the Next-Gen SDK, several banners at once with their own identifiers, `resize` and inline `frame` banner modes with insets handled natively, the one-call consent flow with the `CONSENT_NOT_GATHERED` guard, app open automation, a single revenue event, and typed error codes on every rejection. ## API mapping The table maps the API of `@capacitor-community/admob` 8.2.1 to the Capacitor AdMob plugin, grouped by the order you meet them. The biggest structural change is that full-screen ads are addressed by an instance `id` that `load...` returns (or that you pass in), instead of by the ad unit ID of the most recently prepared ad. | `@capacitor-community/admob` | Capacitor AdMob plugin | | --- | --- | | `import { AdMob } from '@capacitor-community/admob'` | `import { Admob } from '@capawesome-team/capacitor-admob'` | | `requestConsentInfo(options)`, then `showConsentForm()` | [`requestConsent(options)`](../../sdks/capacitor/admob.md#requestconsent) does both | | `AdmobConsentInfo.canRequestAds`, `privacyOptionsRequirementStatus` | `canRequestAds`, `privacyOptionsRequired` (boolean) | | `showPrivacyOptionsForm()`, `resetConsentInfo()` | `showPrivacyOptionsForm()`, [`resetConsent()`](../../sdks/capacitor/admob.md#resetconsent) | | `requestConsentInfo({ tagForUnderAgeOfConsent })` | *No equivalent* on the consent request; `initialize({ tagForUnderAgeOfConsent })` tags ad requests only | | `AdmobConsentDebugGeography.EEA` (numeric enum) | `DebugGeography.Eea` (string enum) | | `initialize({ testingDevices, initializeForTesting, ... })` | [`initialize({ testDeviceIds, ... })`](../../sdks/capacitor/admob.md#initialize) | | `trackingAuthorizationStatus()`, `requestTrackingAuthorization()` | App Tracking Transparency plugin | | `showBanner({ adId, adSize, position, margin })` | [`showBanner({ adUnitId, size, position, mode })`](../../sdks/capacitor/admob.md#showbanner) resolves with `{ id }` | | `BannerAdPosition.BOTTOM_CENTER`, `TOP_CENTER`, `CENTER` | `'bottom'`, `'top'`; no center | | `BannerAdSize.SMART_BANNER` | *No equivalent*; use `BannerSize.AdaptiveBanner` | | *No equivalent* | `BannerSize.InlineAdaptiveBanner` with a `frame`, `collapsible`, [`setBannerFrame(...)`](../../sdks/capacitor/admob.md#setbannerframe) | | `hideBanner()`, `resumeBanner()`, `removeBanner()` | Same names, each takes `{ id }` | | `bannerAdSizeChanged` with `{ width, height }` in dp or points | `bannerSizeChanged` with `{ id, width, height }` in CSS pixels | | `prepareInterstitial({ adId })`, `showInterstitial({ adId? })` | [`loadInterstitialAd({ adUnitId })`](../../sdks/capacitor/admob.md#loadinterstitialad) resolves with `{ id }`, `showInterstitialAd({ id })` | | `prepareRewardVideoAd({ adId, ssv })`, `showRewardVideoAd()` | [`loadRewardedAd({ adUnitId, serverSideVerification })`](../../sdks/capacitor/admob.md#loadrewardedad), `showRewardedAd({ id })` | | `prepareRewardInterstitialAd(...)`, `showRewardInterstitialAd()` | `loadRewardedInterstitialAd(...)`, `showRewardedInterstitialAd({ id })` | | `loadAppOpen({ adId })`, `showAppOpen()`, `isAppOpenLoaded()` | `loadAppOpenAd({ adUnitId })`, `showAppOpenAd({ id })`; `AD_NOT_LOADED` error code instead of a check | | Foreground listener in your app | [`enableAppOpenAutoShow({ adUnitId, minInterval })`](../../sdks/capacitor/admob.md#enableappopenautoshow) | | `RewardAdPluginEvents.Rewarded` with `{ type, amount }` | `rewardEarned` with `{ id, type, amount }` | | Per-format event enums (`InterstitialAdPluginEvents.Loaded`, ...) | Shared events `adLoaded`, `adShowed`, `adDismissed`, `adClicked`, `adFailedToLoad`, `adFailedToShow`, `adImpressionRecorded`, each with `format` and `id` | | `bannerAdPaid` and per-format `AdImpression` with `AdMobRevenueData` | `adRevenuePaid` with `{ id, format, value, currencyCode, precision }` | | `valueMicros`, `networkName`, `impressionId` | `value` in standard units; *no equivalent* for the other two | | `AdMobError { code: number, message }` | Rejections with `error.code` from `ErrorCode` plus the SDK message; events keep the numeric SDK code | | `npa`, `isTesting`, `immersiveMode` | *No equivalent* | | `MaxAdContentRating.ParentalGuidance` | `MaxAdContentRating.Pg` | | `setApplicationMuted(...)`, `setApplicationVolume(...)` | Same names | ## Migrating the code A consent flow followed by an interstitial looks like this with the community plugin, following the order its documentation recommends: ```typescript import { AdMob, AdmobConsentStatus } from '@capacitor-community/admob'; const startAds = async () => { let consentInfo = await AdMob.requestConsentInfo(); if (consentInfo.isConsentFormAvailable && consentInfo.status === AdmobConsentStatus.REQUIRED) { consentInfo = await AdMob.showConsentForm(); } if (!consentInfo.canRequestAds) { return; } await AdMob.initialize(); await AdMob.prepareInterstitial({ adId: 'ca-app-pub-3940256099942544/1033173712' }); await AdMob.showInterstitial(); }; ``` With the Capacitor AdMob plugin, the status check moves inside the plugin, and the interstitial is addressed by the identifier that the load call returns: ```typescript import { Admob } from '@capawesome-team/capacitor-admob'; const startAds = async () => { const { canRequestAds, privacyOptionsRequired } = await Admob.requestConsent(); if (!canRequestAds) { return privacyOptionsRequired; } await Admob.initialize(); const { id } = await Admob.loadInterstitialAd({ adUnitId: 'ca-app-pub-3940256099942544/1033173712', }); await Admob.showInterstitialAd({ id }); return privacyOptionsRequired; }; ``` Two details change beyond the names. First, the community plugin targets `showInterstitial()` at the most recently prepared ad unless you pass `adId`, so apps that preload two interstitials for different screens identify them by ad unit ID. The Capacitor AdMob plugin identifies every loaded ad by its `id`, which you can also set yourself in the load options, so two instances of the same ad unit coexist. Second, errors arrive differently: the community plugin reports load failures through `InterstitialAdPluginEvents.FailedToLoad` with a numeric SDK code, while `loadInterstitialAd(...)` rejects with `LOAD_FAILED` and the SDK message, and the `adFailedToLoad` event carries the numeric code for logging. Rewarded ads keep their shape. `prepareRewardVideoAd({ adId, ssv: { userId, customData } })` becomes `loadRewardedAd({ adUnitId, serverSideVerification: { userId, customData } })`, and the reward listener moves from `RewardAdPluginEvents.Rewarded` to `rewardEarned`. Banner code changes the most if it used `margin`; replace it with `mode: 'resize'` or pad your layout from `bannerSizeChanged`, and remember that the reported size is in CSS pixels. Finally, delete the app state listener that showed app open ads and call `enableAppOpenAutoShow(...)` once after `initialize()`. ## FAQ ### Is @capacitor-community/admob still maintained? Yes. As of October 19, 2026, the latest release is 8.2.1 from October 6, 2026, the repository had 23 open issues and 4 open pull requests, and the package is downloaded about 53,500 times per week. Its documentation site, per-pull-request beta builds and a native ads preview all indicate active development. The open question is its Android SDK generation, which stays on the legacy Google Mobile Ads SDK until the next major version. ### Is the Capacitor AdMob plugin free? No. The [Capacitor AdMob plugin](../../sdks/capacitor/admob.md) is part of the [Capawesome Insiders](../../insiders/index.md) subscription and is installed from the Capawesome npm registry with the license key that comes with it. `@capacitor-community/admob` is free under the MIT license. ### Can I run both plugins in one app? Not safely. Both plugins pull in the Google Mobile Ads SDK on each platform, but different generations on Android: `play-services-ads` 25.4.x versus `ads-mobile-sdk` 1.2.1. The community README asks you not to add a second Mobile Ads dependency, and two SDK generations in one Android build is exactly that. Migrate in one release rather than format by format. ### Do I have to migrate before June 2027? Not necessarily. Google's dates for the legacy Android SDK are June 30, 2027 for deprecation (ads still serve, no technical support) and June 30, 2028 for sunset (ads "at risk of not serving"). The community plugin's next major version is expected to move to the Next-Gen SDK, which is a rewrite of its Android layer and a breaking change for your code either way. Plan the migration, to whichever plugin, within that window. ### Does the Capacitor AdMob plugin support native ads? No. It supports banner, interstitial, rewarded, rewarded interstitial and app open ads. `@capacitor-community/admob` offers native ads as a preview with an API that may still change. If native ads are a requirement, that is a reason to stay on the community plugin for now. ## Ship Changes Without Review Replacing an ad plugin touches the native projects, so the first release after the switch needs a store submission. Every tweak after that, from a changed frequency cap to a new ad placement, is JavaScript, and Capawesome Cloud Live Updates can ship it to your users without another review. [Try Capawesome Cloud Free](https://capawesome.io){ .md-button .md-button--primary } ## Conclusion Stay on `@capacitor-community/admob` if your app needs native ads, attributes revenue per mediation partner, or runs on a budget that rules out a paid plugin; it is maintained and will move to the Next-Gen SDK in its next major version. Move to the Capacitor AdMob plugin if you want the Next-Gen SDK on Android now, if your banner layout fights with insets, or if the consent and app open code in your app has grown into something you would rather not own. Either way, schedule the Android migration before June 2027, when Google stops supporting the legacy SDK. [Announcing the Capacitor AdMob Plugin](./announcing-the-capacitor-admob-plugin.md) walks through the five ad formats and the banner modes in detail. If you have any questions, join us on the [Capawesome Discord server](https://discord.gg/VCXxSVjefW){:target="_blank"}. To stay updated on the latest news, subscribe to the [Capawesome newsletter](https://capawesome.io/newsletter/){:target="_blank"}.