# A Godot AdMob plugin that copies the Google SDK shape instead of inventing one

> godot-admob-plugin wraps the Google Mobile Ads SDK for Godot 4.5 and later, in GDScript and C#, with editor mock ads and every ad format and mediation adapter exposed. It saves you the native bridge work, at the cost of a third party dependency in your ad revenue path.

**poingstudios/godot-admob-plugin** — Complete AdMob (Google Mobile Ads SDK) plugin for Godot. Supports GDScript and C#.

- Repository: https://github.com/poingstudios/godot-admob-plugin
- Website: https://poingstudios.github.io/godot-admob-plugin/
- Stars: 641 · Forks: 51
- Language: GDScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/poingstudios-godot-admob-plugin

## The API mirrors Google, which is the point of the wrapper

godot-admob-plugin is described as a complete AdMob plugin for Godot, supporting GDScript and C#, and the key feature line says it is designed to mirror the official Google Mobile Ads SDK structure, APIs and documentation.

That decision shapes everything else. If you have already written AdMob code for Android or iOS, the object names, the load and show split, the callback pattern and the unit id handling all read the way you expect, because they are modelled on the Google SDK rather than on a Godot specific convention. The plugin presents a MobileAds singleton that is globally available in any script after installation.

The alternative would be a Godot-flavoured API, and there are plenty of those in the engine plugin ecosystem. The cost of that route is that every developer who arrives from native AdMob has to unlearn a mapping. The cost of this route is that the plugin is tied to one ad network, so if your monetisation plan changes, this wrapper does not help you.

The repository layout matches a plugin that ships native code for two platforms: a platforms/ directory holds the Android and iOS pieces, scripts/ holds the tooling, docs/ the documentation source, and mkdocs.yml plus mkdocs.dev.yml two documentation build configurations. There is also an AGENTS.md, an .agents/ directory and a .gdlintrc, which tells you the project is set up for automated tooling and for AI coding assistants, a point the README makes explicitly with its AI-Agent Ready line.

## Two installation routes, and the editor plugin step

The recommended route is the Godot Asset Store. You open your project, go to the AssetLib tab, search for AdMob by Poing Studios, and download and install. There is also a manual path for custom releases: download the latest poing-godot-admob-v*.zip from the Releases page and extract it directly into your project's root folder, which is res://.

Either way there is a post-installation step that is easy to skip and hard to debug later. You have to enable the plugin in Project Settings under Plugins, then configure the required native dependencies for your target platforms, following the Android platform guide and the iOS platform guide.

That dependency step is the real work, and it is not optional. The plugin talks to the Google Mobile Ads SDK, and on mobile that SDK arrives as native libraries and framework pieces that have to be present in the exported build. The README adds a tip for when automated package downloads fail, or after you change your Godot Engine version: trigger the download manually from Project, Tools, AdMob Manager, then the platform, then Download and Install.

So there are three distinct steps and each one can fail in a different way: the plugin toggle, the native dependency configuration, and the actual package download. If an ad simply never appears in an exported build, the second and third steps are where to look first.

## Initialize once at startup, or nothing works

The first API call is the initializer, and the README is explicit that it must be called once during game startup before requesting any ads. In GDScript that is a single call in the ready function.

```gdscript
func _ready() -> void:
	MobileAds.initialize()
```

The C# side is the same call in the overridden ready method, with the API namespace imported.

```csharp
using PoingStudios.AdMob.Api;

public override void _Ready()
{
	MobileAds.Initialize();
}
```

The 1:1 parity between the two languages is a stated feature rather than an accident, and the examples are written as pairs so you can read the same logic in either. That is useful if your project is mixed, with GDScript for gameplay and C# for systems, since the type names and the flow stay aligned.

Note what is not in the examples: no configuration of the app id, no test mode toggle, no callback on initialization completing. The plugin is presenting the Google SDK surface, so anything beyond initialize is out of scope for the wrapper, which is another way of saying that the SDK itself remains the source of truth for behaviour.

## Loading a banner means unit id, size, position and a request

The banner example is the shortest complete flow in the documentation, and it shows the shape of the API. You create an AdView with a unit id, a size and a position, then load it with an AdRequest.

```gdscript
var ad_view: AdView

func _on_load_banner_pressed() -> void:
	var unit_id := "ca-app-pub-3940256099942544/6300978111" if OS.get_name() == "Android" else "ca-app-pub-3940256099942544/2934735716"
	ad_view = AdView.new(unit_id, AdSize.BANNER, AdPosition.TOP)
	ad_view.load_ad(AdRequest.new())
```

The unit ids in the example are the Google test ids, and the plugin selects between the Android and the iOS one based on the platform name. That is worth noting because it means the examples are safe to run against a real build, but it also means a project that copies the example verbatim will ship with test ads and no revenue until someone substitutes the real ids.

The C# equivalent names the same types with .NET casing, AdSize.Banner and AdPosition.Top, and calls LoadAd on the view. The difference in casing is a reminder that the two languages are separate implementations of one API rather than one generated from the other, so a rename on the Google side can land in one language before the other.

## Loaders and callbacks, the shape used by every full screen format

App open ads and interstitials use the same pattern, and it is worth reading once because it applies to every full screen format. You create a callback object, assign the failure and success handlers on it, then hand the callback to a loader along with the unit id and a request.

