How do I add AdMob to a Replit app without rejection?

When Replit Agent adds AdMob, the ads usually show up and the build runs, which is exactly why the rejection is a surprise. Ads pull in tracking and data collection, and that triggers a set of iOS privacy requirements the agent rarely wires up: a Privacy Manifest, the tracking prompt, an accurate privacy disclosure, and attribution identifiers. The fix is to add the privacy plumbing the SDK needs, not to change the ads. Here is the checklist that keeps AdMob from getting your app rejected.

Short answer

Adding AdMob usually works at runtime but gets rejected because ads trigger iOS privacy requirements the agent skips. You need the Google Mobile Ads SDK at a version that ships a Privacy Manifest, version 11.2.0 or higher, the App Tracking Transparency prompt with NSUserTrackingUsageDescription if you serve personalized ads, an App Privacy disclosure in App Store Connect that matches the SDK's data collection, and SKAdNetwork identifiers in Info.plist. App Review rejects when the declared privacy practices and the app's actual behavior do not match, so set all of these up before submitting.

What you should know

• Ads trigger privacy rules: AdMob collects data and can track, which brings Apple's privacy requirements into play.
• Privacy Manifest is mandatory: use a Google Mobile Ads SDK version that ships one, 11.2.0 or higher.
• Tracking needs the ATT prompt: personalized ads use the advertising identifier, which requires permission.
• The disclosure must match: your App Privacy answers have to reflect what the ad SDK actually collects.
• The agent skips this: generated code shows ads but rarely adds the manifest, the prompt, or the disclosure.

Why does adding AdMob cause rejections?

Because an ad SDK is a data-collection and tracking component, and Apple gates those. The moment AdMob is in your app, it can collect data and, for personalized ads, access the device's advertising identifier, which Apple treats as tracking. That brings four requirements into force at once, and App Review checks that your declared privacy practices match the app's real behavior. A Replit-built app typically renders the ads correctly while missing the Privacy Manifest, the tracking prompt, and the App Store Connect disclosure, so the app works but fails review on the mismatch between what it does and what it declares. The reviewer does not have to study your code to catch this, because the App Privacy answers, the presence of the tracking prompt, and the manifest are all things they can check directly, which is why the gap is caught so reliably.

What you must add for App Review

A short, non-negotiable set. The table lists each requirement, why it applies, and how to satisfy it.

How do you set it up in a Replit or Expo app?

Add the privacy keys and the prompt that the generated code left out. Use a current Google Mobile Ads SDK so its Privacy Manifest is included, and in an Expo project declare the iOS keys through app.json under ios.infoPlist: NSUserTrackingUsageDescription with a clear reason, and the SKAdNetworkItems list. In your code, request App Tracking Transparency authorization before you load personalized ads, and respect the result so a user who declines is served non-personalized ads instead. Then complete the App Privacy section in App Store Connect to match what AdMob collects, following Google's privacy strategies for iOS. The runtime SDK is the easy part; these declarations are what review actually checks. Treat the integration as two jobs: getting an ad on screen, which the agent already did, and declaring what that ad SDK does, which is the part still on you.

What about app-ads.txt and test ads?

Two practical extras. The app-ads.txt file declares your authorized ad sellers and is hosted on your developer website, not in the app, and while it does not block App Review, AdMob uses it to verify your inventory and protect ad revenue, so set it up in AdMob and publish it on your domain. Separately, use test ad units while developing and never tap your own live ads, because clicking your own ads is invalid traffic under AdMob policy and can get your AdMob account suspended, which is a different but equally painful failure than an App Store rejection.

What to watch out for

The first trap is assuming working ads mean a compliant app; the ads rendering says nothing about whether the Privacy Manifest, the tracking prompt, and the disclosure are in place. The second is a mismatch between your App Privacy answers and the SDK's real behavior, which is a direct cause of rejection. The third is shipping an app that is mostly ads with little real content, which runs into the minimum-functionality rule separately. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and can confirm the ad SDK is present with its Privacy Manifest and the tracking permission in place, so you catch a missing piece before review does.

What to take away

• AdMob gets rejected not because the ads fail but because the iOS privacy requirements are missing.
• Use Google Mobile Ads SDK 11.2.0 or higher for its Privacy Manifest, add the ATT prompt and NSUserTrackingUsageDescription for personalized ads, and add SKAdNetwork identifiers.
• Make your App Store Connect App Privacy disclosure match what AdMob actually collects, since a mismatch is a direct rejection cause.
• Set up app-ads.txt and use test ad units, and confirm the SDK and its privacy plumbing in the build with a pre-submission scan such as PTKD.com.