react-native-google-mobile-ads, the AdMob wrapper with a generated API reference

A native SDK wrapper, with the native SDK's surface

React Native Google Mobile Ads lets you monetize an app with Google AdMob or Google Ad Manager, and the mechanism is stated plainly: it wraps the native Google Mobile Ads SDKs for iOS and Android. There is no JavaScript ad rendering, no custom ad server and no approximation of the native behaviour. What you get is a bridge to the real SDK, which means the ad formats, the mediation and the consent flow are the ones Google ships rather than something reimplemented in JavaScript.

The format list in the README is long enough to be the real argument for using the wrapper. It covers app open, banner, native, interstitial, rewarded and rewarded interstitial, plus Ad Manager, consent with UMP and mediation. The ad format documentation goes deeper on the banner family, because that is where the decisions are. Anchored adaptive banners are full-width and auto-height, expected to be always on screen and locked to the top or bottom. Inline adaptive banners are larger, of variable height, and can be as tall as the device screen, intended for scrolling content. Collapsible banners exist to improve the performance of anchored ads that are otherwise a small size. And the fixed size legacy catalogue is still documented, with banner at 320x50, large banner at 320x100, medium rectangle at 300x250, full banner at 468x60 and leaderboard at 728x90, for the cases where adaptive does not fit.

The distinction between anchored and inline adaptive is the one that catches people out, because the same API serves both and the difference is about where the banner lives in your layout. A banner that is expected to be always on screen is anchored; a banner that scrolls with your content is inline. Getting that backwards is why a banner sometimes appears in the wrong place.

Beyond banners, native ads let you control the look and feel of the ad so the layout matches your app, interstitials are full-page ads meant for natural breaks and transitions such as after level completion, and the rewarded formats pay for engagement. The difference between rewarded and rewarded interstitial is a policy requirement rather than a technical one. Users do not opt in to view a rewarded interstitial, and Google requires an intro screen with clear reward messaging and an option to skip before the ad shows.

Expo first, but the CLI path is a first class citizen

The installation story is where most React Native ad modules are thin, and this one is not.

The quick start is a single command:

npx expo install react-native-google-mobile-ads expo-dev-client

The expo-dev-client part is not incidental. The README states that the module does not run in Expo Go, and that after adding your AdMob App IDs to the config plugin in app.json you create a development build. Expo Go cannot load a module that links against a native SDK, so a custom development build is the minimum, and that is a real setup step for a team that has been living in Expo Go.

The configuration itself goes into the Expo config plugin, which is where the App IDs live:

{
  "expo": {
    "plugins": [
      [
        "react-native-google-mobile-ads",
        {
          "androidAppId": "ca-app-pub-xxxxxxxx~xxxxxxxx",
          "iosAppId": "ca-app-pub-xxxxxxxx~xxxxxxxx"
        }
      ]
    ]
  }
}

Putting the IDs in app.json rather than in a native file means they travel with the project and are applied by the build rather than by hand, which is the kind of thing that goes wrong on a machine that is not the developer's.

Bare React Native CLI apps are fully supported, and the README points those at a separate install page. The three steps it gives for the whole flow are: gather consent, initialize the SDK, and show your first ad. Consent comes first for a reason, since in the markets where the GDPR and its equivalents apply, showing an ad before consent is a compliance problem rather than a bug.

Imperative classes, hooks and preload pools

The React-friendly part of the design is described as imperative ad classes, React hooks, and preload pools for apps that show many ads, and the third of those is the interesting one.

Most ad integrations expose a component that renders an ad and fires callbacks. That works for a banner that lives on screen. It does not work well for a rewarded ad, where the flow is: the user taps a button, you show a rewarded video, the user watches it, you grant a reward. If the ad has to be fetched at the moment of the tap, there is a loading delay in the middle of a direct response to a user action, and on a slow connection that reads as a broken button.

A preload pool solves that by fetching ads ahead of time and handing one over instantly when the moment arrives. For an app that shows rewarded ads often, that difference is the difference between a smooth flow and a janky one, and it is why the library treats it as a first class feature rather than an optimisation.