```gdscript
var app_open_ad : AppOpenAd
var app_open_ad_load_callback := AppOpenAdLoadCallback.new()
func _ready() -> void:
	app_open_ad_load_callback.on_ad_failed_to_load = func(ad_error: LoadAdError):
		print("Load failed: ", ad_error.message)
	app_open_ad_load_callback.on_ad_loaded = func(ad: AppOpenAd):
		app_open_ad = ad
func _on_load_app_open_pressed() -> void:
	var unit_id := "ca-app-pub-3940256099942544/9257395921" if OS.get_name() == "Android" else "ca-app-pub-3940256099942544/5575463023"
	AppOpenAdLoader.new().load(unit_id, AdRequest.new(), app_open_ad_load_callback)
```

Two details carry most of the design. Loading and showing are separate, and the ad object only exists after the success callback fires, so your show path has to check that the ad is present. And the failure callback gives you a LoadAdError with a message, which is the difference between an ad that never appears and one that fails for a reason you can log.

The interstitial example is identical in structure with InterstitialAd, InterstitialAdLoadCallback and InterstitialAdLoader. The app open format is described as meant for when users cold-start or return to the game, which is a policy decision about where you put the call rather than an API difference.

## Every Google format and mediation adapter, and mock ads in the editor

The format coverage is broad, and the README lists it as out of the box support for all Google ad formats and mediation adapters. The showcase table names them: banner, collapsible banner, interstitial, native, native video, rewarded, rewarded interstitial, UMP consent and the ad inspector.

UMP consent deserves separate mention. It is the user consent flow, and the consent string it produces is something you are expected to handle before requesting personalized ads, so a plugin that exposes it in the same API as the ad formats saves you from bolting on a separate consent library.

The feature that will save you the most time during development is editor mock ads. The README describes them as letting you test and preview ad layouts directly inside the Godot Editor. Building an ad placement, checking that the banner sits where you want it, and confirming the layout on a small and a large screen can all happen without a device, without a network call and without waiting for a fill.

That is not a small convenience. Ad placements are layout problems, and layout problems are much cheaper to fix in the editor than in an exported build on a phone.

The alternative approach, for teams who do not want a third party plugin in the loop, is to call the Google Mobile Ads SDK yourself through Godot's native plugin interface and write the bridge and the Godot bindings by hand. The difference in approach is real: that route removes the dependency and the version coupling, and it replaces them with the work of maintaining a bridge across Godot versions, two platform SDKs and a Google SDK that changes on its own schedule. This plugin takes the opposite trade.

## Versioning, nightlies and the upgrade question

The release history is worth reading carefully because it is not a simple series. The recent tags are v5.2.0-nightly.1b37d46a on 2026-10-18, a nightly build, v5.1.0 on 2026-09-13, and v1.3.8-godot3 on 2026-08-22.

Three things are visible there. Nightly builds are published, so a build you can install is always newer than the last stable tag. The Godot 3 line has its own tag, which tells you the plugin still carries support for an older engine generation. And the major version has reached 5, so the API has been reshaped several times since the beginning.

The repository is not archived and the last push was on 2026-10-18. The README states a floor of Godot 4.5.0 for native support on Android and iOS.

The licence is MIT, with the text in the LICENSE file, which is permissive and does not impose anything on games that use the plugin. For a plugin that sits in the revenue path of a shipped app, the thing to weigh is not the licence but the upgrade cadence: a plugin that tracks a Google SDK release cycle will need attention when Google changes, and the changelog is the place to see what a new major version changed before you adopt it.

## Conclusion

Adopt godot-admob-plugin if you ship a Godot 4.5 or later game on Android or iOS, want AdMob without writing your own native bridge, and value having the Google SDK API shape mirrored in GDScript or C#. Do not adopt it if you need formats or mediation adapters outside Google Mobile Ads, or if you cannot accept a third party plugin sitting between your game and the ad SDK. Before you ship, run the editor mock ads and then the Google test unit ids, confirm the native dependency step in Project Settings has completed for both platforms you build, and read the platform guides for Android and iOS before you rely on the AdMob Manager download path.

## FAQ

### How do I install the godot-admob-plugin?

The recommended route is the Godot Asset Store: open the project, go to the AssetLib tab, search for AdMob by Poing Studios, then download and install. For custom releases you can download the latest poing-godot-admob-v*.zip from the Releases page and extract it into the project root folder, res://.

### What do I have to do after installing the plugin?

Enable it in Project Settings under Plugins, then configure the required native dependencies for your target platforms using the Android and iOS platform guides. If automated package downloads fail, or after a Godot Engine version change, you can trigger them from Project, Tools, AdMob Manager, then the platform, then Download and Install.

### Does godot-admob-plugin support both GDScript and C#?

Yes. The README describes 1:1 GDScript and C# parity for Godot 4.5.0 and later, and each example in the documentation is given in both languages, with the C# side using the PoingStudios.AdMob.Api namespace.

### Which ad formats does the plugin support?

The README lists support for all Google ad formats and mediation adapters out of the box, and the showcase covers banner, collapsible banner, interstitial, native, native video, rewarded, rewarded interstitial, UMP consent and the ad inspector.

### Can I test ads without building for a phone?

Yes. Editor mock ads are a listed feature, letting you test and preview ad layouts directly inside the Godot Editor before you build.

## Sources

- [License: MIT](https://github.com/poingstudios/godot-admob-plugin/blob/master/LICENSE)
- [poingstudios/godot-admob-plugin on GitHub](https://github.com/poingstudios/godot-admob-plugin)
- [Project website](https://poingstudios.github.io/godot-admob-plugin/)
- [README](https://github.com/poingstudios/godot-admob-plugin/blob/master/README.md)
- [Releases](https://github.com/poingstudios/godot-admob-plugin/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/poingstudios-godot-admob-plugin