Protecting Ad eCPM in Your Rork Max App: Designing ATT Pre-Permission Priming

The System ATT Dialog Fires Once, So Design the Ask

The system ATT dialog has a constraint that trips up developers: you effectively get one shot. Once a user picks "Ask App Not to Track," you cannot re-present it from inside the app — you can only send them to Settings.

That is why firing the system dialog immediately is a poor move. A permission request that appears with no context gets reflexively rejected. The fix is pre-permission priming.

Think of it as three steps.

1. Show your own explanation screen (the priming screen) that states, in one line, why you are asking for tracking permission.
2. Only when the user taps "Continue" do you show the system ATT dialog.
3. If they choose "Not now" on the priming screen, preserve the system dialog and re-show only the priming later, once the context is right.

With this design, you fire the one-shot system dialog mainly at people likely to allow it.

Implementing the Priming Screen in Rork Max (SwiftUI)

Ask Rork Max to "build a screen that explains the tracking permission" and you get a starting point, but I prefer to own the ATT state transitions and timing myself. I reorganize the generated code into explicit state management like this.

Priming Screen Requirements

• Show it after the user has experienced the app's value once, not right before ad SDK init
• Keep the copy honest: "so we can keep the app free with relevant ads"
• Offer two choices, "Continue" and "Not now," and keep the app fully usable if they decline

The Code

import SwiftUI
import AppTrackingTransparency
import AdSupport
 
// A wrapper that makes ATT state easy to handle from SwiftUI
@MainActor
final class TrackingCoordinator: ObservableObject {
    @Published var showPriming = false
 
    // Call once on launch. Only queue priming when status is undetermined.
    func evaluateOnLaunch() {
        let status = ATTrackingManager.trackingAuthorizationStatus
        if status == .notDetermined {
            // Do not show yet. Set showPriming after a value moment.
            showPriming = false
        }
    }
 
    // Call when the user taps "Continue" on the priming screen.
    func requestSystemPrompt() async -> Bool {
        let status = await ATTrackingManager.requestTrackingAuthorization()
        let authorized = (status == .authorized)
        Analytics.log(event: "att_result",
                      params: ["authorized": authorized])
        return authorized
    }
}

The priming screen itself is a plain SwiftUI sheet.

struct TrackingPrimingView: View {
    @EnvironmentObject var coordinator: TrackingCoordinator
    var onFinish: (Bool) -> Void
 
    var body: some View {
        VStack(spacing: 20) {
            Image(systemName: "hand.raised.circle")
                .font(.system(size: 56))
            Text("Ads that fit you better")
                .font(.headline)
            Text("To keep this app free, we show relevant ads. Choosing Allow on the next screen means more useful ads for you.")
                .font(.callout)
                .multilineTextAlignment(.center)
                .padding(.horizontal)
            Button("Continue") {
                Analytics.log(event: "att_priming_continue")
                Task {
                    let ok = await coordinator.requestSystemPrompt()
                    onFinish(ok)
                }
            }
            .buttonStyle(.borderedProminent)
            Button("Not now") {
                Analytics.log(event: "att_priming_skip")
                onFinish(false)
            }
            .font(.footnote)
        }
        .padding()
    }
}

When to Call the ATT Request

requestTrackingAuthorization must be called while the app is active in the foreground. If you call it during the splash screen at launch, the dialog can fail to appear and simply return .denied. I use "after the first main screen renders and the user takes one or two actions" as the trigger.

Measure the Opt-In Rate to Improve Copy and Timing

Priming is worth nothing until you measure it. At minimum, capture these three events and you will see where people drop off.

1. Priming screen shown (att_priming_shown)
2. "Continue" tapped (att_priming_continue)
3. System dialog result (att_result carrying the authorized flag)

From those three points, compute two rates: the "Continue" pass rate on the priming screen, and the final authorization rate on the system dialog.

enum Analytics {
    // In a real app, swap this for Firebase Analytics or similar.
    static func log(event: String, params: [String: Any] = [:]) {
        // e.g. later aggregate priming-shown rate and final allow rate
        AnalyticsBridge.shared.record(name: event, parameters: params)
    }
}

Once you measure, you will see a single word of copy or a shift in timing move the pass rate. In my wallpaper apps, simply showing the prompt "after a value moment" rather than at launch moved my final allow rate by more than ten percent in feel. Always re-measure on your own app.

Do Not Get the AdMob Init Order Wrong

This is the trap most easily missed in production. If you initialize AdMob (the Google Mobile Ads SDK) before the ATT result is settled, your first ad request goes out with no IDFA and you lose that revenue outright.

The correct order is "consent (UMP if needed) → ATT result settled → AdMob init → first ad request." That serial section must not be parallelized. I collapse startup into a single bootstrap function that makes ad init wait until ATT resolves.

func bootstrapMonetization(coordinator: TrackingCoordinator) async {
    // 1) Settle consent (UMP) first if required
    await ConsentManager.shared.gatherIfNeeded()
    // 2) Wait for the ATT result (decided via the priming flow)
    _ = await coordinator.requestSystemPrompt()
    // 3) Only now initialize the ad SDK
    await AdNetwork.shared.start()
    // 4) Preload the first ad after init completes
    AdNetwork.shared.preloadInterstitial()
}

One caution: do not call requestTrackingAuthorization twice. If it fires once via priming and once via bootstrap, the state races and debugging gets painful. Keep the call site in one place.

There is one more production caution worth stating. If you serve the EU, the UMP (consent management) form and ATT are separate things, and both must pass in the right order. I lock the sequence to "settle UMP first, then show ATT priming." Reverse it and, in some regions, ad init can proceed while consent is still unresolved, which can halt delivery entirely. Always test on a real device from a reset state (set tracking back to undetermined in Settings, or do a fresh install rather than using the simulator). ATT behavior in the simulator does not always match a device, and that mismatch is an easy place to lose an afternoon.

Common Mistakes and the Calls I Make

• Firing the system dialog at launch → easily rejected with no context. I always insert priming.
• Never showing it again after a decline → leave room to re-show only the priming later, after another value moment (the system dialog is still preserved).
• Running ad init at the top of application(_:didFinishLaunchingWithOptions:) → it tends to run before ATT, so move it into bootstrap.
• Not measuring the opt-in rate → improvements become guesswork. I recommend adding at least the three events above.

For App Store review, you must include NSUserTrackingUsageDescription (the Info.plist purpose string) to present ATT. Rork Max output sometimes drops it, so verify before you submit.

Your Next Step

Start by wiring just two events, att_priming_shown and att_result, and measure your current final allow rate. Once you can see the number, whether to fix the copy or the timing becomes a concrete decision. I usually treat this as the starting point for revenue work — getting the "opt-in rate" foundation right tends to be the shorter path than chasing raw ad prices.