Adding AppLovin MAX to a Rork-Generated iOS Project — A Field Note on Init Order, ATT Consent, and eCPM A/B Testing

Aligning the ATT prompt with AppLovin's consent flags

After ATT resolves, you also need to relay the user's consent state into AppLovin via ALPrivacySettings. The minimum set is hasUserConsent, isAgeRestrictedUser, and isDoNotSell. I treat ATT.authorized as hasUserConsent = true and everything else as false, then override with the Google UMP CMP result for EEA traffic.

func syncPrivacySignals(att: ATTrackingManager.AuthorizationStatus, isEEA: Bool) {
    let consent = (att == .authorized)
    ALPrivacySettings.setHasUserConsent(consent)
    ALPrivacySettings.setDoNotSell(!consent)
    ALPrivacySettings.setIsAgeRestrictedUser(false)
 
    if isEEA {
        let cmp = CMPStore.shared.latestPurposes
        ALPrivacySettings.setHasUserConsent(cmp.consentForPurpose1)
    }
}

The gotcha I hit: if you only call syncPrivacySignals once during initialization and never again after ATT resolves, AppLovin sits with stale false flags. In my first pass, that left rewarded fill from AppLovin pinned to the low-eCPM non-personalized bucket for users who had actually granted ATT. Calling syncPrivacySignals both inside the MAX init completion and again right after the ATT callback (a double-guard) made the issue disappear.

Running MAX as an AdMob mediation adapter, not as a takeover

There is a meaningful operational difference between treating AppLovin MAX as your "main mediation server" and treating it as one adapter inside AdMob mediation. They can look similar in the SDK, but the day-to-day work differs.

Because my wallpaper apps already run multiple networks through AdMob mediation, switching to MAX-as-primary all at once felt like too much risk. I started with MAX added as a bidding adapter inside AdMob mediation, attached to the existing ad units. The bidding group fills faster than waterfall, but reconciling AppLovin's dashboard numbers against AdMob's reports adds operational overhead. My pragmatic sequence: drop MAX into the waterfall with a conservative floor for the first week, observe behavior, then promote to bidding once nothing is on fire.

If you ship the same app on both App Store and Google Play, doing iOS first and then mirroring the configuration to Android lets you internalize the AppLovin dashboard workflow before doubling the surface area.

Minimal A/B setup to actually compare eCPM

Running the two networks in parallel is only useful if you collect comparable numbers. The minimum viable setup I landed on is Firebase Remote Config plus AdMob floor configuration, splitting users into two cohorts:

• A cohort: existing AdMob-only setup
• B cohort: AdMob mediation with AppLovin MAX added as a bidding adapter

Remote Config delivers an ads_variant value of A or B, and AdsBootstrap only initializes the AppLovin SDK for B. I also pair each variant with separate ad units on the AdMob side, and write ads_variant into Crashlytics as a custom key so I can break crash-free rates by cohort.

let variant = RemoteConfig.remoteConfig().configValue(forKey: "ads_variant").stringValue ?? "A"
Crashlytics.crashlytics().setCustomValue(variant, forKey: "ads_variant")
 
if variant == "B" {
    AdsBootstrap.shared.startAfterActive()
} else {
    AdMobOnly.shared.startAfterActive()
}

For a solo developer, runtime switching inside a single binary is a much better trade-off than shipping two builds. App Store review only happens once, and binary size stays under control.

The four metrics I track during the experiment:

1. eCPM per 100 impressions (USD)
2. Fill rate against requests (%)
3. Crash-free rate via Crashlytics (Day 1 and Day 7)
4. Time from process launch to first banner display (seconds, with a custom trace)

Two weeks of observation is usually enough to see whether eCPM differences fall outside noise. If the deltas are real, you can confidently promote bidding or rebalance the cohort split. If the deltas look like noise, the responsible move is to plan the rollback.

Quieting the "blank banner on launch" pattern