The three ways of calling the library cover the three ways people write React Native. Imperative classes work well when the ad lifecycle is tied to something outside React, for example a game loop or a navigation event. Hooks fit components that mount and unmount with the screen. And the combination, imperative class plus hook, is the pattern the documentation describes for the common case where you need to preload in one place and consume in another.

The library is written in TypeScript and the README notes it is typed and tested, with unit and end to end tests on both platforms, and a generated API reference published at the invertase.github.io address.

A monorepo where the reference is generated, not written

The repository layout tells you that this is not a single package but a workspace with a build system.

The root package.json is named react-native-google-mobile-ads-monorepo and is marked private with version 0.0.0, which is the standard marker for a workspace root. The workspaces array covers packages/*, RNGoogleMobileAdsExample and tooling/*, so the published package, the example application and the build tooling all live in one tree. There is a lerna.json, an nx.json and a yarn.lock, so the build is Lerna on top of Nx with Yarn as the package manager, and there is a.yarn/ directory and a.yarnrc.yml.

The API reference is generated. The script reference:api runs typedoc, and reference:api:gh-pages runs typedoc with a hostedBaseUrl pointing at the invertase.github.io address, with a typedoc.json in the root to configure it. A generated reference has one property that matters more than accuracy: it cannot drift from the code. A hand written API page for a library this size would fall behind, and the README's claim that it is a generated API reference is the answer to that.

The linting setup is the part that shows how the native side is treated. lint:js runs eslint over the core source with --max-warnings=0. lint:android finds the Java sources outside the generated directory, pipes them through google-java-format with --set-exit-if-changed and then checks git diff to fail if the formatter changed anything, which is the standard way to make a formatter part of CI rather than a suggestion. lint:ios:check runs clang-format with the Google style over the Objective-C and C++ sources with -Werror, and there is a matching lint:ios:fix.

There is also a codecov.yml, an eslint.config.js, a jest.config.js with a jest.setup.ts, a babel.config.js, a Gemfile, a type-test.tsx, a.spellcheck.dict.txt and an llms.txt, which is a convention for making a repository's documentation readable by language models.

What the module does not do for you

The gaps are mostly the ones you would expect, and they are worth pricing in before you commit.

First, there is no ad serving. The module talks to AdMob and Ad Manager, so you need an AdMob account, app IDs for each platform, and ad units configured on the Google side. The config plugin takes the App IDs, not the ad unit IDs, and the ad unit identifiers are the ones you write in your own code. Ad Manager and mediation are supported, so you are not locked to AdMob inventory, but you still need accounts with whoever you mediate through.

Second, consent is a flow you have to drive. The library gives you the UMP pieces and the README lists gather consent as the first step of getting started, but a consent form that reflects your own data practices and your own vendor list is your legal responsibility, not the library's.

Third, this is a native dependency in a project that may otherwise be all JavaScript. That means the Expo Go path is closed, a development build is required, and CI needs a native build step. For a team that ships a native app anyway that cost is small. For a team proving an idea, it is the dominant cost.

Fourth, the repository's own licence field is not classified by GitHub, while the package.json inside declares Apache-2.0. If you are running a licence audit in your build, read the LICENSE file in the repository root rather than trusting either field, because they disagree about the classification.

On maintenance, the project is clearly active. The last push was on 2026-10-15, four days before this article was written, and the release tags are v17.2.0 from 2026-09-25, v17.1.0 from 2026-09-23 and v17.0.0 from 2026-09-18, which is a steady release cadence within September. The repository also carries a CHANGELOG.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, an AGENTS.md and a Gemfile, and the documentation site is at react-native-google-mobile-ads.dev.

Editorial conclusion

react-native-google-mobile-ads suits a React Native app that needs to show real AdMob inventory, since the module tracks the native SDK closely and covers consent and mediation rather than just banners, and it suits an Expo project because the config plugin removes the manual native wiring. It is the wrong choice for a prototype that only needs to prove the idea, since the native dependency, the App IDs and the development build requirement add real setup. Before adopting it, note that the module does not run in Expo Go, so you need a development build, and check the licence in the repository root, because the package metadata declares Apache-2.0 while the repository's own licence field is not classified.

Frequently asked questions

Official sources

1. invertase/react-native-google-mobile-ads on GitHub
2. Issues
3. Project website
4. README
5. Releases