Monetizing iOS Apps with Ads in 2026: A Step-by-Step Tutorial

In-app purchases are not the only way to make money from an iOS app — and for many apps they are not even the best way. Utilities, content apps, and casual games with a free user base monetize through ads: banners, interstitials, rewarded videos, native placements, and app-open units. In 2026 the standard stack is well established — AdMob's Google Mobile Ads SDK, Apple's App Tracking Transparency (ATT) prompt, and SKAdNetwork for attribution. This tutorial walks through the whole setup, from account creation to App Store compliance, grounded in Google's and Apple's official documentation.

Why ads, and where they fit

Ads monetize users who will never pay, and they complement IAP rather than compete with it. A well-placed rewarded ad can even increase IAP revenue by offering currency or premium features in exchange for a video view. The common patterns are: ads-only for utility and content apps, hybrid (ads plus IAP) for games, and subscription-plus-ads for media apps. Before writing any code, decide which pattern fits your audience — it determines the ad formats you integrate and the user flows you design around them.

Step 1: Choose your ad formats

The Google Mobile Ads SDK for iOS supports five main formats, each with a different trade-off between revenue and user friction:

Banner — a persistent strip, typically at the bottom or top. Lowest eCPM, but always visible and the least intrusive.
Interstitial — a full-screen ad shown at natural breakpoints (level completion, between articles). Higher revenue per view; be disciplined about frequency to avoid churn.
Rewarded — the user opts in to watch a video in exchange for a reward (extra lives, premium features, credits). Highest engagement and the format users resent the least, because it is their choice.
Native — ads styled to match your app's design. Best for content feeds where a banner looks out of place.
App open — a full-screen ad shown at launch. Good incremental revenue for apps opened frequently, but it can hurt first-impression ratings if overused.

Most successful implementations start with rewarded plus a light interstitial, then add app-open after launch data shows users return often.

Step 2: Create an AdMob account and register your app

AdMob runs on your Google account — sign in at admob.google.com and add your iOS app. The console assigns you an AdMob App ID (formatted like ca-app-pub-XXXXXXXXXXXX~YYYYYYYYYY) and lets you create ad units, each with its own ID. You will need the App ID for your Info.plist and the ad unit IDs in code. Registering the app first also makes the next steps concrete — the SDK's initialization and the AdMob dashboard are linked to that App ID.

Step 3: Integrate the Google Mobile Ads SDK

Per Google's official quick-start guide, the current requirements are Xcode 16.0 or higher targeting iOS 12.0 or higher, with the SDK imported via Swift Package Manager, CocoaPods, or manual download. Three integration details are worth getting right the first time:

Import and initialize early — import GoogleMobileAds and call GADMobileAds.sharedInstance().start() in your app's launch path, before the first ad request.
Linker flags — the official guide calls for the -ObjC flag in Other Linker Flags (when not using Swift Package Manager).
Swift runpath — add /usr/lib/swift to Runpath Search Paths for projects that need it.

Once initialized, request ads through the format classes (GADBannerView, GADInterstitialAd, GADRewardedAd, and so on), each fed by its ad unit ID.

Step 4: Configure Info.plist — the two keys that unlock everything

Google's quick-start is explicit about what your Info.plist must contain before ads will serve:

GADApplicationIdentifier — a string value holding your AdMob App ID. Without it the SDK refuses to load ads.
SKAdNetworkItems — an array of SKAdNetworkIdentifier entries, starting with Google's own cstr6suwn9.skadnetwork plus the identifiers of the third-party buyers you use.

The second key is what makes attribution work in the post-IDFA era. Apple's SKAdNetwork framework lets ad networks attribute installs without seeing the device's advertising identifier, and Google's privacy documentation states that the Mobile Ads SDK supports conversion tracking through SKAdNetwork even when the IDFA is unavailable.

Step 5: Handle App Tracking Transparency (ATT) properly

Since iOS 14.5, apps that access the advertising identifier (IDFA) must first ask permission through the ATT prompt. Getting this wrong is the #1 source of both review rejections and quietly broken ad revenue:

Add NSUserTrackingUsageDescription to Info.plist with a plain-language explanation of why you track (for example, "to show personalized ads and measure ad performance").
Call ATTrackingManager.requestTrackingAuthorization at a natural moment — usually right after onboarding or when the first rewarded/interstitial is about to appear — not at the very first app screen.
If the user denies, the IDFA comes back as all zeros. That is not a failure: Google's privacy strategies guide confirms the SDK continues to work and relies on SKAdNetwork for conversion tracking. Build your analytics expectations around that reality instead of treating denial as an error state.

Design tip: the ATT prompt converts best when the user understands the value. If your app is ad-funded and free, say so in the prompt copy — "This app is free because it shows ads" is a more honest and effective message than a generic tracking disclaimer.

Step 6: Test before you ship

AdMob provides test ad unit IDs that return sample ads, and the SDK lets you register your device as a test device so real ads never load during development. Testing matters for two reasons: it validates that each format renders and its callbacks fire correctly, and it protects you from invalid activity — real ad requests made by your own test sessions can get your account flagged. Run a full pass with every format you plan to ship: banner render, interstitial load and dismiss, rewarded completion callback, and app-open timing.

Step 7: Stay compliant on the App Store

Ad monetization triggers App Store requirements you must complete before submission:

App Privacy labels — Apple's App Privacy Details require you to declare data collection. An ad-supported app that uses the advertising identifier must declare "Advertising" as a data type and "Third-Party Advertising" as a purpose. Inaccurate labels are a common review rejection reason.
Kids category restrictions — apps targeting children face strict limits on ads and tracking under the App Review Guidelines; third-party ad SDKs are generally not permitted in the Kids category. If your app is kid-oriented, ads are usually not a viable model.
Payment thresholds — AdMob holds earnings until you cross the minimum payment threshold for your country, visible in the Payments section of your AdMob account. Plan cash flow accordingly for the first few months.

Bonus: Apple Search Ads as a growth channel

Advertising your app inside the App Store is the natural companion to in-app ad monetization. Apple Search Ads places your app at the top of relevant search results and charges per tap, with campaigns by keyword and audience. The two systems fit together cleanly: Search Ads grows installs, and in-app ads monetize the users those installs bring — including re-engaging them with rewarded placements.

The one-line version

Ad monetization on iOS in 2026 is: pick your formats, register the app in AdMob, integrate the Mobile Ads SDK (Xcode 16+, iOS 12+), put GADApplicationIdentifier and SKAdNetworkItems in Info.plist, handle the ATT prompt honestly, test with test ad units, and declare advertising in your App Privacy labels. The frameworks are mature and the documentation is exact — the apps that fail are the ones that skip a key, hide the tracking prompt, or treat denied ATT as a disaster instead of a normal outcome.