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 scaffolds Google AdMob by default. It's the most widely used mobile ad network, it pays out reliably, and its keys are publishable - meaning they're safe to embed directly in your app. You connect AdMob once in Dashboard → Connectors → AdMob, and every project in your account can use it.

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.
• Rewarded. The user opts in to watch a short video in exchange for something - extra lives, a hint, a day of premium features. The friendliest format because the user chooses it, and it usually earns the most per view.

"Add a banner ad pinned to the bottom of the feed screen, and a rewarded ad that gives the user 50 coins when they finish watching it. Don't show ads to users on a paid plan."

The agent wires the placements, the load-and-show logic, and the reward callback. That last line in the prompt matters: a common pattern is to show ads only to free users and hide them once someone pays.

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. So AdMob sits in the "just connect" tier of connectors - connect once and the agent embeds the IDs wherever the app needs them. There is no relay and no server-side key. (Contrast this with the secret-key services like OpenAI or Twilio, which can never be bundled and call through a small server-side relay instead. 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.

1. Go to apps.admob.com and sign in with a Google account.
2. 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.
3. Create your ad units. Add one ad unit per placement you plan to use (a banner unit, an interstitial unit, a rewarded unit). Each one gets its own ad-unit ID.
4. Copy the App IDs and ad-unit IDs into Dashboard → Connectors → AdMob. Connect once and every project in your account can 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."

The agent will set the code up to switch automatically, so your test devices never touch the live units.

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.
• Appsanic wires this string in for you automatically when AdMob is connected, so you don't have to remember it. You can customise the wording - keep it truthful about using tracking to show relevant ads.

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

You publish through Appsanic: connect your store account, click Publish, and Appsanic builds the release in the cloud with EAS and uploads it to your TestFlight / Play internal testing track for you. Publishing through Appsanic is rolling out, so it's being finalised. The App Tracking Transparency string and the Google Play ads declaration above happen in that build and submission - the string is wired into the build, and the Play ads declaration is a checkbox you tick in the Play Console when you submit for review.

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 generated app uses Google's mobile ads SDK via react-native-google-mobile-ads. Because it's a native module, ad components render only in development and production builds; the preview substitutes a labelled placeholder component of the same dimensions.
• App IDs and ad-unit IDs are read from your AdMob connector and inlined into the app config and components - they're publishable, so there's no .env file and no relay involved (an exported project has no .env by design; publishable keys are inlined in the code).
• iOS permission strings live in the app config under ios.infoPlist (NSUserTrackingUsageDescription); the App Tracking Transparency request is made through expo-tracking-transparency before personalised ads load.
• A test-vs-production switch keys off the build profile so development builds load AdMob's test ad-unit IDs and production builds load your real ones.
• Styling and structure follow the standard exported stack - StyleSheet plus theme.ts, screens under screens/, state in Zustand. See Editing Exported Code.

Next

Read SMS verification to add phone-number sign-in and one-time codes.