WebView App Rejected Under Guideline 5.1.2: Tracking Pixels, ATT and Your Web Content

Does tracking inside a WebView count under Guideline 5.1.2?

Yes. If your WebView app loads your website and that site runs ad pixels or retargeting tags, Apple treats it as your app tracking users. Under Guideline 5.1.2, that requires permission through App Tracking Transparency (ATT) before any tracking starts – or no tracking in the app at all.

Apple answers the question directly in its User Privacy and Data Use FAQ:

Yes. If you are using a webview for app functionality, it should be treated the same way as native functionality in your app, unless you are enabling the user to navigate the open web.

Guideline 5.1.2(i) sets the rule that follows from it:

You must receive explicit permission from users via the App Tracking Transparency APIs to track their activity.

The same paragraph forbids making anything depend on that permission: your app "may not require users to enable system functionalities (e.g. push notifications, location services, tracking) in order to access functionality, content, use the app, or receive monetary or other compensation". So a WebView app has two compliant states: no tracking, or tracking only after an explicit yes – with a fully working app either way. Our Guideline 5.1.2 guide covers ATT for native SDKs; this article is about the scripts in your web content.

Which scripts on your website count as tracking?

Apple defines tracking as "linking user or device data collected from your app with user or device data collected from other companies' apps, websites, or offline properties for targeted advertising or advertising measurement purposes", plus sharing data with data brokers. Its examples include an SDK that combines your users' data with other developers' data for ads "even if you don't use the SDK for these purposes". Web tags are the browser version of those SDKs.

What counts is the purpose of the data, not the vendor's name. If you can't tell what a script shares, treat it as tracking until you have checked.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

How to find every tracker your app actually loads

1. Inspect the app, not the website. In a debug build, set isInspectable on the WKWebView to true (iOS 16.4 and later) and use Safari's Develop menu on your Mac: the Network tab shows every request your pages make in the app.
2. Open your tag manager. It injects tags at runtime, so they never show up in your source code.
3. Check embeds such as video players, maps, social feeds, chat and review widgets.
4. Look at the server side. Conversion APIs send app users' events without a browser request you could see.
5. Compare with App Store Connect. Apple says "Data collected via web traffic must be declared, unless you are enabling the user to navigate the open web" – the basics are in our article on privacy fixes for WebView apps.

Then match the findings to your rejection:

Gating your tags behind ATT: a pattern for WebView apps

ATT lives in native code, your pixels in JavaScript. The app asks; the website listens:

1. Decide per tag. The simplest option: detect the app, for example by a custom user agent suffix, and skip ad pixels in app mode – no prompt, no tracking labels, nothing to gate.
2. If you do track, ask natively. Add NSUserTrackingUsageDescription with a specific text – per Apple's documentation, an app that calls the framework without the key crashes – and call requestTrackingAuthorization once the first screen is visible and the app is active.
3. Hand the answer to the web layer through a JavaScript bridge, a cookie or a variable the app sets.
4. Default to no. Inject a pixel only on an explicit "authorized". Not determined, denied, restricted or a missing value all mean no tags.
5. Guard the tag manager with an app-mode rule that blocks every advertising tag unless tracking is authorized – including tags added next month.
6. Treat server events the same way and forward app users' conversions only if they allowed tracking.
7. Keep everything working. Declining must not lock features, remove content or cost a discount.

The system alert normally appears only once, and never if "Allow Apps to Request to Track" is off in Settings, so handle a permanent no gracefully. New tags after approval also mean updated App Privacy answers – see what you may change on your website after approval.

Why your cookie banner is not a substitute for ATT

Many websites serving Europe run a consent management platform. Inside your app, the banner can stay – Apple allows additional permission screens to meet legal obligations – but it doesn't replace ATT. Apple's FAQ says your app "must always respect the user's response to the App Tracking Transparency prompt, even if their response to other prompts conflicts".

Put the two steps in a clear order and don't nudge. You may reference a previous legal consent in your ATT purpose string, but Apple's first advice is "Don't confuse the user." ATT answers Apple's question, not every regulator's.

App Privacy labels and privacy manifests for web-based tracking

Your App Privacy answers decide what appears under "Data Used to Track You" on your product page, and they must describe what the app does, web content included:

• If you gate pixels behind ATT, mark the data they send – typically identifiers, purchases and product interactions – as used for tracking, even though some users decline.
• If you removed tracking from app mode, answer "No" to tracking for each data type, keep the types your analytics still collect and publish. Apple lets you update these answers at any time without an app update.
• If an AI chat widget sends conversations to a model provider, 5.1.2(i) applies too: you must "clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so".

