Ads & Monetisation
There are two ways an app makes money: you charge the user, or you show ads. This page is about ads. If you want to charge users (subscriptions, one-off purchases, paywalls), that's a different connector and a different doc - see Payments.
For ads, the agent can scaffold Google AdMob placeholders. Its App IDs and ad-unit IDs are publishable, but connecting them does not install the native SDK, configure consent, or prove ads can serve.
Ad formats
AdMob gives you a few shapes of ad. Pick the one that fits where it sits in your app.
- Banner. A small strip, usually pinned to the top or bottom of a screen. The least intrusive format and the easiest to live with. Good for content screens people sit on for a while.
- Interstitial. A full-screen ad shown at a natural break - between levels in a game, after a user finishes a task, on a screen transition. Powerful, but easy to overuse. Show one too often and users uninstall.
"Add a banner placeholder at the bottom of the feed and mark an interstitial break after a completed task. Hide both for paid users."
The current connector accepts banner and interstitial IDs. Rewarded ads are not represented in the form and require additional native work after export.
Public IDs, safe to embed
AdMob uses two kinds of identifier, and both are designed to live in your app's code:
- An App ID - one per app, per platform (so one for iOS, one for Android).
- Ad-unit IDs - one per placement (your bottom banner, your level-end interstitial, and so on).
These are publishable. They are not secrets, they don't let anyone spend your money, and embedding them in the app is exactly how AdMob is meant to work. AdMob therefore needs no relay or server-side key. Secret-key services such as OpenAI or Twilio need a separately deployed backend whose runtime secret you provision yourself. See Connectors Overview.
What you'll see in the preview vs a real build
This is the part people trip over, so it's worth being plain about it.
Real ads need a native ad SDK that the Expo Go preview can't load. So in the Expo Go preview, the agent renders a clearly-labelled placeholder box where each ad would go - same size, same position, marked as a placeholder. Your layout looks right and you can build around it, but no real ad is fetched.
Real ads only render in a development build or a production build - the kind you create with EAS once your project is exported. That's by design, not a limitation to work around. Treat the preview as a layout tool for ads, and verify the real thing in a development build on a device.
Setting up the AdMob console
Before the IDs exist, you create them in Google's AdMob console. It takes about ten minutes the first time.
- Go to apps.admob.com and sign in with a Google account.
- Create an app in the console - one entry for iOS and one for Android if you're launching on both. AdMob gives you an App ID for each.
- Create your ad units. Add a banner or interstitial unit for each placement represented by the current connector. Each gets its own ad-unit ID.
- Open the Appsanic project build, select Connectors → AdMob, and enter the App IDs and ad-unit IDs. Connect each project that should use them.
Use test ad-unit IDs while you build
This is the single most important rule with AdMob, so do not skip it. While you're developing, use AdMob's test ad-unit IDs, never your real ones. Google provides dedicated test IDs that always serve a safe sample ad.
Tapping or repeatedly loading your real ad units during development looks exactly like click fraud to Google's systems, and it can get your AdMob account suspended - which means losing the ability to earn at all. Tell the agent which environment you're in:
"Use AdMob test ad-unit IDs in development and my real ad-unit IDs only in production builds."
After export, configure the native SDK to use Google's documented demo units in development and production IDs only in release builds. Review that switch before running either build; the preview never loads an ad.
iOS App Tracking Transparency (ATT)
On iOS, personalised ads rely on tracking the user across apps, and Apple requires you to ask permission first through the App Tracking Transparency prompt. Two things follow from that:
- Your app must include a short, honest explanation string (
NSUserTrackingUsageDescription) telling the user why you want to track. Apple rejects builds that request tracking without one. - Add this string during the exported native setup if you request tracking. Appsanic leaves it in the
SETUP REQUIREDchecklist; connecting IDs alone does not add or approve the wording.
If the user declines the prompt, ads still show; they're just non-personalised and typically earn a little less. That's the correct, compliant behaviour, so don't try to nag the user into accepting.
"Show the App Tracking Transparency prompt the first time the user opens the app, and keep showing ads either way."
Google Play ads declaration
When you submit your Android app to the Play Console, Google asks one direct question on the App content page: does your app contain ads. If you use AdMob, the answer is yes - tick it. Getting this wrong (saying no while you actually run ads) is a policy violation that can pull your listing. There's nothing for Appsanic to set here; it's a checkbox you tick yourself at submission time, so make a note of it for when you publish.
A note on how you actually publish
Native ads require an exported development build before release. Install and configure the ads package, use demo units, test consent and ATT on devices, and only then enable production units. The Google Play ads declaration remains a checkbox you complete in Play Console.
Prefer to drive it yourself? You can instead export your project to GitHub and run EAS from your own repo (eas build, then eas submit). That fallback is always available, and the same App Tracking Transparency string and Play declaration apply.
Under the hood (for engineers)
- The preview uses labelled React Native placeholders. It does not import
react-native-google-mobile-ads, initialise the SDK, or fetch demo/real ads. - A
SETUP REQUIREDblock explains how to install the native package, add publishable IDs to app configuration, configure consent/ATT, and make a development build. - Treat build-profile switching between Google's demo units and production units as code you must review and test after export, not as a consequence of connecting the IDs.
- Styling and structure follow the standard exported stack - StyleSheet plus
theme.ts, screens underscreens/, state in Zustand. See Editing Exported Code.
Next
Read SMS verification to add phone-number sign-in and one-time codes.