A Next-Gen AdMob port lands on Android alone until Google ships an iOS build

The Gradle coordinate is what makes this a port. Google's successor ships as com.google.android.libraries.ads.mobile.sdk, a Kotlin-first library with a different API surface ^[4]. Capawesome, which sells the plugin and wrote the announcement, says that is why plugin authors have to port instead of bumping a version number ^[5].

A new coordinate also moves where version conflicts show up. The plugin exposes both dependency versions as Gradle project variables, so you can pin $adsMobileSdkVersion and $userMessagingPlatformVersion in variables.gradle when another plugin drags in a different version ^[8]. On Android it defaults to ads-mobile-sdk 1.2.1 ^[7].

The call shape is identifier-based. Every full-screen format uses the same two steps, a load method that returns an identifier and a show method that takes it, so porting one teaches you the other three ^[10]. Because each load hands back its own identifier, several ads can be in flight at once, and you can pass your own id rather than use a generated one ^[11]. Both rewarded formats accept a serverSideVerification option carrying userId and customData, forwarded to your verification callback ^[12].

Banners are where the port cost concentrates, because the banner is a native view sitting on top of a web view that knows nothing about it ^[15]. The plugin offers three placements ^[15]. Resize mode needs only the ad unit, a size and a position ^[16]. Inline placement makes your layout code responsible for the rectangle: you measure an anchor element with getBoundingClientRect(), pass the result as frame, and call setBannerFrame when the layout shifts ^[17]. The identifier returned by showBanner is what hideBanner, resumeBanner and removeBanner operate on ^[18].

App open ads get a shortcut, enableAppOpenAutoShow, which loads and shows one when the app returns to the foreground and stays quiet while a consent form or another full-screen ad is visible ^[13]. Its minInterval frequency cap defaults to 14400 seconds, which is four hours ^[13][1]. Every method is Android and iOS only and rejects with an unimplemented error on the web ^[14].

Everything above about Google's timetable comes from one vendor post promoting a paid plugin, and it is checkable against Google's own deprecation page in an afternoon. The dates reported are June 30, 2027 for deprecation of Android major versions 24 and 25, and June 30, 2028 for sunset, twelve months apart ^[2][2]. A sunset version is described as "at risk of not serving", while a sunset ad request is described as returning a no fill ^[3].

Capawesome's argument for acting now is a scheduling argument: two years sounds like plenty of runway, and does not survive a port landing in the same quarter as a store deadline, so starting a new monetization layer on a library with a published sunset date means paying for it twice ^[19]. That reasoning holds on Android. On iOS the plugin tracks the latest legacy Google Mobile Ads SDK, because Google has not shipped a Next-Gen variant for that platform yet ^[7].