A common regression right after adding AppLovin MAX is that banner requests during the first 2 to 3 seconds of launch fail to fill. With AdMob alone you may never have seen this, but mediation adapter initialization shifts the timing slightly and exposes the gap.

The fix I now use is to defer instantiating the ad view at all until AdsBootstrap.isReady is true. On the React Native side, the hook is essentially a suspense-style wait:

import { useEffect, useState } from 'react';
import { NativeEventEmitter, NativeModules } from 'react-native';
 
const emitter = new NativeEventEmitter(NativeModules.AdsBootstrap);
 
export function useAdsReady() {
  const [ready, setReady] = useState<boolean>(false);
 
  useEffect(() => {
    NativeModules.AdsBootstrap.isReady().then(setReady);
    const sub = emitter.addListener('AdsBootstrapReady', () => setReady(true));
    return () => sub.remove();
  }, []);
 
  return ready;
}

Components that render banners read const ready = useAdsReady() and show a placeholder while ready === false. The before version requested an ad on mount; the after version waits for ready and only then requests. Eliminating the "blank box for 1.5 seconds" also fixes the layout jump that comes from late-arriving ad views.

Triaging the first crashes that show up via Crashlytics

Within the first three days of running MAX in parallel, a small number of AppLovin-related stack traces appeared in Crashlytics. Most were the usual "listener torn down in the wrong order around rewarded ad close" pattern, but distinguishing them from AdMob-side crashes is much easier thanks to the ads_variant custom key.

I opened a Claude in Chrome session and asked it to read the Crashlytics dashboard, pull only stack traces tagged ads_variant=B, summarize the top three signatures, and cross-reference each one with AppLovin's published known-issues. Doing that interactively through a single agent session compressed roughly an hour of manual dashboard hopping into about fifteen minutes. The agent can also screenshot the AppLovin dashboard and produce a small table of top-three regional eCPM and fill rate for the week, which kept the operational overhead from eating into actual coding time.

Rewarded ads: same AdMob API, different normalization needs

Beyond banners and app-open, I also routed rewarded ads through AdMob mediation into AppLovin MAX. The GADRewardedAd API itself is abstracted by AdMob, so the call sites stay the same. What does change is that AppLovin needs its own rewarded placement configured in its dashboard, and the GADAdReward payload that comes back is not perfectly normalized between networks.

In my first integration, AppLovin-routed rewards arrived with amount = 0 in a small percentage of cases. For an app where the reward feeds a game-like loop, that is a real risk of either zero-grant or double-grant bugs. The safe pattern is to add a normalization layer that clamps to your own sane defaults.

rewardedAd.present(fromRootViewController: vc) { [weak self] in
    let raw = rewardedAd.adReward
    let amount = max(1, raw.amount.intValue)
    let type = raw.type.isEmpty ? "coin" : raw.type
    self?.rewardLedger.grant(amount: amount, type: type, source: variant)
}

The lesson from the field: every time you add a mediation network, also add a normalization layer for reward payloads.

Realistic solo-developer time budget and a rollback plan

Bringing this back to the practical level, adding AppLovin MAX is not technically hard, but the three-axis cost (init order, consent flags, parallel operation) is real. For the iOS build of Beautiful HD Wallpapers, my elapsed engineering time from design to two-week A/B observation was roughly 18 to 22 hours. That is achievable in part because Rork already gave me a working skeleton; writing the same ad layer fully by hand would likely have doubled that.

Plan the rollback before you plan the launch. I wired ads_variant so that flipping Remote Config to A for everyone effectively disables AppLovin MAX without a store update. If crash-free rate slides or eCPM moves in the wrong direction, I can revert in minutes rather than waiting for review. That safety valve matters a lot for indie developers who do not have a team to cover for them.

The real work is not adding the SDK. It is staying disciplined about the data you collect and giving yourself room to pull back when the numbers do not justify the operational overhead. After twelve years of solo app work, I have come to value experiments whose exits are as well-defined as their entries.

Thanks for reading. I hope this is useful to others walking the same path.