Privacy manifests are the native counterpart: SDKs in your app ship PrivacyInfo.xcprivacy files that can declare tracking (NSPrivacyTracking) and tracking domains, and Apple documents that network requests to listed domains fail as long as tracking permission is missing. Apple describes this for your app's network requests, not for pages in a web view – so gate web tags in your own code. Upload warnings like ITMS-91053 are covered in our privacy manifest guide.

WebViewGold: native ATT prompt, decision available to your web code

WebViewGold, the website-to-app product made by our team, covers the native half of the pattern above:

• App Tracking Transparency support in the Xcode project, so the system prompt comes from the app with your own purpose string.
• User Tracking Decision API. Your page triggers a user-disable-tracking:// link, and WebViewGold sets the JavaScript variable trackingDisabled to true when tracking was blocked or false when it wasn't. Load pixels only when the value is exactly false, and test a fresh install before the prompt is answered.
• Native ads with consent options. If you show AdMob or Facebook Audience Network ads, ATTDeniedShowAds can stop ads entirely after a denial, and askForAdConsent controls Google's consent management for AdMob.
• Custom user agent for clean app detection, so your browser version keeps its own consent logic.

WebViewGold is a one-time purchase, and you publish in your own developer account. It doesn't decide what your tags do: the gating logic and your App Privacy answers remain yours, and no tool can promise an approval. appsubmitter.io can review both sides before you resubmit.

Two honest ways to answer App Review

Option A: the app doesn't track

Remove ad tags from app mode, change your App Privacy answers to "not used for tracking" and publish them. If the build still contains NSUserTrackingUsageDescription or an ATT request you no longer need, remove it in a new build. Then reply with the tags you removed and the data you still collect, and why.

Option B: the app tracks with permission

Upload a build that shows the ATT prompt on a screen every reviewer reaches, gate your tags as described and name the screen in the review notes. Mention that the alert needs "Allow Apps to Request to Track" switched on, and attach a recording of a fresh install.

Either way, reply in App Store Connect and keep it factual. If App Review treated plain first-party analytics as tracking, cite Apple's definition; if that doesn't settle it, appeal to the App Review Board or book a 30-minute App Review appointment through Meet with Apple. To hand it off, appsubmitter.io audits the tags your app loads, aligns App Privacy with the ATT flow and manages the resubmission in your account – start with a free consultation call or book the iOS service. Code changes are quoted separately upfront.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name] (version [x.y], build [build number]). Regarding Guideline 5.1.2, we have reviewed the tracking behavior of the app and the web content it displays.

[Option A – the app does not track]
- We removed [Meta Pixel / Google Ads tags] from the web content shown in the app. The app does not link user data with third-party data for advertising.
- Our updated App Privacy information is published. We collect [data types] only for [purposes].
- [Build [build number] no longer contains an App Tracking Transparency request.]

[Option B – the app tracks with permission]
- Build [build number] shows the App Tracking Transparency request [after the welcome screen].
- Advertising tags in our web content load only after the user allows tracking. If the user declines, all features remain available.
- Our App Privacy information lists the data used to track.

To verify: install the app fresh with "Allow Apps to Request to Track" turned on in Settings > Privacy & Security > Tracking, then [steps]. A screen recording is attached.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• You have a list of every tag, pixel and embed your pages load inside the app, including tag manager tags.
• In app mode, ad pixels load only after an explicit ATT authorization – or not at all.
• Not determined, denied, restricted and missing values all keep tracking tags off.
• Server-side conversion events are sent only for users who allowed tracking.
• Declining tracking leaves every feature, content area and discount available.
• A cookie banner yes never overrides an ATT no.
• App Privacy answers, including Data Used to Track You, match what the app and its web content do.
• If you use WebViewGold, your tag loader checks trackingDisabled before injecting any pixel.

Frequently asked questions

Sources and further reading

• Apple – App Store Review Guidelines, 5.1.2 Data Use and Sharing
• Apple – User Privacy and Data Use (tracking definition and FAQ)
• Apple – App privacy details on the App Store
• Apple Developer Documentation – requestTrackingAuthorization(completionHandler:)
• Apple Developer Documentation – NSUserTrackingUsageDescription
• Apple Developer Documentation – NSPrivacyTrackingDomains
• Apple Developer Documentation – WKWebView isInspectable
• WebViewGold documentation – User Tracking Decision API (iOS)

Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.