I've been in the middle of a large-scale update cycle for my iOS apps this spring. Beautiful HD Wallpapers, Ukiyo-e Wallpapers, Relaxing Healing, and Law of Attraction Everyday — four apps, running in parallel, handling new iPhone resolution targets, and migrating Firebase SDK from CocoaPods to Swift Package Manager at the same time.
One task I'd been putting off was AdMob mediation optimization: adding Unity Ads, Liftoff, and InMobi as new partners. On paper it sounds manageable. In practice, it meant registering on each network's dashboard, adding adapter Pods, submitting W-8BEN tax forms for each, and adjusting ATT prompt ordering — all across four apps at once. I worked through this with Claude, and along the way hit a few undocumented pitfalls that I want to share here.
Why Add Three Mediation Partners Now
I've been building apps independently since 2014, with a cumulative download count that has passed 50 million across my catalog. For most of that time I ran AdMob alone. I knew adding more networks would improve eCPM, but the setup overhead kept it on the backlog.
The shift came when I started looking more closely at AppLovin MAX's optimization toggle. Traditional waterfalls require manually ordering floor prices. With the optimization toggle enabled, MAX dynamically reorders networks based on real-time eCPM — which means once you configure it, it mostly runs itself.
That made the math work. If I could set up the mediation configuration once and apply the same pattern across all four apps, the ongoing maintenance would be minimal. Getting that pattern right was where Claude came in.
The W-8BEN Submissions: Finding the Right Door
To receive payments from Unity Ads, Liftoff, and InMobi, you need to submit a W-8BEN form to each — the IRS certificate that establishes you as a non-US person and reduces withholding tax to 0%. The forms themselves aren't complicated, but finding where to submit them in each company's dashboard took longer than I expected.
Unity Ads routes through the Finance tab. Liftoff buries it several levels into the account settings. InMobi sends a link in a post-registration email. Each one is slightly different.
I asked Claude: "Walk me through where to submit W-8BEN for Unity Ads, Liftoff, and InMobi." It summarized the general navigation path for each and pointed me to their support documentation. The important caveat here — dashboard UIs change frequently, and Claude's training data may lag. So I treated the responses as directional guidance rather than step-by-step instructions to follow blindly.
For InMobi in particular, the navigation path Claude described didn't match the current UI exactly. But because I knew roughly where to look — Finance → Tax Information → W-8 Form — I found it without too much searching. That's the right way to use Claude for this kind of task: get your bearings, then navigate yourself.
ATT Prompt Ordering — The Trap That Doesn't Shout
The AppLovin MAX documentation does mention ATT prompt ordering, but it's easy to overlook on a first pass.
// ❌ Problematic order (SDK initializes before consent)
MobileAds.sharedInstance().start(completionHandler: nil)
ATTrackingManager.requestTrackingAuthorization { status in
// ads start without knowing consent status
}
// ✅ Correct order (ATT resolves first)
ATTrackingManager.requestTrackingAuthorization { status in
MobileAds.sharedInstance().start(completionHandler: nil)
}requestTrackingAuthorization must be called before initializing MobileAds. If you initialize the SDK first, it starts serving ads before it knows the user's consent status — which degrades targeting accuracy.
Two of my four apps had the ordering wrong. Both had been working for years, so I'd stopped questioning that part of the code. I showed the initialization sequence to Claude and asked it to check the ATT and MobileAds ordering — and it flagged the issue immediately.
This is a small thing, but it illustrates where Claude adds consistent value: reviewing code you've stopped looking at critically. My grandfather on both sides of my family were temple carpenters. Their approach was to inspect each joint carefully before moving on, even if they'd built the same structure a hundred times. I've taken that into how I review my own code — and Claude has become part of that inspection process.
AppLovin MAX Waterfall: 20 Groups, One Pattern
In AppLovin MAX, each ad unit has its own mediation configuration. Across four apps with multiple ad formats (banner, interstitial, rewarded), I ended up with close to 20 groups to configure.
I asked Claude: "What's the most efficient way to add Unity Ads across 20 MAX ad units?" It noted that MAX doesn't have a bulk editor in the dashboard, and suggested using CSV export to audit existing configuration before adding networks group by group.
What I hadn't fully understood was the difference between Bidding and fixed CPM network entries. Bidding-type entries participate in real-time auctions, so you don't set a floor price — but you do need to enable Bidding separately in the partner network's own dashboard. This two-dashboard coordination (MAX + Unity Ads, MAX + Liftoff, etc.) was the part that caused confusion early on.
Claude helped me map out which steps happened in which dashboard for each network. Once I had that mental model, the repetition across 20 groups became mechanical rather than uncertain.
All three partners are now configured as Bidding type with the optimization toggle on. I'm still in the monitoring phase, but eCPM movement has been positive in the first week.
The Pattern for Multi-App Updates
One practical lesson from running this across four apps: start with the most complex app.
I started with Beautiful HD Wallpapers. It has the most dependencies, and it was still in a mixed CocoaPods/SPM state during part of this update cycle. Adding AppLovin MAX SDK and three adapter pods had the highest potential for dependency conflicts.
I pasted the Podfile into Claude and asked: "Are there any dependency conflicts between AppLovin MAX and my existing Firebase setup?" It flagged a version constraint issue with the Firebase SDK that could have caused pod install to fail. Knowing about it in advance meant I could pin the correct versions before running the install.
After working out the pattern on the most complex app, I applied it to the remaining three with much less friction. That sequencing — most complex first, lateral expansion after — is now how I approach any change that needs to go into multiple apps.
Mediation Updates Are Invisible but They Compound
None of this work is visible to users. But eCPM improvements compound over time, and for an indie developer managing multiple apps alone, optimization tasks like this are easy to defer indefinitely.
Working alongside Claude lowered the cognitive overhead of juggling multiple dashboards, documentation sources, and code changes at once. Especially for W-8BEN submissions and SDK integration specifics, being able to ask the same clarifying question several different ways — without judgment — sped up my understanding.
My working pattern for SDK maintenance is now: Claude handles documentation navigation and code review; I make all the decisions and submit everything manually. That boundary has held up well across this update cycle.
If you're running a similar iOS mediation setup, I hope something in this account saves you a few hours.